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.
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.
- 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.
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 ve çoğu zaman iyi bir işarettir; 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, etkisinin (süre ve bedel) 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.
Teklifleri doğru karşılaştırmanın yolu
Teklifleri karşılaştırırken toplam rakama değil, şu sorulara 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. Ö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.