Özel Yazılım Fiyatları 2026: Web Uygulaması Maliyeti Nasıl Hesaplanır?

İlk görüşmede neredeyse her seferinde aynı cümleyi duyuyorum: “Bizim gibi bir sistem kaça çıkar?” Çoğu zaman masada başka bir firmadan gelmiş tek satırlık bir rakam da oluyor. O rakamın neyi kapsadığını ise genellikle teklifi veren dışında kimse bilmiyor. Kaç ekran var, kaç kullanıcı rolü, hangi entegrasyonlar? Test kimin işi, yayından sonra sisteme kim bakacak? Bunlar kâğıda dökülmeden iki teklifi yan yana koymanın anlamı yok.

Biz bir web uygulamasının bedelini her projede aynı beş parçadan kuruyoruz. Efor, yapılacak işin adam-gün cinsinden toplamıdır. Gün ücreti, ekibin bir günlük maliyeti ve kârıdır. Entegrasyon payı, dış sistemlere bağlanmanın getirdiği, kodlamadan çok bekleme ve doğrulamadan oluşan ek iştir. Risk payı, kapsam belirsizliğinin parasal karşılığıdır. İşletim gideri ise yayından sonra her yıl tekrar eden barındırma, bakım ve geliştirme bütçesidir.

• Eforadam-günİş kırılımındaki her paketin üç noktalı tahmini (dar, tipik, geniş kapsam) toplanır.
• × Gün ücretiTL/günRol karışımına göre ortalama ücret; ekibin maliyeti, boşta kalan zamanı ve kârı dahil.
• + Entegrasyongizli günlerDış sistem başına test ortamı, veri eşleme, sertifika ve canlı doğrulama günleri.
• + Risk payıbelirsizlikKeşif yapılmadıysa geniş, yapıldıysa dar tutulan çarpan.
• + İşletimyıllıkBarındırma, izleme, güvenlik güncellemeleri, küçük geliştirmeler.

Formülü açık yazınca bütçeyi küçültmek istediğinizde hangi kalemle oynadığınız da görünür hâle gelir: ekran sayısını mı azaltıyorsunuz, entegrasyonu ikinci sürüme mi bırakıyorsunuz, yoksa testten mi kısıyorsunuz (sonuncusunu önermem). Yönetime veya satın almaya gidecek bütçe talebinin gerekçesi de kendiliğinden çıkar. Web yazılım geliştirme tekliflerimizi de bu kırılımla hazırlıyoruz; satırları görmeden rakamı konuşmuyoruz.

Adam-gün, bir kişinin bir iş gününde yaptığı iş miktarıdır. “20 adam-gün” demek, bir kişinin 20 günde ya da iki kişinin 10 günde bitireceği iş demektir; teoride. Pratikte iki kişi aynı işi tam olarak yarı sürede bitirmez, çünkü konuşmaları, birbirinin kodunu incelemeleri ve aynı dosyaya dokunmamak için iş bölmeleri gerekir. Bu koordinasyon payını takvim hesabında ayrıca ele alacağız.

Hesap, işi küçük parçalara bölmekle başlar. Buna iş kırılım yapısı (WBS, Work Breakdown Structure) denir. Kural basit: bir paket tek bir kişinin bir haftadan kısa sürede bitirebileceği kadar küçük olmalı. “Sipariş modülü” bir paket değildir; “sipariş listesi ekranı ve filtreleri”, “sipariş onay akışı”, “siparişin ERP'ye aktarımı” paketlerdir.

1. 1İşi paketlere bölünHer ekran, her iş kuralı ve her entegrasyon ayrı satır. Bir haftayı aşan paket varsa tekrar bölün.
2. 2Paket başına üç tahmin yazınDar, tipik, geniş. Tahmini paketi yapacak rolden biri versin; satış ekibi değil.
3. 3Ortak işleri ekleyinProje kurulumu, ortamlar, CI/CD, test, proje yönetimi ve yayın; çoğu teklifte unutulan satırlar bunlardır.
4. 4Rol ücretleriyle çarpınBackend, frontend, tasarım, test ve yönetim günlerini kendi ücretleriyle ya da ortalama ücretle çarpın.
5. 5Belirsizlik çarpanını uygulayınToplamı tek rakam değil aralık olarak verin: en az, olası, en çok.

Her paket için tek bir gün sayısı yerine üç tahmin yazıyoruz: işler yolunda giderse (dar), olağan durumda (tipik) ve bilinmeyenler ortaya çıkarsa (geniş). Bunları PERT formülüyle birleştiriyoruz: (dar + 4 × tipik + geniş) / 6. Bu formül, geniş tarafı uzun olan riskli paketlerin beklenen değerini doğal olarak yukarı çeker. COCOMO gibi kod büyüklüğüne dayanan modeller de var; ancak teklif aşamasında kod satırı bilinmediği için KOBİ ölçeğindeki projelerde paket bazlı tahmin daha işe yarar.

Adam-ayla karıştırmayın. Bir ayda ortalama 21–22 iş günü var; izin, resmî tatil, toplantı ve eğitim düşülünce bir geliştiricinin projeye verebildiği gün ayda 16–17'ye iner. Teklifte “5 adam-ay” yazıyorsa ayı kaç gün saydıklarını sorun: 22 günle 16 gün arasındaki fark, 5 adam-ayda 30 iş günü eder.

Örnek iş kırılımı: bayi sipariş portalı

Aşağıdaki tablo uydurma bir müşteri değil, tipik bir senaryonun iskeletidir: 40 bayinin giriş yapıp fiyat listesini gördüğü, sipariş verdiği ve siparişin Logo'ya aktarıldığı bir portal. Gün ücreti örnek olarak 10.000 TL alınmıştır.

Toplam 104 adam-gün × 10.000 TL = 1.040.000 TL (KDV hariç). %20 KDV ile 1.248.000 TL.

• Ekranlar (katalog, sepet, panel) toplamın yarısından azdır; geri kalanı entegrasyon, test, yönetim ve altyapıdır.
• Test ve proje yönetimi birlikte 25 gün, yani işin yaklaşık dörtte biri. Bu satırları olmayan bir teklif ucuz görünür, bedeli projede ödenir.
• Logo entegrasyonu tek başına 14 gün; bayiye özel fiyat kuralları karmaşıksa bu sayı kolayca büyür.

Bir web uygulamasını modüllere ayırdığınızda bazı parçaların neredeyse her projede tekrar ettiğini görürsünüz: giriş ve yetki, yönetim paneli, raporlar, bildirimler. Bu tekrar, eforlarının bir bant içinde tahmin edilebilmesini sağlar. Aşağıdaki tablo bizim hesaplayıcıda kullandığımız örnek bantlardır; gerçek bir projede ekip kendi geçmiş verisiyle bu bantları kalibre etmelidir.

Tabloyu okurken “dar kapsam” sütununu hedef, “geniş kapsam” sütununu uyarı olarak düşünün. Örneğin rol yetkisi iki rolle (yönetici ve kullanıcı) dar banttadır; aynı ekranı şube müdürü yalnız kendi şubesinin kayıtlarıyla görecekse kayıt bazlı yetki devreye girer ve iş geniş banda kayar.

Bantlar adam-gün cinsinden örnek değerlerdir; ekip ve teknoloji yığınına göre kalibre edilmelidir.

Ekran sayısı ayrı bir çarpandır. Basit bir liste ve form ekranı (bir tablonun listelenmesi, eklenmesi, düzenlenmesi) hazır bir arayüz kitiyle ekran başına 1–2 adam-gün sürebilir; özel tasarımlı, çok durumlu bir ekran ise 3 günü rahatça geçer. Hesaplayıcıda ekran başına tipik değer UI kitte 1,6, özel tasarım sisteminde 2,4 adam-gündür (örnek).

Bir entegrasyonun kodu çoğu zaman birkaç günde yazılır. Takvimi ve bütçeyi uzatan, kodun etrafındaki işlerdir: karşı tarafın test ortamına erişim almak, eksik veya güncel olmayan dokümantasyonu doğrulamak, iki sistemdeki kodları eşlemek (sizin stok kodunuz ile ERP'deki stok kodu aynı mı?), hata ve zaman aşımı senaryolarını kurmak, canlıya geçmeden önce karşı tarafın onayını almak.

Türkiye'de sık karşılaştığımız entegrasyonlarda bu gizli günlerin kaynağı az çok bellidir. e-Fatura ve e-Arşiv için çoğu firma GİB'e doğrudan bağlanmak yerine bir özel entegratörün API'sini kullanır; her entegratörün test ortamı, belge biçimi ve iptal-iade akışı biraz farklıdır. Sanal POS tarafında (iyzico, PayTR veya bankanın kendi altyapısı) 3D Secure akışı, iade ve taksit senaryoları test edilir; canlıya geçiş için ödeme kuruluşunun üye işyeri başvurusunu ve kontrolünü tamamlaması gerekir. Logo veya Mikro gibi ERP'lerde ise asıl iş veri eşlemesidir: cari hesaplar, depolar, fiyat listeleri, birimler.

• Kodlama%30İstek-yanıt eşlemesi, kimlik doğrulama, temel akış.
• Test ortamı ve erişim%15Hesap, anahtar, IP izni; karşı tarafın yanıt süresine bağlı.
• Veri eşleme%20Kodlar, birimler, KDV oranları, adres alanları.
• Hata senaryoları%15Zaman aşımı, tekrar deneme, çift kaydı önleme (idempotency).
• Onay ve canlı doğrulama%20Sağlayıcı kontrolü, ilk gerçek işlemlerin izlenmesi.

Sık kullanılan entegrasyonların örnek bantları

Bu yüzden entegrasyonları hesaplayıcıda modüllerden ayrı tuttuk ve her biri için kodlama dışındaki günleri de içeren bantlar verdik. Bir entegrasyonun maliyetini kalem kalem çıkarmak isterseniz API entegrasyonu fiyatları yazımız bu konuyu ayrıntılı ele alıyor; ERP özelinde Logo ERP entegrasyonu rehberimiz var. Entegrasyonu ayrı bir iş paketi olarak yaptırmak istiyorsanız API geliştirme hizmetimize bakabilirsiniz.

Aşağıdaki hesaplayıcı yukarıdaki formülün birebir uygulamasıdır. Her kalem için üç noktalı tahmini PERT ile birleştirir, test ve proje yönetimi payını ekler, belirsizlik çarpanını keşif durumunuza göre uygular. Gün ücreti, ekip büyüklüğü ve işletim varsayımları sizindir; değiştirdikçe sonuç ve sol paneldeki özet anında güncellenir.

MVP (minimum viable product, en küçük işe yarar ürün) maliyetini düşürmenin yolu daha ucuz geliştirici bulmak değil, daha az şey geliştirmektir. Bütçenin büyük kısmı efordan geldiğine göre, eforu azaltan tek gerçek kaldıraç kapsamdır.

Kapsamı daraltırken MoSCoW önceliklendirmesini kullanıyoruz: her özelliği Must (olmazsa ürün işe yaramaz), Should (önemli ama ilk gün şart değil), Could (olsa iyi olur) ve Won't (bu sürümde yok) kutularından birine koyuyoruz. Kuralımız şu: ilk sürüm bütçesinin büyük kısmı Must kutusuna gitmeli, Could kutusu ise ilk sürümde boş kalabilmeli. Should kutusundakiler takvimde yer açılırsa girer.

• MustOlmadan ürün temel işini yapamaz.Örnek: Giriş, ana iş akışı (ör. randevu oluşturma), temel bildirim, yetki.
• ShouldÖnemli; geçici bir el çözümüyle ertelenebilir.Örnek: Excel dışa aktarım, toplu işlem, ikinci ödeme yöntemi.
• CouldDeneyimi güzelleştirir, kararı değiştirmez.Örnek: Karanlık tema, gelişmiş grafikler, kişiselleştirilmiş panel.
• Won'tBu sürümde yok; listede yazılı durur.Örnek: Çok dil, pazaryeri entegrasyonu, mobil uygulama.

MVP ile MMP (minimum marketable product, satılabilir ilk ürün) farkını da konuşmak gerekiyor. MVP bir varsayımı test eder: insanlar bu işi bu ekranla yapar mı? MMP ise para ödeyecek müşteriye çıkar; fatura, destek, KVKK aydınlatma metinleri, şifre sıfırlama gibi “sıkıcı” ama zorunlu işler burada girer. Yatırımcıya demo yapacaksanız MVP, ilk müşteriden ödeme alacaksanız MMP bütçeleyin.

Takvim de bütçeyle aynı yerden kısalır. Hesaplayıcıda Could ve Won't kutusundaki modülleri kaldırıp hafta sayısının nasıl düştüğüne bakın; MVP süresini konuşurken kimsenin ezberden verdiği haftaya değil, bu kırılıma güvenin. Çok kiracılık, abonelik ve kullanım ölçümünü ilk günden doğru kurmanın neden önemli olduğunu SaaS girişimleri için web yazılım sayfamızda anlattık. Mobil tarafta benzer bir kapsam tartışması için mobil uygulama yaptırma fiyatları yazısına bakabilirsiniz.

MVP bütçesini şişiren üç alışkanlık

• Yönetim paneli MVP'ye tam girerİlk aylarda veriyi veritabanı aracı veya basit bir iç ekranla yönetmek çoğu zaman yeter. Panel, en çok tekrarlanan işlem netleştikten sonra yazılmalı.
• “Sonra eklemesi zor” korkusuÇok dil gibi bazı kararlar baştan altyapı ister ama tamamı değil. Metinleri baştan çeviri dosyasında tutmak birkaç saattir; ikinci dili yayına almak ise ayrı bir iştir.
• Entegrasyonun MVP'de olması gerektiği varsayımıİlk 50 sipariş elle ERP'ye girilebilir. Entegrasyon, hacim kanıtlandığında yatırım olarak daha kolay savunulur.

Gün ücretini anlamak, teklifleri değerlendirmenin ve kendi ekip kurma hesabını yapmanın ön koşulu. Bir geliştiricinin şirkete maliyeti brüt maaşından fazladır, projeye verebildiği gün sayısı ise takvimdeki iş günlerinden azdır. İkisini birleştirince gerçek gün maliyeti çıkar.

1. ADIM 1Brüt maaşörnek 100.000 TL/ayKıdem ve teknolojiye göre çok değişir; kendi bandınızı kullanın.
2. ADIM 2+ İşveren payı≈ %21,75–23,75SGK ve işsizlik sigortası işveren payı; teşvike göre.
3. ADIM 3+ Yan hak, ekipmanörnek 10.000 TL/ayYemek, sağlık, donanım amortismanı, lisanslar.
4. ADIM 4÷ Verimli gün≈ 200 gün/yılTatil, izin, hastalık ve iç işler düşülmüş proje günü.

İşveren maliyeti. Brüt maaşın üzerine SGK işveren payı ve işsizlik sigortası işveren payı eklenir. 2026'da 7566 sayılı Kanun'la uzun vadeli sigorta işveren hissesi bir puan arttı; teşviksiz işveren payı SGK için yaklaşık %21,75, işsizlik sigortası için %2 oldu. Primlerini düzenli ödeyen, imalat dışı sektördeki bir yazılım şirketi 2 puanlık indirimden yararlanır ve toplam yük brütün yaklaşık %21,75'ine iner. Kısa vadeli sigorta oranı işin tehlike sınıfına göre değişir, teşvikler üst üste binebilir, yüksek maaşlarda da prime esas kazanç tavanı devreye girer. Kendi oranınızı mali müşavirinize doğrulatın; bu yazıdaki oranlar örnek hesap içindir.

Yan haklar ve ekipman. Yemek, ulaşım veya yol desteği, özel sağlık sigortası, dizüstü bilgisayarın amortismanı, geliştirme araçlarının ve bulut hesaplarının lisansları, ofis veya uzaktan çalışma desteği. Kişi başına aylık sabit bir tutar olarak düşünmek hesabı kolaylaştırır.

Verimli gün. 2026'da 365 günden 104 hafta sonu düşülünce 261 iş günü kalıyor. Hafta içine denk gelen resmî tatiller, arife yarım günleriyle birlikte 11,5 gün ediyor (bayramların hafta sonuna denk gelip gelmemesine göre bu sayı yıldan yıla birkaç gün oynar). Yıllık izin de İş Kanunu'na göre bir yılını dolduran çalışan için en az 14 gün; kıdem arttıkça uzar. Bunlar çıkınca 235 civarına inilir. Hastalık, eğitim, şirket içi toplantılar ve projeye yazılamayan işler de düşülünce projeye verilen gün yılda 190–210 arasında kalır.

Ajans veya yazılım firmasının gün ücreti bu maliyetin üzerine boşta kalan kapasiteyi (iki proje arasındaki günler), satış ve teklif hazırlama zamanını, yönetim giderlerini ve kârı ekler. Bu nedenle bir firmanın gün ücretinin, aynı kıdemdeki çalışanınızın gün maliyetinden yüksek olması normaldir; asıl karşılaştırma proje boyunca ve sonrasında toplam ne ödediğinizdir.

Türkiye'de maaşlar yılda en az bir kez, çoğu şirkette iki kez güncelleniyor. Altı aydan uzun sürecek bir projede gün ücretinin sabit mi olduğunu, yoksa belirli bir tarihte güncelleneceğini sözleşmede netleştirin. Döviz bazlı teklif alıyorsanız hangi kurun ve hangi tarihin esas alınacağı da yazılı olmalı.

Bu bölümde yalnız maliyete bakıyorum; hangi firmayla çalışılacağı ayrı bir konu ve onu yazılım firması seçerken dikkat edilmesi gerekenler yazısında ele aldık.

Kendi ekibinizin gün maliyeti çoğu zaman dışarıdan alınan gün ücretinden düşüktür. Buna rağmen toplam maliyet her zaman lehinize olmaz, çünkü kendi ekibinize iş olsun olmasın her ay ödersiniz. Dışarıdan çalıştığınızda ise yalnız kullandığınız günü ödersiniz. Karar, proje bittikten sonra ekibe ne kadar iş kalacağına bağlıdır.

Hesaba girmesi gereken ama sık unutulan kalemler şunlar: işe alım süresi (iyi bir kıdemli geliştiriciyi bulmak ve işe başlatmak aylar alabilir; bu sürede proje başlamaz), işe alım bedeli (danışmanlık firması komisyonu veya ilan ve mülakat zamanı), ekibin kıdem dengesi (tek kişilik ekipte o kişi izne çıktığında iş durur), bilgi sürekliliği (ekipten biri ayrıldığında bilgi de gider) ve proje bittiğinde ekibe ne olacağı.

• İşe alım gecikmesiEkip kurulana kadar proje başlamaz; pazara çıkış tarihi de o kadar kayar.
• Atıl kapasiteProje sonrası iş azalırsa maaşlar sürer; ödenen gün başına maliyet yükselir.
• Kıdem dengesiTek kişilik ekip, izin ve ayrılıkta durur. En az iki kişi ve kod inceleme kültürü gerekir.
• Bilgi sahipliğiDış kaynakta dokümantasyon ve kaynak kodun size devri sözleşmede yazılı olmalı; iç ekipte ise bilgiyi tek kişiye bağlamamak gerekir.

Aşağıdaki karşılaştırıcı bu kalemleri 36 aylık bir ufukta toplar. İç ekibin aylık sabit maliyetini, dış kaynağın proje ve sonrası için ödenen gün bedeliyle karşılaştırır ve kritik eşiği hesaplar: proje sonrası ayda kaç adam-gün iş sürekli varsa kendi ekibiniz daha ucuza gelir.

Pratikte en sık gördüğümüz sağlıklı model hibrit: ilk sürümü dış ekip yapar, bu sırada şirket bir ürün sahibi ve bir geliştirici işe alır, devir dönemi boyunca iki ekip birlikte çalışır. Böylece işe alım gecikmesi takvimi durdurmaz, bilgi de şirkette kalır. Teknik liderliği ayrıca dışarıdan almak isterseniz IT danışmanlık ücretleri ve CTO as a Service yazısı bu modeli anlatıyor.

Yayın günü bütçenin bittiği gün değildir. Bir web uygulaması canlıya çıktıktan sonra her ay barındırılır, izlenir, yedeklenir; kullandığı kütüphanelerin ve çatıların güvenlik güncellemeleri uygulanır; kullanıcıların talep ettiği küçük değişiklikler yapılır. Bunlar yapılmazsa sistem ilk yıl idare eder; ikinci yıl bir tarayıcı, PHP ya da Node.js sürüm yükseltmesinde bir yerden kırılır.

Bakım bedeli için piyasada geliştirme bedelinin belirli bir yüzdesi şeklinde oranlar dolaşıyor. Biz bu yazıda oran vermiyoruz, çünkü bakımın maliyeti geliştirme bedeline değil, sistemin ne kadar değiştiğine ve ne kadar kritik olduğuna bağlıdır. Hesaplayıcıda bakımı aylık adam-gün, yeni özellikleri ise yıllık bir bütçe payı olarak ayrı ayrı girmeniz bu yüzden.

Barındırma tarafında küçük bir iç araç tek bir sanal sunucuda rahatça çalışır; dışarıya açık, kampanya dönemlerinde yükü artan bir portal ise yük dengeleyici, ayrı veritabanı ve yedekli yapı ister. Sunucu modellerinin farkını web hosting, VPS, bulut ve dedicated karşılaştırmamızda anlattık; uygulamanız için yönetilen altyapı isterseniz bulut sunucu kiralama sayfamıza bakabilirsiniz.

Destek sözleşmesinde ilk yanıt süresi, çözüm hedefi ve hizmet saatleri gibi SLA ayrıntılarının nasıl okunacağını firma seçimi yazısında anlattığımız için burada tekrarlamıyorum. Bütçe açısından tek kural: bakım bedelini geliştirme teklifinin dipnotunda değil, ayrı bir satırda ve yıllık tutar olarak görün.

Periyodik güvenlik testinin kapsamını ve bütçesini güvenlik ve sızma testi sayfamızda bulabilirsiniz; yeni sürüm çıkmadan önce yapılan bir test, canlıda bulunan açığın maliyetinden her zaman düşüktür.

Toplam sahip olma maliyeti (TCO, total cost of ownership), bir sistemin satın alma veya geliştirme bedeline, belirli bir süre boyunca işletme ve geliştirme giderlerinin eklenmesiyle bulunur. Yazılım projelerinde üç yıl iyi bir ufuktur: ilk sürümün değerini kanıtlamasına yetecek kadar uzun, teknoloji ve iş süreçleri değişmeden önce karar verebilecek kadar kısadır.

Hesabı yıl yıl kuruyoruz. Yıl 0 geliştirme bedelidir. Yıl 1, 2 ve 3 ise barındırma, üçüncü taraf servisler, bakım havuzu ve yeni özellik bütçesinden oluşur. Hesaplayıcının alt bölümündeki yığılı çubuk grafiği bu dağılımı sizin girdilerinizle gösterir.

• Yıl 0Keşif, tasarım, geliştirme, test, yayın, eğitimTek seferlik; teklifteki ana rakam
• Yıl 1Barındırma, servisler, bakım havuzu, ilk geri bildirimlerin düzeltilmesiBakım talebi en yoğun yıl
• Yıl 2Barındırma, servisler, bakım, yeni özellikler, çatı sürüm yükseltmesiBüyük sürüm yükseltmesi genellikle bu dönemde gelir
• Yıl 3Barındırma, servisler, bakım, yeni özellikler, periyodik güvenlik testiYeniden yazma mı, iyileştirme mi kararının zamanı

Hazır bir SaaS aboneliğiyle kıyas yapmak istediğinizde, aboneliğin kullanıcı başına aylık bedeliyle üç yıllık toplamını aynı grafiğe koyun. Kullanıcı sayısı arttıkça abonelik doğrusal artar, özel yazılımın işletim gideri ise daha yavaş artar; iki eğrinin kesiştiği nokta kararın eşiğidir. Hazır yazılım mı özel yazılım mı sorusunun tamamını Excel yerine ne kullanılır yazısında ele alıyoruz; burada yalnız maliyet tarafını gösteriyoruz.

Yazılım tahminlerinde “belirsizlik konisi” olarak bilinen bir gözlem var: projenin başında yapılan tahmin, gerçek sonucun hem çok altında hem çok üstünde olabilir; kararlar verildikçe aralık daralır. Barry Boehm'in çalışmalarına dayanan ve Steve McConnell'in yaygınlaştırdığı hâliyle, yalnız bir fikir aşamasındaki tahmin gerçek eforun 0,25 katı ile 4 katı arasında olabilir; gereksinimler tamamlandığında aralık yaklaşık 0,67–1,5 kata, arayüz tasarımı bittiğinde 0,8–1,25 kata iner.

Önemli bir ayrıntı: koni kendiliğinden daralmaz. Zaman geçtiği için değil, kararlar verildiği için daralır. Kapsamı belirsiz kalan bir proje altıncı ayında da ilk günkü kadar belirsiz olabilir.

1. Fikir0,25× – 4×Tek paragraflık tarif
2. Ürün tanımı0,5× – 2×Hedef kullanıcı ve ana işler belli
3. Gereksinimler0,67× – 1,5×Senaryolar ve kurallar yazılı
4. Arayüz tasarımı0,8× – 1,25×Ekran akışları onaylı
5. Ayrıntılı tasarım0,9× – 1,1×Veri modeli ve entegrasyon ayrıntısı hazır

Hesaplayıcıdaki çarpanlar koninin uç değerlerinden dardır, çünkü en azından yazılı bir ihtiyaç listesi olduğunu varsayar: keşif yapılmadıysa 0,8–1,6, yapıldıysa 0,9–1,25. Keşif aşaması bu yüzden bir masraf değil, risk payını küçültmenin en ucuz yoludur. Bir iki haftalık keşif; kullanıcı senaryolarını, ekran listesini, entegrasyonların teknik durumunu ve kabul kriterlerini yazılı hâle getirir.

Keşfin ayrı ücretlendirilmesi de bu yüzden mantıklıdır: keşif çıktısı (gereksinim dokümanı, ekran akışları, mimari karar notları) size aittir ve isterseniz başka bir ekiple de projeye devam edebilirsiniz. Bu tür bağımsız çalışmalar için teknik danışmanlık hizmetimiz var.

Bütçe dar olduğunda ilk akla gelen gün ücretini pazarlık etmek oluyor. Bu genellikle ya daha az deneyimli bir ekip ya da teklifte görünmeyen kısıntılar demek. Aşağıdaki yöntemler ise eforu azaltır; her birinin bir bedeli olduğu için yanına neyi kaybettiğinizi de yazdım.

1. 1Hazır bileşen kullanınKimlik doğrulama, ödeme formu, dosya depolama ve e-posta gönderimi için olgun servis ve kütüphaneler var.BedeliSağlayıcıya bağımlılık ve aylık servis bedeli; çıkış planı yazılı olmalı.
2. 2Hazır UI kit ile başlayınÖzel tasarım sistemi yerine marka renklerine uyarlanmış bir bileşen kütüphanesi ekran başına eforu belirgin düşürür.BedeliArayüz rakiplerinize benzeyebilir; fark yaratmak istediğiniz ekranları özel tasarlayın.
3. 3Aşamalı teslim edinİlk sürümü Must kutusuyla sınırlayın, Should kutusunu ikinci sürüme planlayın.Bedeliİkinci sürüm bütçesi ayrıca onaylanmalı; ara dönemde el çözümleri sürer.
4. 4Entegrasyonu erteleyinHacim düşükken veriyi dışa aktarım dosyasıyla veya elle aktarın.BedeliElle iş hata üretir; ertelemenin bitiş tarihini baştan belirleyin.
5. 5Yönetim panelini sade tutunİlk aşamada yalnız en sık yapılan işlemler için panel yazın.BedeliSeyrek işlemler için teknik ekibe bağımlı kalırsınız.
6. 6İçerik girişini üstleninÜrün açıklamaları, kategori ağacı ve veri temizliği gibi işleri kendi ekibiniz yapsın.BedeliTakvim sizin ekibinizin hızına bağlanır.
7. 7İlk sürümde tek dilMetinleri baştan çeviri dosyasında tutup ikinci dili sonra açın.BedeliYurt dışı müşteri ilk günden varsa erteleme anlamsızdır.

Bir yazılım bütçesi yönetim kuruluna ya da satın almaya gittiğinde ilk sorular hep aynıdır: Ne alıyoruz, ne kadar tutacak, neden bu kadar? Tek bir rakam ve “firma böyle dedi” cümlesi bu soruların hiçbirini yanıtlamaz. Aşağıdaki şablon, hesaplayıcıdaki seçimlerinizle otomatik dolar; kopyalayıp kendi belgenize yapıştırabilirsiniz.

Şablonda bilinçli olarak tek rakam değil üç rakam var: en az, olası ve en çok. Onay isterken olası değeri bütçe, olası ile en çok arasındaki farkı ise ayrı onaylanan risk payı olarak sunmanızı öneririm. Böylece risk payı kullanılmazsa şirkette kalır, kullanılırsa sürpriz olmaz.

“Ölçülecek kazanç” başlığını boş bırakmayın. Yazılımın neyi değiştireceği (elle girilen sipariş sayısı, rapor hazırlama süresi, hatalı fatura oranı) bugünkü değeriyle yazılırsa, üç yıl sonra yatırımın işe yarayıp yaramadığını konuşabilirsiniz.

YAZILIM BÜTÇE TALEBİ: [Proje adı]
Hazırlayan: [Ad Soyad, birim]   Tarih: [gg.aa.yyyy]

1. KAPSAM ÖZETİ
   Proje tipi: Dahili araç · Kullanıcı rolü: 3 · Ekran: 15
   Modüller:
   - Kimlik doğrulama ve rol yetkisi (RBAC)
   - Yönetim paneli
   - Raporlama ve dışa aktarım
   - Bildirimler (e-posta, SMS, uygulama içi)
   - Denetim izi (audit log)
   Entegrasyonlar:
   - ERP / muhasebe (Logo, Mikro vb.)
   Tasarım: Hazır UI kit uyarlaması · Test kapsamı: Standart

2. VARSAYIMLAR
   - Ortalama gün ücreti: 10.000 TL (KDV hariç)
   - Ekip: 3 kişi
   - Keşif aşaması: yapılmadı → belirsizlik çarpanı 0,8–1,6
   - Efor bantları örnektir; firma tekliflerinin adam-gün kırılımıyla güncellenecektir.

3. GELİŞTİRME BÜTÇESİ (KDV HARİÇ)
   Efor: 101 / 126 / 202 adam-gün (en az / olası / en çok)
   - En az:  1.009.853 TL
   - Olası:  1.262.317 TL   ← onay istenen bütçe
   - En çok: 2.019.706 TL
   - Ayrı onaylanacak risk payı (en çok − olası): 757.390 TL
   - KDV (%20, olası tutar üzerinden): 252.463 TL
   - Tahmini takvim: 9–18 hafta

4. BÜTÇEYİ EN ÇOK BÜYÜTEN KALEMLER
   1. 15 ekran (liste, form, detay): ≈ 25 adam-gün (%20)
   2. Test ve hata düzeltme (standart): ≈ 16 adam-gün (%13)
   3. ERP / muhasebe (Logo, Mikro vb.): ≈ 15 adam-gün (%12)

5. YILLIK İŞLETİM GİDERİ
   - Barındırma: 36.000 TL
   - Üçüncü taraf servisler: 12.000 TL
   - Bakım havuzu (2 gün/ay): 240.000 TL
   - Yeni özellik payı (%15): 189.347 TL
   Toplam: 477.347 TL / yıl

6. 3 YILLIK TOPLAM SAHİP OLMA MALİYETİ: 2.694.359 TL
   Yıl 0: 1.262.317 TL · Yıl 1–3: her yıl 477.347 TL

7. ÖLÇÜLECEK KAZANÇ (BUGÜNKÜ DEĞERLER)
   - [ör. elle girilen sipariş sayısı / ay: ...]
   - [ör. aylık rapor hazırlama süresi: ... saat]
   - [ör. hatalı fatura veya sevkiyat oranı: ...]

8. TESLİM EDİLECEKLER (TEKLİFTE YAZILI OLMALI)
   - Kaynak kodun tamamı ve sürüm geçmişi
   - Teknik dokümantasyon: API referansı, mimari diyagramlar, kurulum kılavuzu
   - Birim ve uçtan uca test sonuçları ile kapsam raporu
   - Tasarım kaynak dosyaları
   - Docker, CI/CD ve ortam yapılandırması
   - Ekip eğitimi ve 30 günlük garanti desteği

9. RİSKLER VE AÇIK SORULAR
   - Entegrasyon test ortamlarına erişim ve sorumlusu
   - Kapsam değişikliği talep süreci ve onay yetkisi
   - Gün ücretinin güncellenme tarihi (enflasyon / kur)

Teklif aldığınız firmadan teslim edilecekleri de yazılı isteyin. Bizim web yazılım geliştirme projelerimizde teslim listesi şunlardır:

• ✓Kaynak kodun tamamı ve sürüm geçmişi
• ✓Teknik dokümantasyon: API referansı, mimari diyagramlar, kurulum kılavuzu
• ✓Birim ve uçtan uca test sonuçları ile kapsam raporu
• ✓Tasarım kaynak dosyaları
• ✓Docker, CI/CD ve ortam yapılandırması
• ✓Ekip eğitimi ve 30 günlük garanti desteği