Yazılım projesi ne kadar sürer? Gerçek projelerden süreler

Süreyi kapsam belirler. SPSTARPLAST'ın 16 modüllü ERP'si Mayıs 2025 ile Ağustos 2026 arasında geliştirilip bakımı yapıldı; Otocropper'ın beş sürümü ise bir haftada çıktı.

Süreyi ne belirler?

“Bu iş kaç ayda biter?” sorusunun dürüst cevabı, kapsam yazılmadan verilemez. Süreyi belirleyen beş etken var:

1. Kapsam. Kaç iş akışı, kaç ekran ve kaç kullanıcı rolü olduğu. SPSTARPLAST'ın ERP'si 16 modülden ve 50'den fazla ekrandan oluşuyor, yetkiler 14 işlev alanına göre veriliyor; böyle bir sistem, tek bir iş akışını çözen bir uygulamayla aynı takvime sığmaz.
2. Entegrasyonlar. Başka bir sistemle veri alışverişi ayrı bir iş kalemidir. SPSTARPLAST'ta kartlar ve ekstreler LOGO ERP'den okunuyor, kabul edilen teklifler LOGO'ya satış siparişi olarak yazılıyor; böyle bir bağlantının her yönü ayrı ayrı test edilir.
3. Veri taşıma. Excel dosyalarından ya da eski bir sistemden aktarılacak kayıtların temizlenmesi ve doğrulanması, geliştirmeden bağımsız bir iştir.
4. Karar hızı. Sorulara ve deneme sürümlerine ne kadar hızlı dönüldüğü. Haftalık deneme sürümü, ancak her hafta biri ona bakıyorsa işe yarar.
5. Mağaza incelemesi. Bir iOS uygulaması yayına girmeden önce App Review'dan (Apple'ın uygulama incelemesi) geçer. Apple'a göre App Review günün her saatinde çalışır ve genellikle gönderimlerin en az %50'sini 24 saatten, %90'ını 48 saatten kısa sürede inceler.

Gerçek projelerden süreler

Aşağıdaki tablo yalnızca tamamlanmış ve kayıtlı tarihleri içerir. Her satır, projenin kendi sayfasındaki zaman çizelgesinden alındı.

Bu tarihler bir süre vaadi değildir. Benzer bir işin sizin kapsamınızda ne kadar süreceği, yazılı teklifte kilometre taşlarıyla birlikte belirtilir. Devri de takvimde ayrı bir adım olarak planlayın: SPSTARPLAST'ta geliştirme ve bakım Ağustos 2026'da bitti, devir Eylül 2026'da yapıldı (teslim ayrıntıları).

Uygulama geliştirme aşamaları

Bir web ya da mobil uygulama projesi aşağıdaki aşamalardan geçer. Her aşamanın süresini o aşamanın kendi işi belirler; şirketinize özel yazılım projelerinde de sıra aynıdır.

1. Ön görüşme ve yazılı kapsam. 15 dakikalık ücretsiz bir görüşme, ardından kapsamı, kilometre taşlarını, kabul kriterlerini ve tek bir sabit fiyatı içeren yazılı teklif.
2. İlk iş akışı. Ürünün en önemli akışı uçtan uca çalışır hâle getirilir.
3. Haftalık deneme sürümleri. Her hafta denenebilecek bir sürüm çıkar; geri bildirim bir sonraki haftanın işine girer.
4. Kabul testleri. Her kilometre taşı teklifteki kabul kriterlerine göre kontrol edilir; işe başlarken ödenen %30'dan sonraki ödemeler, yani ara teslimdeki %40 ve tamamlanmadaki %30, bu kontrole bağlıdır.
5. Yayın. Web uygulaması sizin alan adınızda ve hesaplarınızda yayına alınır; mobil uygulama mağaza incelemesinden geçer.
6. Destek. Yayından sonra hata düzeltmeleri ve yeni özellikler aylık ve isteğe bağlı olarak sürer.

Mobil uygulama kaç günde yapılır?

Bu sorunun tek bir gün sayısıyla cevabı yok; internette dolaşan genel süre aralıkları da sizin uygulamanız hakkında bir şey söylemez. Bunun yerine süreyi uzatan kalemleri tek tek sayın:

• Mağaza incelemesi. Apple'ın verdiği bilgiye göre çözülmemiş inceleme sorunlarının ortalama %40'tan fazlası, inceleme yönergelerinin 2.1 maddesiyle, yani çökmeleri, yer tutucu içerikleri ve eksik bilgileri kapsayan “App Completeness” (uygulamanın eksiksizliği) kuralıyla ilgilidir. Bu yüzden gönderimden önceki kontrol ayrı bir adım olarak planlanmalıdır.
• Abonelik ve uygulama içi satın alma. Ödeme akışı, mağaza ayarları ve testleri ayrı bir iş kalemidir. 1in46 ve Mawla'da abonelikler RevenueCat ile yönetiliyor.
• Diller. Her dil, metinlerin çevirisi ve ekranların o dilde denenmesi demektir. 1in46 İngilizce, Türkçe, İspanyolca ve sağdan sola yazılan Arapça olmak üzere dört dilde.
• İkinci mağaza. 1in46 Mart 2026'dan beri App Store'da, Eylül 2026'dan beri Google Play'de. İki mağazaya çıkışın aynı gün olması gerekmez; ikinci mağaza ayrı bir kilometre taşı olabilir.
• Teknoloji seçimi. Tek kod tabanıyla iki mağazaya çıkmak ile tek bir platform için yerel uygulama yazmak farklı işlerdir. MUST, 1in46 ve Mawla Expo ve React Native ile, çevrim dışı çalışan Zoomi Kids ise yerel Swift ile geliştirildi. Seçimi takvim değil, uygulamanın ihtiyacı belirlemelidir.

App Store'daki dört uygulamamız (MUST, 1in46, Mawla ve Zoomi Kids) incelemeden Savaş Tutumlu'nun geliştirici hesabıyla geçti. Hesap, ücret ve inceleme adımlarını App Store'da uygulama yayınlama rehberinde, iOS ve Android projelerini nasıl yürüttüğümüzü ise mobil uygulama geliştirme sayfamızda anlattık.

Süreyi kısaltmak

• Tek bir iş akışıyla başlayın. İlk sürüm tek bir işi uçtan uca yapsın; bu işin nasıl seçileceğini MVP ve ilk sürüm planlama rehberinde anlattık.
• Kabul kriterlerini baştan yazın. Neyin “bitti” sayılacağı yazılı değilse teslim tartışmaya açık kalır.
• Haftalık deneme sürümüne bakın. Her hafta size denenebilecek bir sürüm gelir; geri bildirim ne kadar erken gelirse düzeltme o kadar küçük olur.
• Bir karar sorumlusu belirleyin. Sorulara sizin tarafınızdan kimin cevap vereceği belli olsun.
• Riskli işi öne alın. Bir model, bir entegrasyon ya da veri taşıma gibi belirsiz bir kalem ilk kilometre taşlarından birinde denenmelidir. Otocropper'da veri etiketleme ve model eğitimi Ağustos 2026'da, ilk sürüm 8 Eylül 2026'da yapıldı.

Size verilen süreyi nasıl okumalısınız?

Birkaç firmadan süre aldıysanız rakamları yan yana koymadan önce her birine aynı dört soruyu sorun:

• Bu süre hangi kapsam için verildi? Ekranların ve iş akışlarının listesi yazılı mı?
• Entegrasyonlar ve veri taşıma bu sürenin içinde mi, dışında mı?
• Sizin tarafınızdaki cevapların ne kadar hızlı geleceği varsayıldı?
• Mağaza incelemesi, kabul testleri ve devir takvimde ayrı adımlar olarak görünüyor mu?

Bu soruların cevabı yazılı değilse iki teklifin süresini karşılaştırmak mümkün olmaz. Tekliflerden biri ötekilerden belirgin biçimde kısaysa, önce kapsam listesinde neyin eksik olduğuna bakın.

Gecikmeyi önleyen maddeler

Takvimi korumanın yolu, sözleşmede birkaç maddeyi açıkça yazmaktır:

• Yazılı kapsam ve kapsam dışında bırakılan işlerin listesi.
• Her kilometre taşının tarihi, içeriği ve kabul kriteri.
• Yazılı değişiklik talebi: kapsam dışındaki her yeni işin fiyatı ve takvime etkisi iş başlamadan yazılır.
• Sorulara kimin, ne kadar sürede cevap vereceği; iki taraf için de.
• Kilometre taşlarına bağlı ödeme.
• Teslimde kodun, veritabanının ve hesapların kime geçeceği.

Bu maddelerin sözleşmede nasıl yer alacağını yazılım geliştirme sözleşmesinde dikkat edilmesi gerekenler rehberinde anlattık.

İlgili hizmet

Özel yazılım geliştirme hizmeti: şirketinizin iş akışına göre kurulan iç sistemler; yazılı kapsam, kilometre taşları ve tek bir sabit fiyatla.

İlgili rehberler

• ERP seçim kriterleri: hazır paket mi, özel ERP mi?
• Yazılımda MVP nedir, ilk sürüm nasıl planlanır?
• Yazılım geliştirme sözleşmesi: dikkat edilecek maddeler

Kaynaklar

• Apple Developer, App Review: inceleme süresi ve yönergelerin 2.1 maddesi (21 Ekim 2026'da kontrol edildi).
• Proje tarihleri: tablodaki proje sayfaları ve Projeler sayfası (21 Ekim 2026'da proje kayıtlarıyla karşılaştırıldı).