İçeriğe geç
dafalabs
1 Ağustos 2026·2 dakikalık okuma

"Uygulama kaça yapılır?" sorusunun dürüst cevabı

Bu soruya rakam veren biri ya kapsamı biliyordur ya da sonradan ek fatura çıkaracaktır. Aradaki farkı nasıl anlarsınız?

En sık gelen soru bu, ve en zor cevaplanan. "Bir uygulama kaça mal olur?"

Dürüst cevap: sorunun kendisi eksik. "Bir bina kaça yapılır?" gibi. Kaç katlı, kaç metrekare, nerede, hangi malzemeyle?

Ama bu cevap yalnız bırakıldığında kaçamak gibi duruyor. O yüzden bir adım daha atalım: fiyatı belirleyen şeyler tam olarak neler.

Maliyeti belirleyen altı şey

Ekran sayısı ve karmaşıklığı. Beş ekranlık bir uygulama ile kırk ekranlık bir uygulama arasında sekiz kat değil, daha büyük bir fark var — çünkü ekranlar birbirine bağlandıkça karmaşıklık üst üste biniyor.

Kullanıcı rolleri. Herkesin aynı şeyi gördüğü bir uygulama ile yönetici, personel ve müşteri rollerinin farklı ekranlar gördüğü bir uygulama aynı iş değil. Her rol, ayrı bir akış ve ayrı bir test yükü demek.

Sunucu tarafı var mı. Uygulama sadece veri gösteriyorsa iş yarıya iniyor. Kullanıcı hesapları, veri kaydı, bildirimler, raporlama varsa bir de arka uç yazılıyor demektir.

Entegrasyonlar. Ödeme, e-fatura, kargo, mevcut ERP. Her biri ayrı bir belirsizlik: karşı tarafın dokümantasyonu iyi mi, test ortamı var mı, destek veriyorlar mı? En çok sürpriz buradan çıkıyor.

Offline çalışma. "İnternet yokken de çalışsın" cümlesi maliyeti ciddi biçimde artırır. Veriyi cihazda tutmak, çakışmaları çözmek ve eşitlemek başlı başına bir mühendislik işi.

Tasarımın hazır olup olmaması. Elinizde onaylanmış bir tasarım varsa geliştirme doğrudan başlar. Yoksa önce o iş yapılır.

Kapsam netleşmeden verilen rakamın anlamı

İki ihtimal var:

Yüksek verilir. Belirsizliği fiyata yediren bir teklif alırsınız. İş beklenenden basit çıkarsa fark size dönmez.

Düşük verilir. İşe girildikten sonra "bu kapsam dışıydı" konuşmaları başlar. Proje ortasında bütçe tartışması, ilişkiyi de takvimi de bozar.

İkisi de kötü. Bu yüzden biz önce kapsamı çıkarıyoruz.

Nasıl olması gerekiyor

Sağlıklı bir teklif süreci şöyle işler:

  1. Görüşme. Ne yapmak istediğinizi dinliyoruz. Ücretsiz, taahhütsüz.
  2. Kapsam çıkarma. İş maddelere bölünüyor: hangi ekranlar, hangi roller, hangi entegrasyonlar, neler ilk sürümde yok.
  3. Yazılı teklif. Her madde için süre ve bedel. Neyin dahil olmadığı da yazıyor — asıl anlaşmazlık orada çıkıyor.
  4. Geliştirme. Düzenli aralıklarla çalışan sürüm gösteriliyor.

Üçüncü maddedeki "dahil olmayanlar" listesi teklifin en değerli kısmı. "İçerik girişi bize ait değil", "mağaza hesapları müşteri adına açılacak", "tasarım revizyonu iki tur" gibi satırlar, altı ay sonraki tartışmayı bugünden bitiriyor.

Bütçeniz belliyse söyleyin

Çoğu kişi bütçeyi söylemenin pazarlık gücünü azaltacağını düşünüyor. Tersi oluyor.

Bütçeyi bilirsek o rakama ne sığdığını söyleyebiliriz — hangi özellikler ilk sürüme girer, hangileri ikinci aşamaya kalır. Bilmezsek ya kapsamı fazla geniş tutup rakamı yükseltiriz ya da eksik anlayıp yanlış teklif veririz.

"Şu kadar bütçem var, buna ne yapılır?" sorusu, "kaça yapılır?" sorusundan çok daha hızlı sonuca gidiyor.

Küçük başlamak bir eksiklik değil

İlk sürümün her şeyi yapması gerekmiyor. Çekirdek işi yapan, gerçek kullanıcıya ulaşan bir sürüm; hem daha ucuz hem de sonraki kararları tahminle değil ölçümle almanızı sağlıyor.

Bize gelen projelerin bir kısmında ilk işimiz kapsamı daraltmak oluyor. Kendi faturamızı küçülten bir öneri, ama biten proje sayısını artırıyor.

"Uygulama kaça yapılır?" sorusunun dürüst cevabı — dafalabs