Özel yazılım geliştirme maliyeti tek satırlık bir fiyatla açıklanamaz. Aynı işi yapan iki proje arasında bile bütçede ciddi farklar oluşabilir. Nedeni basit: maliyeti, yazılımın görünen ekranlarından çok arka plandaki modüller, entegrasyonlar, veri akışları, yetki kurgusu, performans beklentisi ve bakım yükü belirler.

Bir şirket “müşteri yönetimi sistemi” istediğinde konu yalnızca birkaç form ve rapordan ibaret kalmayabilir. 5 kullanıcı için hazırlanan temel bir operasyon paneli ile 500 kullanıcının aynı anda işlem yaptığı, e-fatura, ERP ve kargo sistemine bağlanan bir platform aynı kategoride görünse de bütçe mantığı aynı değildir. Sağlıklı bir hesaplama için kalemleri ayırmak gerekir.

Bu yazıda özel yazılım geliştirme maliyeti için gerçekçi bir bütçe modeli kuracağız. Modül bazlı yaklaşım, entegrasyon karmaşıklığı, kullanıcı etkisi, bakım giderleri ve kapsam kontrolü üzerinden ilerleyeceğiz. Amaç, teklif istemeden önce doğru çerçeveyi kurmanıza yardımcı olmak.

Özel yazılım geliştirme maliyeti neden sabit değildir?

Hazır ürünlerde fiyat çoğu zaman paket bazlıdır. Özel yazılımda ise maliyet, ihtiyaç analiziyle başlar. Aynı sektör içinde bile fark büyüyebilir. Örneğin 8 ekranlı bir iç operasyon uygulaması ile 8 ekranlı bir B2B sipariş portalı aynı eforu gerektirmez. Çünkü ikinci senaryoda bayi yetkilendirmesi, fiyat listesi kuralları, stok senkronizasyonu, sipariş onayı ve dış sistem bağlantıları devreye girer.

Maliyeti etkileyen ana değişkenler şunlardır:

  • Modül sayısı ve her modülün iş kuralı yoğunluğu
  • Dış sistem entegrasyonları ve veri eşleme ihtiyacı
  • Kullanıcı rolleri, eşzamanlı kullanım ve performans beklentisi
  • Web, mobil, yönetim paneli gibi kanal sayısı
  • Güvenlik, loglama, raporlama, yedekleme gereksinimleri
  • Canlıya alma sonrası bakım ve geliştirme planı

Buradaki kritik ayrım, “ekran sayısı” ile “karmaşıklık” arasındadır. 20 sayfalık sade bir backoffice, 6 ekranlı ama yoğun iş mantığı içeren bir teklif motorundan daha düşük maliyetli olabilir. Bu yüzden doğru hesap, tasarım ya da yazılım başlamadan önce kapsamı katmanlara ayırarak yapılır.

Modül bazlı bütçe modeli nasıl kurulur?

En pratik yöntem, projeyi bağımsız modüllere bölmektir. Her modül için analiz, arayüz, backend, test ve canlıya alma yükü ayrı ayrı değerlendirilir. 4 modüllü bir proje ile 11 modüllü bir projenin aynı bütçede olması beklenmez; ancak modül sayısı tek başına yeterli değildir. Her modülün derinliği de ölçülmelidir.

Modül seviyeleri: temel, orta, ileri

Bir bütçe modelinde modülleri şu mantıkla sınıflandırmak iş görür:

  • Temel modül: Listeleme, kayıt ekleme, güncelleme, basit filtreleme. Örnek: personel kartı yönetimi.
  • Orta karmaşıklık: Rol bazlı görünüm, onay akışı, dosya yükleme, durum yönetimi. Örnek: izin talep süreci.
  • İleri modül: Kural motoru, dinamik fiyatlama, çok adımlı iş akışı, dış veri bağımlılığı. Örnek: bayi teklif ve iskonto onay yapısı.

Örnek bir senaryo düşünelim: satış ekipleri için özel CRM geliştiriliyor. Modüller şu şekilde ayrılabilir:

  • Müşteri ve firma yönetimi
  • Teklif oluşturma ve revizyon takibi
  • Aktivite, görev ve hatırlatma kayıtları
  • Raporlama paneli
  • Yetkilendirme ve kullanıcı yönetimi

Bu yapı 5 modül gibi görünür. Ancak teklif modülünde PDF üretimi, kur bazlı fiyat, onay akışı ve ERP’ye veri aktarımı varsa toplam eforu belirleyen asıl parça burası olur. İlk bütçe görüşmesinde “kaç modül var?” sorusu kadar “her modülde kaç iş kuralı var?” sorusu da mutlaka sorulmalıdır.

Entegrasyon maliyeti nasıl hesaplanır?

Entegrasyon, bütçeyi en sık etkileyen kalemlerden biridir. Çünkü burada yalnızca bir API çağrısı yazılmaz; kimlik doğrulama, veri dönüşümü, hata yönetimi, tekrar deneme mekanizması, loglama ve versiyon uyumu da kurgulanır. Tek bir entegrasyon bazen birkaç ekranlık modül kadar efor yaratabilir.

Özellikle şu sistemler maliyeti artırabilir:

  • ERP sistemleri
  • CRM, muhasebe veya stok çözümleri
  • Ödeme kuruluşları
  • E-fatura ve e-arşiv servisleri
  • Kargo, SMS, e-posta, kimlik doğrulama servisleri

Entegrasyonda kritik sorular

Sağlıklı bir bütçe için en az 6 başlığın netleşmesi gerekir:

  1. Hazır API dokümantasyonu var mı?
  2. REST, SOAP, SFTP veya dosya tabanlı bir iletişim mi kullanılacak?
  3. Veri tek yönlü mü akacak, çift yönlü mü?
  4. Anlık senkron mu isteniyor, 15 dakikalık batch akışı yeterli mi?
  5. Hata durumunda manuel müdahale ekranı gerekecek mi?
  6. Test ortamı ve örnek veri sağlanıyor mu?

Basit bir örnek verelim. Kargo entegrasyonunda yalnızca gönderi kodu üretmek başka bir iştir. Buna durum takibi, iade süreci, çoklu desi hesabı, label çıktısı ve webhook dinleme eklendiğinde efor katlanır. Benzer biçimde ERP entegrasyonunda sadece sipariş gönderimi ile stok, fiyat, cari hesap, tahsilat ve fatura senkronizasyonu arasında ciddi fark vardır.

// Basit bir entegrasyon örneği
POST /api/orders
{
  "customerCode": "C1024",
  "items": [{"sku": "P-445", "qty": 12}],
  "currency": "TRY"
}

Bu örnek kısa görünür. Ancak gerçek hayatta alan eşleme, eksik veri kontrolü, zaman aşımı, tekrar deneme ve işlem idempotency gibi katmanlar eklenir. Maliyet hesabında belirleyici olan da tam olarak bu görünmeyen alanlardır.

Kullanıcı sayısı maliyeti nasıl etkiler?

“10 kullanıcı mı, 1.000 kullanıcı mı?” sorusu lisans mantığı açısından değil, mimari yük açısından önem taşır. Özel yazılımda kullanıcı sayısı arttıkça yalnızca yetki ekranları çoğalmaz; performans, güvenlik ve veri hacmi planı da değişir. 20 kullanıcılı bir uygulama tek veritabanı sunucusunda sorunsuz çalışabilir. 2.000 kullanıcıda ise önbellekleme, kuyruk yapısı, yük dengeleme ve ayrıntılı izleme ihtiyacı doğabilir.

Maliyeti etkileyen kullanıcı başlıkları şunlardır:

  • Toplam kullanıcı sayısı
  • Aynı anda aktif olan kullanıcı oranı
  • Rol ve yetki matrisi
  • İşlem yoğunluğu: sadece görüntüleme mi, yoğun veri girişi mi?
  • Saklanan veri miktarı: örneğin ayda 50 bin kayıt mı, 2 milyon kayıt mı?

Somut bir senaryo düşünelim. Bir saha servis uygulamasında 60 teknisyen mobil uygulamayı gün içinde kullanıyor, 8 operasyon çalışanı ise yönetim panelinden planlama yapıyor. Burada çevrimdışı çalışma, cihaz senkronizasyonu ve konum verisi maliyeti etkiler. Aynı projede kullanıcı sayısı 60 yerine 600 olduğunda rapor performansı ve sunucu altyapısı yeniden ele alınır.

Bakım, destek ve işletim giderleri neden ayrı kalem olmalı?

Birçok projede ilk geliştirme bütçesi konuşulur, bakım tarafı ise geri planda kalır. Oysa canlıya çıkan yazılım bitmiş sayılmaz. Güvenlik güncellemeleri, bulut altyapı takibi, log analizi, küçük iyileştirmeler, hata düzeltmeleri ve versiyon uyumluluğu düzenli bir iş yükü üretir. Bu yük aylık ya da yıllık planlanmadığında gerçek toplam sahip olma maliyeti görünmez hale gelir.

Bakım kalemleri genel olarak şu başlıklarda toplanır:

  • Uygulama izleme ve hata müdahalesi
  • Güvenlik yamaları
  • Sunucu, veritabanı ve yedekleme yönetimi
  • Küçük geliştirme talepleri
  • Üçüncü taraf servis değişikliklerine uyum

Bakım modeli nasıl kurgulanır?

Pratikte 2 yaklaşım öne çıkar. İlki, aylık belirli saat karşılığı bakım paketidir. Örneğin ayda 10 saat, 20 saat gibi bir kapasite ayrılır. İkincisi ise talep bazlı destek modelidir; burada yalnızca ihtiyaç oldukça çalışma yapılır. Sürekli kullanılan ERP, CRM, bayi portalı veya operasyon uygulamalarında ilk model daha öngörülebilir olur.

Bulut maliyetleri de bu bölümde ele alınmalıdır. Uygulamanın 1 sunucu, yönetilen veritabanı, obje depolama, CDN, loglama ve yedekleme kullanması ile tek bir sanal makinede çalışması aynı işletim giderini üretmez. Teklif alırken yazılım geliştirme maliyeti ile altyapı işletim maliyetini ayrı görmek, karar kalitesini artırır.

Gerçekçi bütçe modeli için örnek hesap çerçevesi

Aşağıdaki yapı, teklif istemeden önce kurum içinde ön bütçe çıkarmak için kullanılabilir. Buradaki amaç rakam uydurmak değil, maliyeti oluşturan kalemleri görünür hale getirmektir.

  • Analiz ve çözüm tasarımı: iş akışlarının çıkarılması, kullanıcı rolleri, kapsam dokümantasyonu
  • UI/UX tasarımı: ekran akışları, responsive yapı, kullanıcı deneyimi kararları
  • Backend geliştirme: veri modeli, iş kuralları, API katmanı
  • Frontend / mobil geliştirme: web paneli, portal, mobil ekranlar
  • Entegrasyonlar: ERP, ödeme, e-fatura, kargo, SMS, SSO
  • Test ve kalite: fonksiyonel test, regresyon, kabul süreci
  • DevOps ve canlıya alma: CI/CD, loglama, yedekleme, ortam kurulumu
  • Bakım ve destek: aylık veya yıllık operasyon yükü

Örnek bir proje çerçevesi kuralım: 7 ana modül, 2 dış entegrasyon, 3 kullanıcı rolü, web paneli ve mobil uygulama, aylık bakım ihtiyacı. Bu projede ilk sürüm bütçesini yalnızca ekran sayısına bakarak hesaplamak yanıltıcı olur. Çünkü mobil taraf, yetki matrisi, çevrimdışı senkron ve entegrasyon testi toplam eforu kayda değer ölçüde değiştirir.

İyi bir teklif dokümanında en az şu 5 bilgi yer almalıdır: kapsam dışı maddeler, teslim fazları, entegrasyon varsayımları, bakım sınırı, değişiklik yönetimi yöntemi. Özellikle fazlama, bütçe kontrolü açısından etkilidir. Tüm sistemi tek seferde yapmak yerine çekirdek sürümü 8-12 hafta içinde canlıya alıp sonraki modülleri planlamak, hem riski hem de nakit baskısını azaltabilir.

Maliyet sapmasını azaltmak için nelere dikkat edilmeli?

Proje bütçesinin kontrolden çıkmasının en yaygın nedeni, kapsamın belirsiz olmasıdır. “Raporlar da olsun”, “mobil de ekleyelim”, “ERP ile de konuşsun” gibi ifadeler ilk görüşmede küçük görünür; ancak zaman içinde ciddi bir geliştirme yükü oluşturur. Net tanım yapılmadığında teklif ile gerçek iş arasındaki fark açılır.

Şu önlemler fayda sağlar:

  • İhtiyaçları kullanıcı senaryosu olarak yazın. Örneğin: “Satış yöneticisi, onay bekleyen teklifleri tek ekranda görebilmeli.”
  • Must-have ve nice-to-have ayrımı yapın.
  • Her entegrasyon için veri yönünü ve sıklığını tanımlayın.
  • İlk sürüm kapsamını sabitleyin.
  • Kabul kriterlerini baştan belirleyin.

Özel yazılım geliştirme maliyeti doğru hesaplandığında yalnızca fiyat değil, karar kalitesi de iyileşir. Hangi modülün ilk fazda yer alacağı, hangi entegrasyonun ertelenebileceği, hangi kullanıcı grubunun öncelikli olduğu daha net görünür. Kurumlar için sağlıklı yaklaşım, yazılımı tek seferlik bir alım gibi değil, ölçülebilir bir dijital yatırım olarak ele almaktır.

Kapanışta özetleyelim: gerçekçi bütçe; modül derinliği, entegrasyon karmaşıklığı, kullanıcı yükü ve bakım ihtiyacının birlikte değerlendirilmesiyle ortaya çıkar. İyi hazırlanmış bir kapsam dokümanı, çoğu zaman pazarlıkla elde edilen indirimden daha değerlidir. Çünkü sürprizleri azaltır, teslim kalitesini yükseltir ve projenin toplam sahip olma maliyetini görünür kılar.