← TÜM YAZILARBLOG / PLANLAMA

4 DK OKUMA

Bir Web veya Mobil Uygulama Geliştirmek Ne Kadar Sürer?

MVP, iç araç ve tam platform için gerçekçi süreler; süreyi neyin uzatıp kısalttığı ve kaliteden ödün vermeden nasıl hızlandırılacağı.

Bir proje zaman çizelgesini gösteren soyut illüstrasyon

"Ne kadar sürer?" neredeyse her keşif görüşmesinin ilk sorusu ve dürüst cevap bir tarih değil, bir aralıktır. Bu yazıda gerçekten teklif ettiğimiz aralıkları, bir projeyi aralığın üst ya da alt ucuna iten şeyleri ve başlamadan önce kısa tarafa düşmek için neler yapabileceğinizi anlatıyoruz.

Kısa özet

  • Odaklı bir MVP veya iç araç, web ya da mobil, genellikle başlangıçtan canlıya 4 ila 8 hafta sürer.
  • Birden fazla uygulama, rol ve üçüncü taraf entegrasyonu içeren bir platform genellikle 2 ila 4 ay sürer.
  • Mobil uygulamalarda üstüne mağaza inceleme süresi eklenir: App Store için genellikle bir iki gün, yeni bir Google Play geliştirici hesabı için bir haftaya kadar.
  • Mevcut bir kod tabanında kurtarma ya da performans işi aylarla değil haftalarla ölçülür; çünkü ilk düzeltmeler genellikle mimaridedir, yeniden yazım değildir.

Bunlar hizmetler sayfamızdaki cevapların arkasındaki rakamlar. Tasarımı, web'i, mobili ve backend'i birlikte üstlenen tek bir küçük ekip varsayılıyor. İşi üç tedarikçiye bölmek, hiçbir tahminin gizleyemeyeceği bir koordinasyon süresi ekler.

Süreyi asıl belirleyen şeyler

Özellikler girdilerden yalnızca biri. Pratikte bir projenin aralığın neresine düşeceğini beş şey belirler.

  • Kaç kararın çoktan verilmiş olduğu. Net bir sahibi, kapsam dışı kalanların yazılı listesi ve ilk kullanıcı akışı hakkında kararı olan bir proje, her ekranın tartışıldığı bir projeden iki kat hızlı ilerler. Keşif aşaması bu kararları erkenden vermek için var.
  • Entegrasyonlar. Her ödeme sağlayıcısı, CRM, ERP ya da partner API'si kendi test ortamını, kendi tuhaflıklarını ve kendi onay sürecini getirir. Üç entegrasyon, ürünün geri kalanı kadar maliyetli olabilir.
  • Roller ve yetkiler. Tek tür kullanıcısı olan uygulama basittir. Müşteri, operatör ve yöneticinin farklı şeyler gördüğü bir uygulama bir yetki modeli gerektirir ve o model her ekrana dokunur.
  • Tasarımın hazır olması. Bir tasarım sistemi ya da marka varsa doğrudan onun üstüne inşa ederiz. Yoksa ilk bir iki hafta, geri kalan her şeyin bağlı olduğu ekranları üretmekle geçer.
  • Mobile özgü konular. Çevrimdışı mod, arka plan senkronu, push bildirimleri ve mağaza uyumluluğu eklenti değildir. Her biri gerçek cihazlarda bir haftalık iş ve testtir.

Proje türüne göre tipik aralıklar

Tanıtım sitesi veya landing page: 1 ila 3 hafta. Uzun süren kod değil, içerik ve tasarımdır. Core Web Vitals'ı geçmek sonradan yapılan bir iyileştirme değil, "bitti" tanımının parçasıdır.

İç araç veya pano: 3 ila 6 hafta. Bir iki kullanıcı rolü, bir veritabanı, birkaç ekran ve bir kimlik doğrulama katmanı. En hızlı yayına çıkan ve kendini ilk ödeyen projeler bunlardır.

Bir web veya mobil ürünün MVP'si: 4 ila 8 hafta. Gerçek ama bilinçli olarak küçük bir ürün: iyi yapılmış tek bir ana akış, analitik, çökme raporlama ve ilk günden yayın hattı. Amaç altıncı ayda her şeyi çıkarmak değil, sekizinci haftada gerçek kullanıcılardan öğrenmektir.

Platform veya çok uygulamalı ürün: 2 ila 4 ay. Bir web uygulaması, bir mobil uygulama ve paylaştıkları backend; entegrasyonlar ve birden fazla kullanıcı rolüyle. Bunları fazlara böleriz: ilk altı sekiz haftada kullanılabilir bir ilk sürüm, sonra üstüne artışlar.

Kurtarma, denetim veya performans işi: 2 ila 6 hafta. Bir profilleme turu, neyin yavaş ya da kırılgan olduğunun yazılı listesi, sonra etki sırasına göre düzeltmeler. Sıfırdan yeniden yazmak neredeyse hiçbir zaman cevap değildir; bu yüzden haftalarla ölçülür.

Nasıl tahmin veriyoruz

  • Keşif görüşmesi, 30 ila 45 dakika. Ne yapıyorsunuz, kim kullanacak ve başarısız olursa işe maliyeti ne.
  • Yazılı kapsam. Kısa bir belge: ne yapacağız, neyi bilerek dışarıda bırakacağız, fazlar, takvim ve fiyat. 40 sayfalık bir teklif değil.
  • Tek bir teslim tarihi yerine fazlar. Her faz, staging linkinde ya da test sürümünde çalışan yazılımla biter; böylece plan sonda değil, her bir iki haftada bir düzeltilir.

Kaliteden ödün vermeden süreyi kısaltmak

  • Kendi tarafınızda tek bir karar vericiyi belirleyin ve geri bildirim turlarını kısa tutun.
  • İlk sürümün neleri *içermediğini* yazın. O listedeki her madde kazanılmış bir haftadır.
  • Hesapları erkenden getirin: mağaza geliştirici hesapları, alan adı erişimi, ödeme sağlayıcısı ve API anahtarları. Bir giriş bilgisini beklemek, her projedeki en yaygın boş haftadır.
  • Sıkıcı, kanıtlanmış teknolojiyi tercih edin. Egzotik seçimler iki kez zaman alır: bir kez kurarken, bir kez de bakımını yaparken.
  • Gerçek kullanıcıların kullanabileceği en küçük sürümü çıkarın, sonra geliştirin. On sekizinci ay, lansman gününden daha önemlidir.

Gerçek bir tahmin alın

Ne yaptığınızı proje formu üzerinden anlatın ya da hello@alaz.pro adresine yazın. Kısa bir görüşmenin ardından, genellikle bir hafta içinde fazları, takvimi ve fiyatı olan yazılı bir kapsam alırsınız. Her mesajı bir mühendis okur ve bir iş günü içinde cevap veririz.

ALAZ ekibiWeb, mobil ve backend mühendisliği

ALAZ, İzmir ve New York'ta web uygulamaları, mobil uygulamalar ve backend sistemleri geliştiren ve kendi ürünlerini yayınlayan bir yazılım stüdyosu. Bu yazıyla ilgili sorular için: hello@alaz.pro. Stüdyo hakkında daha fazlası

SONRAKİ YAZIYavaş Bir Web Sitesi İşinize Gerçekte Ne Kadara Mal Oluyor?
BENZER BİR ŞEY ÜZERİNDE Mİ ÇALIŞIYORSUNUZ?PROJE BAŞLAT