Yazılım projesi maliyeti; kapsamın büyüklüğüne, entegre edilecek sistem sayısına, kullanıcı rolleri ve yetkilerine, platforma (web, mobil), veri taşıma ve test ihtiyacına ve canlıya alındıktan sonraki bakım yüküne göre belirlenir. Bu yüzden ihtiyaç analizi yapılmadan "bir yazılım kaça olur?" sorusuna verilen her cevap tahmindir.
Doğru bütçe; kapsamı yazılı hale getirip aşamalara bölen, her aşamanın bedelini ayrı gösteren ve bakım maliyetini de hesaba katan bir teklifle ortaya çıkar. Aşağıda yazılım fiyatlarını belirleyen 8 kalemi, fiyatlama modellerini ve teklifleri doğru karşılaştırmanın yolunu anlatıyoruz.
Aynı iş için neden birbirinden çok farklı teklifler geliyor?
Bir yazılım projesi için üç firmadan teklif isteyen bir işletme sahibinin en sık yaşadığı şaşkınlık, tekliflerin arasındaki büyük farktır. Oysa çoğu durumda firmalar aynı işi fiyatlamıyordur. Bir teklif yalnızca ekranları ve temel kayıt işlemlerini kapsar, diğeri muhasebe entegrasyonunu, mobil uygulamayı ve eski verilerin taşınmasını da içine alır. Üçüncüsü ise belirsiz kalan her noktayı riske karşı fiyatına eklemiştir.
Basit bir örnek: Bir toptancı, sahadaki satış temsilcilerinin sipariş alabileceği bir uygulama istiyor. İlk firma yalnızca sipariş formunu ve bir yönetim listesini fiyatlıyor. İkinci firma, temsilcinin müşteriye özel fiyat listesini görmesini, stok bilgisinin muhasebe programından anlık çekilmesini ve internetin olmadığı depoda da sipariş girilebilmesini kapsama almış.
Üçüncü firma bu konulardan hiç söz etmemiş ama fiyatına belirsizlik payı eklemiş. Üç teklif de "sipariş uygulaması" başlığını taşıyor; oysa ikinci teklifteki iş, birinciden birkaç kat büyük.
Talep ne kadar belirsizse teklifler o kadar dağınık olur. "Bize bir sipariş takip programı lazım" cümlesi, kimi firma için birkaç haftalık, kimi firma için aylar süren bir işi tarif eder. Maliyeti anlamanın yolu, fiyatı değil kapsamı karşılaştırmaktan geçer.
Bütçe aşımının gerçek maliyeti
Yazılım projelerinde asıl pahalı olan, baştaki bedel değil, yolda ortaya çıkan ek bedeldir. Kurumsal yazılım projelerinin en iyi ölçülen türü olan ERP'de tablo şöyle:
Panorama Consulting Group'un 2026 ERP Raporu'na göre katılımcıların dörtte birinden fazlası projesinin bütçeyi aştığını, dörtte birine yakını takvimin gerisinde kaldığını bildirdi; medyan proje süresi 9 ay oldu.
Aynı rapora göre bütçe aşımının en yaygın nedeni beklenmedik ek teknoloji ihtiyacı, takvim aşımının en yaygın nedeni ise kurumsal (organizasyonel) sorunlar. Yani fazladan ödenen bedelin kaynağı çoğu zaman kötü kod değil; başta öngörülmeyen bir entegrasyon, geç verilen bir karar ya da proje sırasında değişen bir ihtiyaçtır. ERP'ye özgü maliyet kalemlerini ERP fiyatlarını belirleyen etkenler yazısında ayrıca açtık.
Daha geniş ölçekte de sonuç benzer. BCG'nin 2020 tarihli "Flipping the Odds of Digital Transformation Success" araştırmasına göre dijital dönüşümlerin %70'i hedeflerinin gerisinde kaldı; yalnızca %30'u hedeflenen değere ulaşıp kalıcı değişim sağladı. Hedefe ulaşmayan bir projenin maliyeti yalnızca harcanan para değil, o süre boyunca elde edilemeyen verimliliktir.
"Kendi yazılımcımızı alalım, daha ucuz olur" seçeneği de her zaman sanıldığı kadar kolay değildir. TÜİK Girişimlerde Bilişim Teknolojileri Kullanım Araştırması 2026 verisine göre 10 ve daha fazla çalışanı olan girişimlerden bilgi ve iletişim teknolojileri uzmanı işe alan ya da almayı deneyenlerin %31,7'si işe alım sürecinde güçlük yaşadı. İç ekip kurmanın maliyeti maaşla sınırlı değildir; işe alım süresi, tek kişiye bağımlılık ve o kişi ayrıldığında kaybolan bilgi de hesaba katılmalıdır.
Dış bir firmayla çalışacaksanız yazılım firması seçerken bakılacak kriterleri derledik.
Yazılım projesi maliyetini belirleyen 8 kalem
- Kapsam ve iş kuralları. Kaç ekran, kaç süreç, kaç istisna? Bir sipariş formu basittir; siparişe göre değişen fiyat, stok rezervasyonu ve onay kuralları işi katlar.
- Kullanıcı rolleri ve yetkiler. Herkesin her şeyi gördüğü bir sistem ile departman, şube ve rol bazında yetki ayrılan bir sistem arasında ciddi iş farkı vardır.
- Entegrasyonlar. Muhasebe/ERP, e-Fatura entegratörü, e-ticaret sitesi, kargo firması, banka... Her bağlantı ayrı bir analiz, geliştirme ve test demektir; bunun ayrıntılarını API entegrasyonu hizmetimizde anlatıyoruz.
- Platform. Yalnızca web paneli mi, yoksa sahada kullanılacak bir mobil uygulama da mı gerekiyor? Çevrimdışı çalışma ihtiyacı mobil tarafın maliyetini belirgin biçimde etkiler. Teknoloji seçiminin maliyete etkisini native mi cross-platform mu yazımızda anlattık; mobil tarafın kalemlerini mobil uygulama maliyeti yazısında ayrıntılandırdık.
- Veri taşıma. Eski programdaki ya da Excel dosyalarındaki verinin temizlenip yeni sisteme aktarılması çoğu teklifte unutulan, ama zaman alan bir iştir. Temizliğin nasıl yapılacağını veri kalitesi ve mükerrer kayıt yazımızda anlattık.
- Raporlama. Standart listeler ucuzdur; yönetime özel gösterge panoları, dönem karşılaştırmaları ve dışa aktarma seçenekleri ayrı iş kalemleridir.
- Donanım. Barkod okuyucu, saha terminali, sensör ya da özel bir cihaz gerekiyorsa donanım, montaj ve sahadaki test süreci maliyete eklenir.
- Bakım, barındırma ve destek. Sunucu ya da bulut gideri, güvenlik güncellemeleri, küçük değişiklik talepleri ve destek hizmeti, projenin ilk bedelinden ayrı ama kalıcı bir maliyettir. Bulut barındırmanın gerçek maliyetini bulut geçişi maliyeti yazımızda ele aldık.
Fiyatlama modelleri: hangisi size uygun?
| Model | Nasıl işler | Ne zaman uygun | Dikkat edilecek nokta |
|---|---|---|---|
| Sabit fiyat | Tanımlı kapsam için tek bedel | Kapsam net ve yazılıysa | Kapsam dışı her talep ek teklif gerektirir |
| Zaman ve malzeme | Harcanan emek kadar ödeme | Kapsam belirsiz, keşif gerekiyorsa | Düzenli raporlama ve üst sınır şarttır |
| Aşamalı (fazlı) | Her aşama ayrı kapsam ve bedelle | Orta ve büyük projelerde | İlk aşama kendi başına değer üretmeli |
| Abonelik | Aylık/yıllık kullanım bedeli | Hazır platform ve SaaS ürünlerde | Veriyi dışa alma koşulları netleşmeli |
Orta ölçekli işletmeler için genellikle en sağlıklı model aşamalı olandır: ilk aşamada en çok değer üreten iş canlıya alınır, sonraki aşamalar gerçek kullanım deneyimine göre şekillenir. Böylece ilk bütçe küçük kalır ve "yanlış şeyi eksiksiz yapma" riski azalır.
Abonelik modeli ise herkesin aynı biçimde ihtiyaç duyduğu standart işler için uygundur. Örneğin kurumsal e-posta ve dosya yönetimini tek panelde toplayan Smart360 kurulum gerektirmez, aylık ya da yıllık ödemeyle kullanılır. Bu tür ihtiyaçlar için ayrı bir yazılım projesi bütçelemek gerekmez; proje bütçesini sizi farklılaştıran işlere ayırabilirsiniz. Abonelik ile lisanslı kurulumun beş yıllık farkını SaaS mı kurulu yazılım mı yazısında karşılaştırdık.
Model seçimi kadar önemli olan bir konu daha var: değişiklik talebinin nasıl yönetileceği. Proje sırasında yeni fikirlerin çıkması doğaldır; kullanıcılar sistemi görmeye başlamış demektir. Sorun, bu fikirlerin sözlü olarak kapsama eklenmesidir. Her değişikliğin yazılı bir talep, süre ve bedel etkisinin yazılı bir değerlendirmesi ve karar vericinin onayıyla işleme alınması, bütçeyi kontrol altında tutmanın en basit yoludur.
Bütçe aşımı çoğu zaman proje bitince değil, ara teslimlerde fark edilebilir. Her aşama sonunda harcanan emeği, tamamlanan kapsamı ve açık değişiklik taleplerini karşılaştıran bir durum raporu istemek, sapmayı erken yakalatır; bunun nasıl yapılacağını yazılım projesinde yüklenici denetimi yazısında anlattık.
Yapay zeka bileşeni içeren projelerde maliyetin yapısı biraz farklıdır: veri hazırlama, model denemeleri ve doğruluk ölçümü klasik ekran geliştirmeden daha fazla pay alır, getirisi de pilotta ölçülerek belirlenir. Bütçeyi ve beklenen getiriyi birlikte kurmanın yolunu yapay zeka projesinde ROI yazısında ele aldık.
Yazılım teklifi karşılaştırma: kapsamı yan yana koyun
Teklifleri karşılaştırmanın ilk kuralı, tüm firmalara aynı yazılı talebi göndermektir. Kapsamı ölçülebilir gereksinimlere ve kabul kriterlerine döken bir teknik şartname, gelen tekliflerin aynı işi fiyatlamasını sağlar. Teklifler geldikten sonra toplam rakamı değil, kalemleri aynı tabloya yazın:
| Kalem | Teklif A | Teklif B | Teklif C |
|---|---|---|---|
| Kapsam madde madde yazılmış mı? | |||
| Entegrasyonlar ayrı kalem mi? | |||
| Veri taşıma ve test dahil mi? | |||
| Aşamalar ve her aşamanın bedeli ayrı mı? | |||
| Kabul kriteri tanımlı mı? | |||
| Bakım ve destek bedeli, kapsamı ve yanıt süresi belli mi? | |||
| Kaynak kod, dokümantasyon ve veri kime ait? |
Boş kalan her hücre, sonradan ek teklif olarak dönebilecek bir belirsizliktir. Tabloyu doldururken şu sorulara da bakın:
- Kapsam madde madde yazılmış mı, yoksa "sipariş modülü" gibi tek satırlık başlıklar mı var?
- Entegrasyonlar, veri taşıma ve test ayrı kalem olarak gösterilmiş mi?
- Kabul kriteri tanımlı mı? Bir aşamanın "bitti" sayılması neye bağlı?
- Canlıya aldıktan sonraki bakım ve destek bedeli ve kapsamı belli mi?
- Kaynak kod, dokümantasyon ve veritabanı erişimi kime ait? Bu maddeyi yazılım sözleşmesi ve kaynak kodu yazımızda ayrıntılı anlattık.
Bu sorulara net cevap veremeyen bir teklif, ucuz görünse bile en pahalı seçenek olabilir. Satın alma sürecinin diğer adımlarını ve iş sistemlerine dair rehberleri Yazılım Geliştirme yazılarımızın tamamında bulabilirsiniz. Özel yazılım ile hazır paketin toplam maliyetini karşılaştırmak istiyorsanız özel yazılım mı hazır paket mi rehberimize göz atın; kapsamı teklif istemeden önce netleştirmenin adımlarını ise yazılım ihtiyaç analizi yazımızda anlattık.
Digital Bridge'de maliyeti nasıl netleştiriyoruz?
Maliyet sürprizlerinin çoğu belirsiz kapsamdan doğduğu için teklif sürecimizi kapsamı netleştirmek üzerine kurduk:
- Önce ihtiyaç analizi. Süreçlerinizi, mevcut programlarınızı ve entegrasyon noktalarını inceliyoruz. Proje işlerinde hazır paket satmadığımız için analiz, sizi belirli bir ürüne yönlendirmek için değil, gerçekten neyin geliştirilmesi gerektiğini ortaya çıkarmak için yapılır.
- Yazılı teklif: kapsam, aşamalar, bedel. Her aşamanın neyi kapsadığı ve bedeli teklifte ayrı ayrı yer alır; kapsam dışında kalanlar da açıkça yazılır.
- Web, mobil ve entegrasyon tek ekipte. Özel web yazılımları, mobil uygulama ve entegrasyon işlerini aynı ekip yürüttüğü için arayüzler arasındaki "bu bizim işimiz değil" boşlukları oluşmaz.
- Donanım gerekiyorsa ücretsiz teknik fizibilite. Projede özel bir cihaz, terminal ya da sensör gerekiyorsa cihaz imalatı ve IoT tarafında teknik fizibiliteyi ücretsiz yapıyor, donanım maliyetini yazılım kalemleriyle birlikte gösteriyoruz.
- Canlıya aldıktan sonra da yanınızdayız. Teknik destek 7/24 erişilebilir; bakım kapsamı teklifte ayrıca tanımlanır.
Tüm hizmet alanlarımızı yazılım çözümleri sayfamızda bulabilirsiniz.
Sonraki adım
Bütçe konuşmasına başlamadan önce üç şeyi yazıya dökün: yazılımın çözmesini istediğiniz en önemli üç sorun, konuşması gereken mevcut sistemler ve ilk aşamada mutlaka olması gerekenler. Bu kısa not bile teklifler arasındaki farkı büyük ölçüde azaltır. Notunuzu hazırladıktan sonra bizimle iletişime geçin; kapsamı birlikte netleştirip aşamalara bölünmüş, yazılı bir teklif hazırlayalım.