Özel Yazılım Fiyatı Neye Göre Belirlenir? Teklif Almadan Önce Bilmeniz Gerekenler

Kısa cevap

Özel yazılım fiyatı yalnızca ekran sayısına veya yazılımcının kaç gün kod yazacağına göre belirlenmez. Gerçek maliyeti; kapsam, kullanıcı rolleri, iş akışları, entegrasyonlar, mevcut veri aktarımı, güvenlik seviyesi, web/mobil ihtiyacı, test kapsamı, altyapı ve proje sonrasındaki bakım gereksinimleri birlikte belirler. Bu nedenle iki firma aynı başlıkla: “CRM sistemi” veya: “Yönetim paneli” teklifi verse bile aslında tamamen farklı ürünlerden bahsediyor olabilir.

Sağlıklı bir teklif karşılaştırmasında sadece:

Toplam fiyat kaç TL?

• sorusuna değil;

Bu fiyatın içinde tam olarak ne var, ne yok ve proje bittikten sonra hangi maliyetler devam edecek?

sorusuna bakılmalıdır.

Neden özel yazılıma sabit bir “liste fiyatı” vermek zordur?

Çünkü özel yazılım hazır bir kutu ürün değildir. Örneğin iki şirket de: “Operasyon takip sistemi istiyoruz.” diyebilir. İlk şirketin ihtiyacı: Kullanıcı girişi + Görev oluşturma + Durum değiştirme + Basit rapor olabilir. İkinci şirket ise: 8 kullanıcı rolü + Departman bazlı yetkilendirme + Onay süreçleri + Mobil uygulama + ERP entegrasyonu + Dosya yönetimi + Bildirim + Cari hesap + Yapay zekâ + Raporlama + Eski verilerin aktarılması isteyebilir. İki projeye de dışarıdan: “Operasyon yazılımı” denir. Ama yapılacak iş aynı değildir. PMI da proje gereksinimlerinin ve kapsam parametrelerinin belgelenmesini sonraki planlama, doğrulama ve kapsam değişikliği kararları için temel kabul ediyor. (Proje Yönetimi Enstitüsü) Bu nedenle özel yazılım teklifinde ilk soru: “Kaç ekran var?”

• değil;

“Hangi işi, hangi kullanıcılar, hangi kurallarla yapacak?” olmalıdır.

Özel yazılım fiyatını belirleyen 10 temel faktör

1. Projenin kapsamı

En doğrudan maliyet kalemidir. Bir proje: Login Müşteri listesi Form Dashboard seviyesinde olabilir. Başka proje: Web uygulaması + Mobil uygulama + Admin panel + CRM + Operasyon + Finans + Raporlama + API içerebilir. Özellik sayısı arttıkça yalnızca kod miktarı değil:

• tasarım,
• veri modeli,
• test,
• yetkilendirme,

hata senaryoları da büyür.

“10 ekran” neden yeterli fiyatlandırma bilgisi değildir?

Şu iki ekranı düşünün. Ekran A Hakkımızda Statik içerik. Ekran B Finansal Dashboard İçinde:

• kullanıcı yetkisi,
• 8 filtre,
• tarih aralığı,
• farklı para birimleri,
• grafikler,
• Excel export,
• veri aggregation,

API çağrıları bulunuyor. İkisi de: 1 ekran olarak sayılır. Ama geliştirme maliyeti aynı değildir. Bu nedenle profesyonel teklif: ekran sayısı yerine: özellik + business rule + teknik karmaşıklık üzerinden değerlendirilmelidir.

2. İş akışları ve kullanıcı rolleri

Kullanıcı sayısı ile kullanıcı rolü aynı şey değildir. Sistemde: Admin User

• olması başka;

Super Admin Company Admin Operation Finance Sales Customer Supplier Viewer olması başkadır.

Her rol için şu soruların cevaplanması gerekir:

Neyi görebilir?

Neyi değiştirebilir?

Kimin verisini görebilir?

Onay verebilir mi?

Silme yapabilir mi?

Fiyat görebilir mi?

Export alabilir mi?

Onay akışı maliyeti neden artırabilir?

Örneğin: Operasyon oluşturur ↓ Manager kontrol eder ↓ Finance onaylar ↓ Director final approval verir gibi bir süreç varsa yalnızca dört kullanıcı rolü oluşturulmaz. Ayrıca:

• bekliyor,
• onaylandı,
• reddedildi,
• revizyon istendi,
• kim onayladı,
• ne zaman onayladı,

onay sonrası düzenleme yapılabilir mi gibi business rule’lar geliştirilir. Bu nedenle teklif verirken: “Approval sistemi var.” demek yeterli değildir. Workflow’un gerçek yapısı fiyatı belirler.

3. Web, mobil ve farklı platform ihtiyaçları

Yalnızca web uygulaması:

Desktop + responsive web ile: Web + iOS + Android aynı kapsam değildir. Mobil uygulama:

• uygulama navigation,
• native cihaz özellikleri,
• push notification,
• offline davranış,
• store hazırlıkları,

mobil test gibi ek çalışma yaratabilir. Tek backend kullanılması bazı işleri ortaklaştırabilir. Ama: “Web zaten var, mobil uygulama ücretsiz çıkar.” beklentisi doğru değildir.

Mobil uygulama mı responsive web mi?

Her projede native/mobile app gerekmeyebilir. Örneğin kullanıcının:

• kamera,
• push notification,
• sık mobil kullanım,
• cihaz özellikleri,

offline çalışma ihtiyacı yoksa iyi tasarlanmış responsive web uygulaması başlangıç için yeterli olabilir. Bu karar proje fiyatını ciddi ölçüde değiştirebilir. Bu nedenle teknoloji seçimi yalnızca “daha modern olanı” değil, kullanıcı ve iş ihtiyacını karşılayan çözümü hedeflemelidir. GOV.UK Service Standard’ın güncel teknoloji rehberi de kullanılan teknolojinin kullanıcı deneyimi, erişilebilirlik, güvenilirlik ve uzun vadeli çalışma modeli üzerindeki etkisinin değerlendirilmesini öneriyor. (GOV.UK)

4. Entegrasyonlar

Özel yazılım maliyetinin en sık küçümsenen alanlarından biri budur. Yeni sistem:

• ERP,
• muhasebe,
• banka,
• ödeme sistemi,
• CRM,
• e-fatura,
• Microsoft 365,
• Google Workspace,
• lojistik sistemi,

AI servisi ile entegre olabilir. Her entegrasyon: API'yi çağır seviyesinde değildir. Genellikle: API araştırması ↓ Kimlik doğrulama ↓ Data mapping ↓ Test hesabı ↓ Error handling ↓ Rate limit ↓ Retry ↓ Monitoring gerekir. Üçüncü taraf API’ye bağlanan bir servisin availability’si de kısmen o sağlayıcıya bağlı hale gelir; bu nedenle hata ve alternatif akışlar ayrıca tasarlanmalıdır. (GOV.UK)

Entegrasyon başına neden sabit fiyat vermek zor?

Çünkü iki API aynı zorlukta değildir. API A

• iyi dokümante edilmiş,
• REST,
• hazır sandbox,
• modern OAuth,

örnek kodlar. API B

• eski,
• eksik dokümantasyon,
• özel VPN,
• XML/SOAP,
• test sistemi yok,

sağlayıcıdan manuel onay gerekiyor. İkisi de: “1 entegrasyon” olarak görünür. Ama efor tamamen farklı olabilir.

Teklif almadan önce entegrasyonlar için ne hazırlamalısınız?

Mümkünse:

• kullanılacak sistemin adı,
• API dokümantasyonu,
• sandbox/test erişimi,
• teknik sorumlu iletişimi,
• hangi verilerin alınacağı,

hangi verilerin gönderileceği hazır olmalıdır. Bu bilgiler ne kadar erken sağlanırsa teklif o kadar gerçekçi olur.

5. Mevcut verinin yeni sisteme aktarılması

Yeni yazılım tamamen boş database ile başlayabilir. Ya da: 8 yıllık müşteri verisi + 20 Excel dosyası + eski CRM + binlerce PDF taşınabilir. Bu ikinci durumda:

data migration

ayrı bir proje kalemidir.

Neden “Excel'i içeri aktarırız” bazen basit değildir?

Çünkü veri:

ABC LTD ABC Limited A.B.C. Ltd. gibi duplicate olabilir. Tarih formatları: 23/08/26 23.08.2026 2026-08-23 şeklinde farklı olabilir. Eksik kayıtlar bulunabilir. Eski sistemde:

status = 3

olan değer yeni sistemde:

status = COMPLETED

olarak tutulabilir. Dolayısıyla veri aktarımı: Export ↓ Import

• değil;

Mapping ↓ Cleaning ↓ Deduplication ↓ Transformation ↓ Import ↓ Validation olabilir. Bu doğal olarak maliyeti etkiler.

6. Güvenlik gereksinimleri

Bir tanıtım sitesiyle müşteri:

• finans,
• sağlık,
• ticari sır,
• operasyon,

ödeme verisi yöneten B2B sistem aynı güvenlik seviyesine ihtiyaç duymaz. Gelişmiş sistemde:

• rol bazlı erişim,
• MFA,
• audit log,
• encryption,
• tenant isolation,
• backup,
• güvenlik testleri,

erişim politikaları gerekebilir. Güncel GOV.UK güvenlik rehberi de güvenli dijital hizmetlerde tehditlerin, yasal sorumlulukların, üçüncü taraf yazılım risklerinin, veri korumasının ve güvenlik bütçesinin hizmetin yaşam döngüsü boyunca ele alınmasını öneriyor. (GOV.UK) Yani güvenlik: sonradan eklenen ekstra özellik değildir. Doğru projede mimarinin parçasıdır.

Penetrasyon testi fiyata dahil mi?

Bu mutlaka sorulmalıdır. Bazı projelerde: Internal security testing yeterli olabilir. Daha hassas projelerde bağımsız: penetration testing gerekebilir. Güvenlik rehberleri özellikle büyük kod değişiklikleri ve yeni entegrasyonlarda güvenlik kontrollerinin yeniden değerlendirilmesini öneriyor. (GOV.UK)

Teklifte şu ifade açık olmalıdır:

Penetrasyon testi dahil mi, ayrıca mı fiyatlandırılıyor?

7. Test ve kalite seviyesi

Özel yazılım fiyatında yalnızca:

Kod yazma bulunmaz. Production kalitesi için:

• unit test,
• integration test,
• E2E,
• cihaz/tarayıcı testi,
• role/authorization testleri,
• hata senaryoları,

UAT gerekebilir. “Çalışıyor” ile “production-ready” aynı değildir Örneğin ödeme özelliği: Kart başarılı → ödeme başarılı senaryosunda çalışabilir.

Peki:

timeout?

kullanıcı iki kez tıkladı?

webhook iki kere geldi?

payment provider geç cevap verdi?

işlem başarılı ama uygulama response alamadı?

Bu senaryolar da test edilmelidir. Güncel GOV.UK güvenilir hizmet rehberi de kalite güvencesinin yalnızca otomatik araçlara bırakılmaması ve servisin gerçek kullanıcı sonuçlarının izlenmesini vurguluyor. (GOV.UK) Bu kalite seviyesi de teklif maliyetini etkiler.

8. Tasarım ve kullanıcı deneyimi

Bazı tekliflerde:

Frontend development vardır. Ama: UX/UI design yoktur. Bu ikisi aynı değildir. UI/UX süreci:

• kullanıcı akışı,
• wireframe,
• görsel tasarım,
• responsive davranış,
• design system,

usability gibi çalışmalar içerebilir. Hazır component sistemlerinin kullanılmasıyla tamamen custom tasarımın maliyeti aynı değildir.

Teklifte:

Tasarımlar tarafımıza mı ait olacak, yoksa yazılım firması mı hazırlayacak?

sorusu açık olmalıdır.

9. Teknik mimari ve ölçek beklentisi

Şu iki uygulama da aynı ekranlara sahip olabilir:

Sistem A 20 kullanıcı Sistem B 100.000 kullanıcı + yüksek trafik + çoklu şirket + kritik SLA İkinci sistem:

• cache,
• queue,
• monitoring,
• autoscaling,
• database optimization,

availability açısından farklı tasarlanabilir. Cloud mimarisinde performans, hız ve maliyet arasında gerçek trade-off’lar vardır. AWS Well-Architected Framework de mimari seçimlerde cost, speed-to-market ve kaynak kullanımının birlikte değerlendirilmesini; maliyetin kullanım ve mimariyle zaman içinde optimize edilmesini öneriyor. (AWS Dokümantasyonu) Bu nedenle: “Cloud kullanılıyor.” tek başına fiyatı açıklamaz. Ne büyüklükte ve ne kadar güvenilir bir sistem tasarlandığı önemlidir.

10. Proje sonrası bakım ve destek

En önemli fakat tekliflerde en çok gözden kaçan kalemlerden biri budur. Yazılım canlıya alındıktan sonra:

• framework güncellemesi,
• security patch,
• işletim sistemi/runtime değişikliği,
• API değişikliği,
• bug,
• yeni browser/device,

monitoring devam eder. Dijital servislerin canlıya çıktıktan sonra da güncellenmesi ve iyileştirilmesi gerekir; dependency’lerin güncel tutulması da güvenlik ve servis sürekliliğinin bir parçasıdır. (GOV.UK) Bu nedenle özel yazılım maliyetini: Development price olarak değil: Initial investment + Ongoing operation olarak değerlendirmek daha doğrudur.

Özel yazılım teklifindeki maliyetleri iki gruba ayırın

1. Bir kerelik geliştirme maliyetleri

Örneğin:

• discovery,
• UX/UI,
• frontend,
• backend,
• mobil,
• entegrasyon,
• veri migration,
• test,

canlıya alma.

2. Devam eden maliyetler

Örneğin:

• hosting/cloud,
• database,
• storage,
• e-mail/SMS,
• AI API,
• domain,
• üçüncü taraf lisans,
• monitoring,
• bakım,

destek. Bu ayrım teklif üzerinde açık olmalıdır.

Cloud maliyeti neden sabit olmayabilir?

Cloud birçok durumda:

kullanım arttıkça maliyet artar modelinde çalışır. Örneğin:

• CPU,
• database,
• storage,
• bandwidth,
• request,

AI token kullanımı maliyet yaratabilir. AWS Well-Architected yaklaşımı da cloud maliyetlerinde expenditure ve usage awareness, demand/supply yönetimi ve zaman içinde optimizasyonu temel çalışma alanları olarak tanımlıyor. (AWS Dokümantasyonu) Bu nedenle teklifte: “Sunucu dahil.” ifadesi tek başına yeterli değildir.

Sorulması gereken:

Hangi kapasiteye kadar? Kullanım büyüdüğünde ücret nasıl değişecek?

Üçüncü taraf lisansları kim ödüyor?

Örneğin sistem:

• SMS,
• WhatsApp,
• e-mail,
• harita,
• ödeme,
• AI,
• storage,

analytics servisleri kullanabilir. Bunlar yazılım teklifine dahil olmayabilir. Teklifte her servis için: Firma ödüyor veya Müşteri doğrudan sağlayıcıya ödüyor ayrımı yapılmalıdır.

Bir yazılım teklifinin sadece toplam rakamını karşılaştırmak neden yanlış?

Örneğin: Firma A 300.000 TL Dahil: Web uygulaması Backend Admin panel UI/UX Test Data migration 3 ay support Deployment Firma B 190.000 TL Dahil: Web uygulaması Backend Harici:

• tasarım,
• migration,
• sunucu,
• bakım,

entegrasyon. İlk bakışta B ucuzdur. Ama kapsamlar eşit değildir. Bu yüzden: Fiyat karşılaştırmadan önce kapsamları eşitleyin.

Teklifleri nasıl aynı zemine getirirsiniz?

Bir tablo oluşturun:

Kalem Firma A Firma B Firma C Discovery ✅ ❌ ✅ UI/UX ✅ ❌ ✅ Backend ✅ ✅ ✅ Admin panel ✅ ✅ ✅ Mobil ❌ ❌ ✅ Entegrasyon 2 1 2 Data migration ✅ ❌ ✅ QA ✅ Belirsiz ✅ Deployment ✅ ✅ ✅ Kaynak kod

✅

?

✅

Bakım 3 ay ❌ 6 ay Hosting Harici Dahil Harici Bu tablo toplam rakamdan daha fazla bilgi verir.

Teklif almadan önce sorulması gereken 15 soru

1. Tam olarak hangi özellikler fiyata dahil?

“CRM sistemi” yeterli açıklama değildir.

2. Hangi özellikler dahil değil?

Bu soru bazen dahil olanlardan daha değerlidir.

3. UI/UX tasarım dahil mi?

Hazır template mi, custom tasarım mı?

4. Mobil uygulama dahil mi?

iOS ve Android birlikte mi?

5. Entegrasyon sayısı ve kapsamı ne?

API tarafında hangi işlemler yapılacak?

6. Eski verilerin aktarılması dahil mi?

Veri temizleme de dahil mi?

7. Test süreci neleri içeriyor?

Kim UAT yapacak?

8. Hosting ve cloud dahil mi?

Dahilse hangi limite kadar?

9. Üçüncü taraf servis ücretleri kime ait?

SMS, e-mail, AI, harita vb.

10. Canlıya alma dahil mi?

Domain, cloud, store süreçleri?

11. Kaynak kod kime ait olacak?

makalede bunu ayrıca detaylandıracağız.

12. Proje sonrasında support var mı?

Ne kadar süre?

13. Yeni özellikler nasıl fiyatlandırılacak?

Change request süreci nasıl?

14. Kritik hata desteği var mı?

SLA veya response süresi tanımlı mı?

15. Proje iptal edilirse elimizde ne kalır?

Kod, database, tasarım, dokümantasyon teslim edilecek mi?

Fiyatlandırma modelleri nelerdir?

Özel yazılım firmaları farklı modeller kullanabilir.

1. Sabit fiyat — Fixed Price

Örneğin: Belirli kapsam → belirli ücret Avantaj: bütçe öngörülebilir. Dezavantaj: kapsamın yeterince net olması gerekir.

Sabit fiyat hangi projelerde iyi çalışır?

Özellikle:

• kapsam net,
• iş akışları belli,
• entegrasyonlar biliniyor,

değişkenlik düşük ise. Ancak: “Proje boyunca istediğimiz her şeyi ekleriz” + “Fiyat değişmesin” modeli sürdürülebilir değildir.

2. Time & Materials

Model:

Harcanan süre × ekip maliyeti şeklindedir. Avantaj:

• kapsam değişebilir,

discovery yoğun ürünlerde esnektir. Dezavantaj: final bütçe fixed-price kadar net değildir.

3. Milestone / Faz Bazlı

Örneğin: Faz 1 → MVP Faz 2 → Entegrasyon Faz 3 → Mobil şeklinde fiyatlanabilir. Özel yazılım için güçlü modellerden biridir çünkü büyük proje daha yönetilebilir yatırım parçalarına bölünür.

4. Retainer / Dedicated Team

Şirket sürekli geliştirme istiyorsa:

Aylık ekip veya: belirli kapasite ayrılabilir. Özellikle sürekli büyüyen SaaS ürünlerinde kullanılabilir.

Hangi fiyatlandırma modeli daha iyi?

Tek bir doğru yoktur. Durum Daha uygun model Kapsam çok net Fixed price Belirsizlik yüksek Time & Materials Büyük proje Faz/milestone Sürekli ürün geliştirme

Retainer/dedicated team

En düşük teklif neden bazen en pahalı seçenek olabilir?

Düşük teklif şu yollarla oluşabilir:

Test yok Dokümantasyon yok Güvenlik sınırlı Data migration hariç Support hariç Entegrasyon hariç İlk yatırım düşük görünür. Sonrasında:

• yeniden geliştirme,
• başka firmaya geçiş,
• production sorunları,

teknik borç nedeniyle toplam maliyet yükselir. Bu yüzden doğru metrik: ilk proje fiyatı

• değil;

toplam sahip olma maliyeti — TCO olmalıdır.

Total Cost of Ownership nasıl düşünülmeli?

Basitleştirilmiş model:

TCO = Initial Development + Infrastructure + Third-party Services + Maintenance + Support + Future Migration / Upgrade Cloud maliyetlerinde de yalnızca başlangıç deployment’ını değil, workload’un bütün yaşam döngüsündeki kullanım ve optimizasyonu değerlendirmek gerekir. (AWS Dokümantasyonu)

Özel yazılım fiyatı neden sadece developer maaşı değildir?

Bir proje ekibinde:

• business analysis,
• UX/UI,
• frontend,
• backend,
• mobile,
• QA,
• DevOps,
• project/product management,

security rolleri bulunabilir. Küçük projelerde tek kişi birkaç rolü üstlenebilir. Büyük projede uzmanlaşma artar. Bu nedenle: “Developer 2 ay çalışacak, maliyet neden bu kadar?” hesabı çoğu zaman projenin tamamını yansıtmaz.

Teklif içinde proje yönetimi neden önemlidir?

Çünkü geliştirme yalnızca task tamamlamak değildir. Ayrıca: Kapsam ↓ Planlama ↓ Öncelik ↓ Demo ↓ Feedback ↓ Test ↓ Release yönetilir. Zayıf proje yönetiminin bedeli doğrudan kod satırı olarak görünmez. Ama:

• rework,
• gecikme,

yanlış kapsam olarak ortaya çıkar.

AI yazılım geliştirme fiyatlarını tamamen düşürür mü?

AI araçları:

• kod üretimi,
• test,
• refactor,
• araştırma,

debugging gibi işlerde geliştiricileri hızlandırabilir. Ancak özel yazılımın maliyetini oluşturan:

• iş analizi,
• mimari karar,
• entegrasyon,
• doğrulama,
• security,

acceptance ortadan kalkmaz. Bu nedenle: “AI ile kod artık hızlı yazılıyor, yazılım birkaç günde yapılır.” genellemesi doğru değildir. Daha doğru sonuç: AI bazı üretim maliyetlerini azaltabilir veya ekip kapasitesini artırabilir; ancak ürün sorumluluğu ve kalite gereksinimini ortadan kaldırmaz.

Hazır çözüm kullanmak fiyatı azaltabilir mi?

Evet. Her özellik sıfırdan geliştirilmek zorunda değildir. Örneğin: Authentication Storage Payment E-mail Analytics için güvenilir servisler kullanılabilir. Bu:

• geliştirme süresini,

bakım yükünü azaltabilir. Ancak üçüncü taraf servis:

• lisans,
• API,

vendor dependency maliyeti oluşturabilir. Burada hazır bileşen ile custom geliştirme arasında teknik ve ekonomik trade-off değerlendirilmelidir.

Open-source kullanmak ücretsiz yazılım demek mi?

Hayır. Bir component’in lisans ücreti: 0 TL olabilir. Ama:

• entegrasyon,
• deployment,
• bakım,
• güncelleme,

security maliyeti devam eder. AWS’in cost-optimization rehberi de licensed ve open-source çözümler dahil farklı teknoloji seçeneklerinin toplam maliyet açısından değerlendirilmesini mimari kararların parçası olarak ele alıyor. (AWS Dokümantasyonu)

Teklifte “bakım” yazıyorsa ne anlama geliyor?

Mutlaka açıklanmalıdır. Bakım şu anlamlara gelebilir: Firma A Sadece bug fix Firma B Dependency Security Monitoring Bug fix Small improvements Aynı kelime. Farklı hizmet. Teklifte bakım kapsamı net yazmalıdır.

Garanti ile bakım aynı mı?

Genellikle hayır. Örneğin yazılım firmasının kendi yaptığı bir hatayı düzeltmesi: bug/warranty olabilir. Ama 8 ay sonra üçüncü taraf API değiştiğinde gereken çalışma: maintenance olabilir. Bu ayrım sözleşme ve teklifte açık olmalıdır.

Proje sırasında yeni özellik istersek ne olur?

Sağlıklı süreç:

Yeni talep ↓ Analiz ↓ Süre etkisi ↓ Maliyet etkisi ↓ Faz 1 / Faz 2 ↓ Onay olmalıdır. Yeni fikir çıkması problem değildir. Fakat: Kapsam ↑ Süre aynı Bütçe aynı varsayımı gerçekçi değildir.

İyi teklif nasıl görünür?

İyi bir özel yazılım teklifi ideal olarak şunları netleştirir:

Proje amacı

Ne çözüyoruz?

Kapsam

Neler geliştirilecek?

Kapsam dışı

Neler geliştirilmeyecek?

Teknik teslimatlar

• web,
• mobil,
• panel,

API vb.

Entegrasyonlar

Hangileri?

Veri aktarımı

Dahil mi?

Takvim

Fazlar?

Maliyet

Bir kerelik / devam eden?

Support

Ne kadar?

Change request

Nasıl yönetilecek?

Kaynak kod

Kime ait?

Teklifte “kapsam dışı” bölüm neden çok değerlidir?

Çünkü iki tarafın varsayımlarını görünür yapar. Örneğin: “Mobil uygulama kapsam dışıdır.” çok değerlidir. Aksi halde müşteri: “Zaten web yapılıyor, mobil de vardır.” diye düşünebilir. Firma ise: “Mobil teklif edilmedi.” diyebilir. Kapsam dışı maddeler anlaşmazlığı azaltır. InoviqLab Örnek Teklif Maliyet Yapısı Bu bölüm piyasa fiyatı değil, tekliflerin nasıl ayrıştırılabileceğini gösteren örnek modeldir.

1. Discovery / Analiz

2. UX / UI

3. Backend

4. Web uygulaması

5. Mobil uygulama

6. Admin panel

7. Entegrasyonlar

8. Data migration

9. QA

10. Deployment

11. Support / maintenance

12. Üçüncü taraf servisler

Bir teklifin toplam bedeli kadar bu dağılımın da anlaşılması gerekir.

Fiyatı düşürmek için özelliklerden vazgeçmek zorunda mısınız?

Her zaman değil. Üç farklı optimizasyon yapılabilir.

1. Fazlama

MVP

↓ Faz 2 ↓

Faz 3

2. Hazır servis kullanımı

Custom geliştirilmesi gerekmeyen alanları azaltmak.

3. İş akışını sadeleştirmek

Örneğin gereksiz 6 aşamalı approval yerine 3 aşama gerçekten yeterli olabilir.

Bütçe sınırlıysa yazılım firmasına bütçe söylenmeli mi?

Çoğu durumda faydalıdır. Örneğin: 300.000–400.000 TL yatırım bütçemiz var. bilgisi firmaya: Bu bütçeyle

hangi MVP

oluşturulabilir?

sorusunu cevaplama imkânı verir. Aksi halde firma: ideal tam kapsam üzerinden teklif hazırlayabilir ve bütçenin çok üstünde kalabilir. “Bütçeyi söylersek fiyatı ona göre yükseltirler” endişesi Bu nedenle bütçe konuşması: “Maksimum bu kadar ödeyeceğiz.”

• şeklinde değil;

“İlk faz için yatırım aralığımız bu; bu aralıkta en yüksek business değerini hangi kapsamla oluşturabiliriz?” şeklinde yapılabilir. Bu daha sağlıklı bir satın alma konuşmasıdır.

Özel yazılım yatırımı için ROI nasıl düşünülmeli?

Sadece:

Yazılım = 500.000 TL

demek yerine:

Ayda kaç saat tasarruf?

Kaç hata azalıyor?

Kaç işlem otomatikleşiyor?

Kaç personelin işi kolaylaşıyor?

Kaç müşteri daha hızlı hizmet alıyor?

sorulmalıdır. AWS’in maliyet optimizasyonu çerçevesi de teknoloji maliyetlerini business outcome ve iş değeriyle ilişkilendirmenin önemini vurguluyor. (AWS Dokümantasyonu) Basit ROI örneği Şirket bugün: 10 çalışan × ayda 20 saat manuel işlem = 200 saat harcıyor. Yeni sistem bunu: 50 saate indiriyorsa: 150 saat / ay kapasite kazanımı oluşur. Buna ayrıca:

• hata azalması,
• daha hızlı rapor,

müşteri deneyimi eklenebilir.

Bu durumda yazılım maliyeti yalnızca:

ne kadar ödüyoruz?

• değil;

hangi operasyon maliyetini azaltıyoruz?

üzerinden değerlendirilir. En ucuz teklifi seçmenin 6 gizli riski Kapsam eksik olabilir. Test dahil olmayabilir. Bakım maliyeti sonradan çıkabilir. Kaynak kod teslim edilmeyebilir. Vendor lock-in oluşabilir. Teknik borç nedeniyle yeniden geliştirme gerekebilir. Bu, pahalı teklif her zaman daha iyi demek değildir. Asıl hedef: aynı kapsam ve kalite seviyesindeki teklifleri karşılaştırmaktır. Teklif karşılaştırma puan tablosu Örneğin:

Fiyat

%10 Bu oranlar örnektir. Ama önemli mesaj: Fiyat tek kriter olmamalıdır. Özel yazılım teklifi almadan önce hazırlık kontrol listesi Çözmek istediğimiz ana problem belli. Kullanıcı grupları belli. Bugünkü süreci gösterebiliyoruz. MVP özelliklerini ayırdık. Kullanıcı rollerini belirledik. Onay süreçlerini biliyoruz. Entegrasyonları listeledik. API erişimlerini kontrol ettik. Eski veri örnekleri hazır. Web/mobil ihtiyacı belirli. Güvenlik hassasiyetleri belli. Beklenen kullanıcı/işlem hacmi kabaca biliniyor. İlk faz bütçe aralığı düşünülmüş. Proje tarafında karar sahibi belli. Support beklentisi belirli. Bu liste ne kadar netse tekliflerin birbirinden neden farklı olduğu da o kadar kolay anlaşılır. Teklif Karşılaştırma Kontrol Listesi

Kapsam

Aynı modüller teklif edilmiş mi?

Kapsam dışı maddeler var mı?

Kullanıcı rolleri dahil mi?

Raporlama kapsamı aynı mı?

Teknik

Backend dahil mi?

Admin panel dahil mi?

Mobil dahil mi?

Entegrasyonlar dahil mi?

Veri migration dahil mi?

Kalite

QA var mı?

UAT süreci tanımlı mı?

Security kontrolleri var mı?

Backup/monitoring düşünülmüş mü?

Ticari

Tek seferlik maliyet belli. Aylık/yıllık maliyet belli. Third-party ücretleri belli. Bakım fiyatı belli. Yeni geliştirme modeli belli. Sahiplik Kaynak kod sahipliği açık. Database erişimi açık. Cloud hesabı kimin belli. Domain kimin belli. Dokümantasyon teslimi belli.

InoviqLab değerlendirmesi

Bu bölüm InoviqLab’ın özel yazılım fiyatlandırma yaklaşımıdır.

Bir özel yazılım teklifinin kalitesini yalnızca:

kaç TL?

ile değerlendirmek doğru değildir. Bizim için daha önemli denklem: Fiyat ÷ Net Teslim Edilen Değer dir. Birinci prensip: Fiyat kapsamdan sonra gelmeli Şu konuşma: “CRM ne kadar?” tek başına yeterli değildir. Daha sağlıklı: Problem ↓ Süreç ↓ MVP ↓ Teknik ihtiyaç ↓ Teklif şeklindedir. Aksi halde teklif hazırlayan firma boşlukları kendi varsayımlarıyla doldurur. Sonuçta firmalar aynı projeye değil, kendi hayal ettikleri farklı projelere fiyat verir. İkinci prensip: İyi teklif bilinmeyenleri saklamaz Örneğin ERP dokümantasyonu henüz görülmediyse: “ERP entegrasyonu kesin 3 gün.” demek yerine: “ERP API incelemesi sonrası kapsam kesinleştirilecektir.” ifadesi daha güvenilirdir. Belirsizliğin yazılması profesyonellik eksikliği değildir. Tam tersine risk yönetimidir. Üçüncü prensip: Başlangıç maliyeti ile yaşam döngüsü maliyetini ayırın Özel yazılım canlıya çıktığında ekonomik yaşamı yeni başlar. Bu nedenle: Development ile: Operation ayrı bütçelenmelidir. AWS’in güncel Well-Architected cost yaklaşımı da maliyet optimizasyonunu ilk tasarımdan production’ın bütün yaşam döngüsüne uzanan sürekli bir süreç olarak ele alıyor. (AWS Dokümantasyonu) Dördüncü prensip: Bütçe düşürmenin en iyi yolu kaliteyi kesmek değildir Bütçe yüksek geliyorsa ilk kesilecekler: Security Testing Architecture olmamalıdır. Önce: Scope ↓ Fazlama ↓ Opsiyonel modüller değerlendirilebilir. Yani: Daha kötü yazılım değil, daha küçük ilk ürün. Bu genellikle daha sağlıklı optimizasyondur. Beşinci prensip: Kaynak kod ve altyapı sahipliğini fiyat kadar önemseyin Çok ucuz bir sistemin sonunda: Kod sizde değil Cloud hesabı sizde değil Domain sizde değil Database erişimi sizde değil ise tedarikçi bağımlılığı oluşabilir. Bu konuyu 20 ve 21. makalelerde ayrıca detaylandıracağız. Ancak teklif aşamasında bile açık olmalıdır.

Sonuç

Özel yazılım fiyatını belirleyen tek bir formül yoktur. Gerçek maliyet: Kapsam + İş Akışları + Roller + Platformlar + Entegrasyonlar + Veri Migration + Güvenlik + Test + Altyapı + Bakım kombinasyonundan oluşur. Bu nedenle aynı başlıktaki iki teklif arasında büyük fiyat farkı olması tek başına: “Bir firma pahalı.” anlamına gelmez. Önce iki firmanın aynı şeyi teklif edip etmediği kontrol edilmelidir.

Teklif değerlendirirken şu üç rakamı ayrı ayrı görmek en sağlıklı yaklaşımdır:

1. İlk geliştirme yatırımı

2. Devam eden aylık/yıllık maliyet

3. Gelecekteki değişiklik ve bakım modeli

Ve satın alma kararında belki de en önemli soru şudur:

“En ucuz yazılım hangisi?” yerine: “İhtiyacımızı karşılayan, sahipliği bizde kalan ve uzun vadede sürdürülebilir en doğru çözüm hangisi?”