Özel yazılım maliyeti, yazılan satır sayısıyla değil çözülen işin karmaşıklığıyla belirlenir. Kaç kullanıcı rolü olacak, kaç ekran çizilecek, hangi sistemlerle konuşacak, eski verileriniz taşınacak mı? Bunlar netleştiğinde rakam da netleşir. Rakamlar 45.000 ₺’den başlıyor; üst sınırı ise tamamen kapsam çiziyor. Aşağıda o kapsamı oluşturan kalemleri tek tek açtık.
Hazır paket yazılım mı, özel yazılım mı almalıyım?
Doğru cevap her zaman özel geliştirme değildir. Muhasebe, e-posta ya da basit stok takibi gibi standartlaşmış ihtiyaçlarda hazır ürünler binlerce firmayla yıllar içinde olgunlaşmıştır; aynı olgunluğu sıfırdan üretmek ne akıllıca ne de ekonomiktir.
Ölçüt şudur: yaptığınız iş sektördeki herkesin yaptığı gibiyse hazır çözüm alın. İşinizin fark yarattığı, size özgü bir hesaplamanın, akışın ya da kuralın bulunduğu yerde hazır ürün sizi kendi kalıbına sokmaya çalışır.
Hazır çözüm hangi noktada yetmemeye başlar?
- Programın yapamadığı işi tablo dosyalarında yapıp sonucu tekrar programa giriyorsanız.
- Aynı bilgiyi iki ayrı sisteme elle yazan bir çalışanınız varsa.
- Kullanıcı başına aylık lisans bedelleri, tek seferlik bir geliştirme bütçesini geçmeye başladıysa.
- İhtiyaç duyduğunuz raporu hiçbir menüde bulamayıp dışarı aktararak elle hazırlıyorsanız.
- Müşterinize veremediğiniz bir hizmet, sırf programınız desteklemediği için askıda kalıyorsa.
Bu maddelerden ikisi bile geçerliyse ödediğiniz görünmez bedel zaten bir geliştirme bütçesine yaklaşmış demektir. Özel yazılım tarafında amaç yeni bir program sahibi olmak değil, bu görünmez bedeli ortadan kaldırmaktır.
Maliyeti belirleyen gerçek etkenler neler?
Kullanıcı rolü sayısı
Herkesin aynı ekranı gördüğü bir sistemle; yöneticinin, saha ekibinin, muhasebenin ve müşterinin farklı yetkilerle girdiği bir sistem arasında kat kat fark vardır. Her yeni rol, ayrı ekranlar ve ayrı yetki denetimleri anlamına gelir.
Ekran ve akış sayısı
Kapsamın en somut ölçüsü budur. Kaç liste, kaç form ve kaç detay sayfası olacağını çıkarmak, tahmini rakamdan gerçek rakama geçmenin en hızlı yoludur.
Entegrasyonlar
Başka bir sisteme bağlanmanın maliyeti; o sistemin belgelendirmesine, test ortamı sunup sunmadığına ve hata durumunda ne döndürdüğüne bağlıdır. İyi belgelenmiş bir servise bağlanmak kısa sürer, belgesiz ya da çok eski bir sisteme bağlanmak projenin en riskli parçası olabilir. Teklif alırken karşı tarafın bu bağlantıyı daha önce kurup kurmadığını sormak, sürprizleri baştan azaltır.
Veri göçü
Yıllardır biriken kayıtların yeni ortama taşınması çoğu zaman hafife alınır. Eski verinin içinde tekrarlanan kayıtlar, boş alanlar ve tutarsız yazımlar bulunur; bunların temizlenmesi ve eşlenmesi başlı başına bir iştir. Aynı müşterinin üç ayrı biçimde kaydedilmiş olması, tarihlerin farklı düzenlerde girilmesi ya da zorunlu bir alanın yıllarca boş bırakılmış olması sık karşılaşılan durumlardır. Ne kadarının taşınacağına baştan karar vermek de bir seçenektir: bazen son iki yılı taşıyıp gerisini arşivde tutmak hem daha ucuz hem daha temiz bir başlangıç sağlar.
Raporlama
Sabit birkaç çıktı ile kullanıcının kendi filtresini kurabildiği esnek raporlama arasında büyük fark vardır. Esnek raporlama hem arayüz hem performans tarafında ek çalışma ister.
Mobil ihtiyaç
Sahada çalışan ekipler için telefondan erişim şart olabilir. Burada da tarayıcıdan açılan mobil uyumlu bir arayüz ile mağazalarda yayınlanan ayrı bir uygulama arasında ciddi bütçe farkı vardır.
Hangi modül kapsama ne ekliyor?
| Modül veya özellik | Kapsama eklediği iş | Efor düzeyi |
|---|---|---|
| Giriş ve yetkilendirme | Rol tanımları, şifre sıfırlama, oturum güvenliği | Düşük–orta |
| Temel kayıt ekranları | Her veri türü için listeleme, ekleme, düzenleme, silme | Orta |
| Belge ve dosya yönetimi | Yükleme, sürüm takibi, tür ve boyut denetimi, depolama | Orta |
| Çok aşamalı onay akışı | Durum yönetimi, geri gönderme, bildirim, işlem geçmişi | Yüksek |
| Muhasebe veya kaynak planlama bağlantısı | Karşı sistemin kuralları, hata senaryoları, mutabakat kontrolleri | Yüksek |
| Ödeme altyapısı bağlantısı | Sağlayıcı testleri, başarısız işlem senaryoları, iade akışı | Yüksek |
| Eski sistemden veri aktarımı | Temizlik, alan eşleme, doğrulama ve geri dönüş planı | Orta–yüksek |
| Esnek raporlar ve dışa aktarım | Filtre kombinasyonları, performans ayarı, tablo çıktısı | Orta–yüksek |
| Bildirim gönderimi | Şablon yönetimi, gönderim sağlayıcısı, kuyruk ve tekrar deneme | Düşük–orta |
| Mağazada yayınlanan mobil uygulama | Ayrı arayüz, cihaz testleri, yayın ve güncelleme süreçleri | Yüksek |
| Birden fazla dil desteği | Metin yönetimi, tarih ve para birimi biçimleri, çeviri döngüsü | Orta |
Tablodaki düzeyler göreceli bir sıralamadır; kesin süre ancak sizin akışınız yazıya döküldükten sonra çıkar. Amacı, bir isteğin fiyata neden dokunduğunu görünür kılmaktır.
Neden saat başı değil kapsam üzerinden fiyat veriliyor?
Saatlik hesapta iki taraf da yanlış şeyi izler. Siz harcanan zamanı denetlemeye çalışırsınız, geliştirici ise işi hızlı bitirdiğinde daha az kazanacağı bir düzenin içinde kalır. Kapsam üzerinden anlaşıldığında konuşulan şey sonuçtur: hangi ekranlar, hangi kurallar, hangi teslim tarihleri.
Bu yöntemin tek şartı, kapsamın yazılı olmasıdır. Neyin dahil neyin hariç olduğu maddeler hâlinde belirtilmezse her ek istek tartışmaya dönüşür. Sağlıklı yol, önce kısa bir analiz aşaması yapıp kapsamı birlikte çıkarmak, sonra sabit fiyatlı teklifi bu belge üzerinden vermektir.
MVP ile başlamak neden mantıklı?
MVP, işi ayakta tutan en küçük çalışır sürüm demektir. Bütün hayalleri ilk sürüme sıkıştırmak yerine günlük işinizin döndüğü çekirdek akışı önce yayına alırsınız. Burada zor olan teknik kısım değil, neyin ilk sürümde yer almayacağına karar verebilmektir.
Bunun üç somut faydası var. Birincisi, para bir kerede değil aşamalı harcanır. İkincisi, gerçek kullanıcılar sistemi kullanmaya başladığında istek listesi değişir; pratikte baştan vazgeçilmez denen özelliklerin bir kısmına hiç dokunulmadığı görülür. Üçüncüsü, yatırımın karşılığını sonuna kadar beklemeden görmeye başlarsınız.
Aynı mantık e-ticaret projelerinde de geçerlidir: önce satış yapan sade bir yapı, ardından kampanya ve otomasyon katmanları.
Proje hangi aşamalardan geçiyor?
Aşamaları bilmek, bütçenin nereye gittiğini anlamanın en kolay yoludur. Sıralama kabaca şöyle işler.
- Süreç çıkarma: Bugün işin nasıl döndüğü, kimin neyi hangi sırayla yaptığı yazıya dökülür. Burada çoğu firma kendi akışındaki gereksiz adımları ilk kez fark eder.
- Kapsam belgesi: Ekranlar, roller ve kurallar maddeler hâlinde listelenir. Sabit fiyat bu belgeye dayanır.
- Arayüz taslakları: Kod yazılmadan önce ekranların kaba çizimleri onaylanır; bu aşamada yapılan değişiklik en ucuz değişikliktir.
- Geliştirme: Parçalar hâlinde ilerlenir ve her parça bittiğinde size gösterilir.
- Test ve gerçek veriyle deneme: Sistem, uydurma kayıtlarla değil kendi verinizle sınanır.
- Devreye alma ve eğitim: Ekibin sistemi kullanmaya başlaması, çoğu projede teknik kısımdan daha çok emek ister.
Bu adımların atlanması ilk bakışta zaman kazandırır, sonra iki katı süre kaybettirir. Özellikle taslak onayı olmadan başlanan işlerde, ekranlar bittikten sonra gelen düzeltmeler bütçenin en büyük düşmanıdır.
Yatırım kendini ne zaman çıkarır?
Basit bir hesap işinizi görür. Bir işi elle yapmak ayda kaç saat alıyor, o saatin işletmenize maliyeti ne, sistem kurulduğunda bunun ne kadarı ortadan kalkıyor? Buna bir de hata maliyetini ekleyin: yanlış girilen bir sipariş, kaçırılan bir teslim tarihi ya da iki kez faturalanan bir hizmet, çoğu zaman geliştirme bedelinden daha pahalıya patlar.
Geri dönüş süresi işletmeden işletmeye değişir, ama karar verirken bakılacak şey rakamın büyüklüğü değil, karşılığında ortadan kalkan yükün büyüklüğüdür. Hiçbir işi hızlandırmayan bir sistem ucuz da olsa pahalıdır. Bu hesabı yapmadan teklif toplamak, aslında neyi satın aldığınızı bilmeden pazarlık etmek anlamına gelir; oysa iki saatlik bir hesap bile size hangi modülün öncelikli olduğunu net biçimde gösterir.
Teslimden sonra masraf devam eder mi?
Eder ve bu bir aksaklık değil, işin doğasıdır. Sunucu tarafı güncellenir, güvenlik yamaları çıkar, bağlandığınız sistemler kendi arayüzlerini değiştirir, mevzuat değişir, ekibiniz yeni ihtiyaçlar getirir. Bunları karşılayan sürekli bir bakım ve destek ilişkisi aylık 2.500 ₺’lik bir kalemdir; barındırma ve alan adı tarafı yıllık 3.900 ₺ civarında ayrıca yer tutar.
Bakım anlaşmasını gider değil, sistemin çalışır kalmasının bedeli olarak görmek daha doğru. Yıllık planını yaparken geliştirme bedelinin yanına belirli bir iyileştirme payı ayıran işletmeler ikinci yılda çok daha rahat ediyor.
Kaynak kod ve veriler kime ait olacak?
Bu, sözleşmede en net yazılması gereken maddedir. Sorulacaklar basittir: kaynak kod teslim edilecek mi, hangi kod deposunda tutulacak, veri tabanının yedeğini istediğiniz an alabilecek misiniz, sunucu hesapları kimin adına açılacak, kullanılan üçüncü taraf bileşenlerin lisansları ne durumda?
Bu soruların cevabı yazılı değilse ilerideki her taşınma pazarlık konusu olur. Ayrıntısını kaynak kodun kime ait olduğu yazımızda ele aldık.
“Yazılım bitti mi?” neden doğru soru değil?
Çünkü yazılım, tamamlanıp anahtarı teslim edilen bir bina değil, işinizle birlikte yaşayan bir araçtır. İşiniz değiştikçe onun da değişmesi gerekir; değişmeyen bir sistem birkaç yıl içinde ekibin etrafından dolandığı bir engele dönüşür.
Daha faydalı sorular şunlardır: hangi sürüm ne zaman yayına giriyor, bu sürüm hangi işi çözüyor, önümüzdeki üç ayda ne planlanıyor ve bir aksaklıkta kime kaç saat içinde ulaşıyorum? Bu sorulara cevap veren bir çalışma düzeni, bitip bitmediği sorusunu gereksiz kılar.
Özetle bütçe; rol sayısı, ekran sayısı, entegrasyonlar, veri göçü ve raporlama beklentinizin toplamıdır. Kapsamı yazıya dökmek bu kalemleri hem görünür hem pazarlık edilebilir hâle getirir.
Sürecinizi anlatın, hangi kısmının yazılıma değdiğini birlikte belirleyelim; teklif almak için buradan yazabilirsiniz.
