Özel yazılım maliyeti neye göre belirlenir?

Neden tek bir fiyat listesi yok?

Hazır bir yazılımın fiyatı listelenebilir, çünkü ürün zaten vardır. Özel yazılımda satın alınan şey henüz yoktur; fiyat, yapılacak işin büyüklüğünden çıkar. “Bayilerimiz sipariş verebilsin” cümlesi birkaç ekranlık bir form da olabilir, kredi limitleri ve ERP entegrasyonu içeren bir platform da. İkisine aynı rakamı vermek, birini fazla ya da diğerini eksik fiyatlamak demektir.

Bu yüzden ilk görüşmede konuşulan rakam bir tahmindir ve belirsizlik payı yüksektir. Güvenilir bir aralık ancak kullanıcılar, akışlar ve bağlanılacak sistemler bilindiğinde verilebilir. Bunu netleştirmenin yolu kısa bir keşif çalışmasıdır: 1–2 haftada süreç yerinde gözlemlenir, sistemler listelenir, ilk sürümün kapsamı yazılır, önerilen ekip ve süre aralığı çıkarılır. Keşfin adımlarını ve çıktılarını keşif sprintini anlattığımız yazıda ayrıntılı olarak ele alıyoruz.

Keşiften önce sabit fiyat istemek cazip görünür ama risklidir. Teklifi veren firma belirsizliği ya fiyata risk payı olarak ekler ya da düşük fiyat verip kapsamda yazmayan her şeyi değişiklik talebine çevirir. İlkinde belirsizliğin bedelini peşin ödersiniz, ikincisinde proje boyunca.

Maliyeti hangi kalemler belirler?

Aşağıdaki kalemler bir projenin büyüklüğünü en çok değiştirenlerdir. Son sütundaki soru, kalemin sizin projenizde ne kadar ağır olduğunu anlamanıza yardım eder.

Tabloda olmayan iki kalem daha var. Birincisi ekip yapısıdır: kıdem, ekip büyüklüğü ve rollerin dağılımı hem birim ücreti hem de hızı belirler. İkincisi sizin tarafınızdaki zamandır. Kararları verecek ürün sahibi haftada birkaç saat ayıramıyorsa sorular beklemede kalır, takvim uzar; uzayan takvim de maliyettir.

Kişisel veriler yurt dışındaki bir bulut hizmetinde tutulacaksa, KVKK’nın yurt dışına aktarım şartlarının da baştan değerlendirilmesi gerekir. Bu, hem barındırma seçimini hem de sözleşme işlerini etkiler.

Maliyeti kabaca nasıl hesaplarsınız?

Teklif almadan önce kaba bir hesap yapmak, gelen teklifleri okumayı kolaylaştırır. Mantık basittir:

• Geliştirme maliyeti = ekip (kişi) × süre (hafta) × haftalık birim ücret
• İlk yıl toplamı = geliştirme maliyeti + üçüncü taraf kurulumlar + 12 aylık işletme giderleri

Aşağıdaki şablonu kendi değerlerinizle doldurabilirsiniz. Para birimini, fiyat tarihini ve KDV’nin dahil olup olmadığını en başa yazın. Birkaç ay süren projelerde kur ve fiyat değişimleri karşılaştırmayı bozabilir; bu yüzden teklifin geçerlilik tarihi de şablonun parçasıdır.

Para birimi: …… · Fiyat tarihi: …… · KDV: dahil / hariç · Geçerlilik: ……

Belirsizlik payını gizlemeyin; hangi açık soruya karşılık geldiğini yazın. Keşiften sonra sorular yanıtlandıkça bu pay küçülür.

Canlıya çıktıktan sonra hangi giderler başlar?

• Barındırma ve altyapı: sunucu ya da bulut hizmeti, veritabanı, yedekleme, alan adı.
• İzleme: hata kayıtları, erişilebilirlik takibi ve uyarılar.
• Güvenlik güncellemeleri: kullanılan kütüphanelerin yeni sürümleri; mobil uygulamalarda her yıl değişen işletim sistemi sürümleri ve mağaza kuralları.
• Destek ve küçük geliştirmeler: kullanıcı soruları, hata düzeltmeleri, ufak iyileştirmeler.
• Üçüncü taraf ücretleri: e-Fatura entegratörü, SMS, harita, ödeme altyapısı ve uygulama mağazası hesapları.

Bu giderleri tek bir yüzdeyle tahmin etmek yerine kalem kalem listeleyin: sabit olanları aylık tutar olarak, destek ve küçük geliştirmeleri ise aylık saat havuzu ve yanıt süreleriyle.

Ne kadar sürer? Varsayımsal bir örnek

Örneğin bir distribütör, bayilerin telefonla verdiği tekrar siparişlerini bir portala taşımak istiyor. MVP kapsamının nasıl belirleneceğini anlattığımız yazıdaki gibi ilk sürüm daraltılmış olsun: bayi girişi ve bayiye özel fiyat, geçmiş siparişten sepet, sipariş takibi ve salt okunur cari özet. Fiyat ve stok, ERP’den günde birkaç kez dosya aktarımıyla alınır. Portal mobil uyumlu web olarak çalışır; ayrı bir mobil uygulama yoktur.

Bu tablo bir senaryo varsayımıdır; gerçek ekip ve süre keşiften sonra belirlenir. Kişi-hafta toplamını yukarıdaki şablona taşıyıp teklif aldığınız firmanın haftalık birim ücretiyle çarptığınızda geliştirme maliyetinin kaba karşılığını bulursunuz. Bizim sürecimizde kapsamı birlikte belirlenen ilk sürüm, 6–12. haftada canlıya çıkacak şekilde planlanır. Kapsam büyüdükçe tablo da değişir:

• Kampanya ve iskonto kuralları: orta büyüklükte bir ek; kuralların ne kadar yazılı olduğuna bağlı.
• ERP ile anlık, çift yönlü entegrasyon: büyük; ERP’nin API’sine ve karşı taraftaki yetkiliye bağlı.
• Portaldan ödeme: büyük; ödeme kuruluşu, mutabakat ve güvenlik işleri ekler.
• Saha satış için mobil uygulama: kendi keşfi ve ekibiyle ayrı bir aşama.

Bu ekleri ilk sürüme yüklemek yerine sıraya dizmek, büyük programları aşama aşama canlıya çıkarmanın da yoludur: ilk aşama 6–12 haftada, sonrakiler yol haritasında. Kurgusal X Dağıtım için hazırladığımız Bayi Sipariş Platformu ürün konsepti, bu aşamalandırmanın ekranlarda nasıl görünebileceğini gösteriyor.

Teklif istemeden önce rolleri, veri kaynaklarını ve ilk sürümün sınırını proje briefi aracıyla yazın. Daha ayrıntılı kabul ölçütleri için yazılım projesi ihtiyaç listesi örneğini kullanabilirsiniz.

Sabit fiyat mı, zaman-malzeme mi?

Aynı kapsam farklı modellerle fiyatlanabilir. Doğru model, ne kadar belirsizlik kaldığına bağlıdır.

Modeller birleştirilebilir: keşif sabit fiyatla, ilk sürüm tavanı belirlenmiş zaman-malzeme ile, sonrası ekip modeliyle yürütülebilir. Kapsamı gerçekten net, küçük bir iş içinse sabit fiyat çoğu zaman en sade seçenektir.

Bütçeyi güvenle nasıl düşürürsünüz?

Bütçeyi düşürmenin güvenli yolu yapılacak işi azaltmaktır; işi aynı bırakıp kaliteden kısmak değil.

• İlk sürümü daraltın. Tek kullanıcı grubu ve tek ana akışla başlayın.
• Entegrasyonu önce köprüleyin. Dosya aktarımı ya da elle aktarımla başlayıp tam entegrasyonu hacim gerektirdiğinde yapın.
• Hazır bileşen kullanın. Kimlik doğrulama, ödeme, bildirim ve e-Fatura için olgun hizmetler varken bunları sıfırdan yazmak gerekmez. Muhasebe, bordro ya da standart bir CRM ihtiyacında hazır ürün çoğu zaman daha doğru seçimdir.
• Mobil uyumlu webi değerlendirin. Bağlantısız çalışma ya da cihaz özellikleri gerekmiyorsa ayrı bir mobil uygulama ilk sürümde şart değildir.
• Aşamalara bölün. Her aşamanın sonunda devam kararını yeniden verin.

Ucuz bir teklifte otomatik testler, güvenlik kontrolleri, veri taşıma, kabul testi, dokümantasyon, yedekleme planı ya da canlı sonrası garanti eksik olabilir. Bunlar tekliften çıkarılınca ortadan kalkmaz; projenin son haftalarına ya da bakım faturasına taşınır.

Bir teklifte neler olmalı?

İki teklifi karşılaştırmadan önce aynı işi fiyatladıklarından emin olun. Aşağıdaki başlıklar teklifte yazılı olmalı; eksik olanları teklifi verenden isteyin.

Bütçe ve süreyi hangi koşulların belirlediğini özel yazılım geliştirme hizmet sayfamızda da özetliyoruz. Teklifi bu başlıklarla hazırlarız; belirsizlik yüksekse ilk adım olarak bir keşif sprinti öneririz.

Bütçeyi birlikte netleştirelim →