Startup MVP Oyun Kitabı: Fikirden App Store'a 6 Haftada Nasıl Ulaşılır

Çoğu startup ilk uygulamalarını piyasaya sürmek için 6 ay harcar. Biz bunu 6 haftada yapıyoruz. Köşe kesmeyerek değil, v1'e nelerin gireceğini ve v2'nin ne zaman geleceğini mercimerçek gibi kontrol ederek. Düzinelerce kurucunun ilk ürünlerini piyasaya sürmelerine yardım ettikten sonra, sürecimizi tekrar edilebilir bir oyun planına dönüştürdük.

1-2. Hafta: Mercimerçek gibi kapsam belirleme (en zor kısım)

MVP'lerin başarısız olmasının birinci sebebi kapsam genişlemesidir. Tek bir kod satırı yazmadan önce, ilk iki haftada kurucularla MVP'nin tam olarak ne yapacağını ve ne yapmayacağını tanımlıyoruz. Amaç, ürün hipotezini kanıtlayan tek bir temel iş akışını belirlemektir.

Basit ama etkili bir çerçeve kullanıyoruz: bir özellik temel hipotezi doğrudan desteklemiyorsa, onu keseriz. İstisna yok. Ayarlar ekranları, profil düzenlemesi, sosyal paylaşım özellikleri, yönetici panoları — tümü v1'den kesilir, EĞERse ürün değillerse.

Bu duygusal olarak kurucular için zordur. Her özellik senin bebeğin olduğunda gerekli görünür. Bizim işimiz şu sözü söyleyen dürüst ses olmaktır: kullanıcılarının ilk haftada bir ayarlar ekranına ihtiyacı yok. Temel değer önerisinin kusursuz çalışmasına ihtiyaçları var.

Bu aşamanın çıktısı, içinde şunlar olan tek sayfalık bir kapsam belgesidir: temel hipotez, birincil kullanıcı akışı (maksimum 3-5 ekran), gerekli entegrasyonlar (ödemeler, kimlik doğrulama, yapay zeka modeli) ve açık bir yapılmış tanımı. Her şey v2 bekleme listesine gider.

2-3. Hafta: Tasarım sprint — inşa etmeden önce doğrulayın

Google Ventures metodolojisinden ödünç alınan ancak hız için uyarlanmış sıkıştırılmış bir tasarım sprint yürütüyoruz. Pazartesi: kullanıcı yolculuğunu haritalandırın ve kritik yolu belirleyin. Salı: her ekran için wireframe çizin. Çarşamba: görsel yönü belirleyin ve bir bileşen kütüphanesi oluşturun. Perşembe: Figma'da yüksek sadakatli ekranlar. Cuma: etkileşimli prototip.

Hafta sonu boyunca bu prototip 5 gerçek potansiyel kullanıcıyla test edilir. Onları kullanırken izleriz, kafalarının karıştığı yerleri not ederiz ve Pazartesi sabahı üzerinde çalışırız. Bu bir haftalık tasarım en az iki haftalık geliştirme yeniden işini tasarrufu sağlar. Her seferinde.

Tasarım sprintı ayrıca tüm geliştirici devir teslim varlıklarını üretir: bileşen özellikleri, boşluk değerleri, renk tokenları ve etkileşim açıklamaları. Geliştirme başladığında, neyi oluşturacağınız konusunda sıfır belirsizlik vardır.

3-5. Hafta: İnşa Edin — en riskli parçayla başlayın

Geliştirme, en kolay ekranlarla değil, en riskli teknik bileşenle başlar. Uygulamanın yapay zekaya ihtiyacı varsa, önce yapay zekanın çalıştığını kanıtlarız. Gerçek zamanlı senkronizasyona ihtiyacı varsa, bunu önce oluştururuz. Belirli bir donanım entegrasyonuna ihtiyacı varsa, bu önce gelir. Arayüz, kanıtlanmış işlevselliğin etrafında sarılır, değil tersine.

Bu yaklaşım sezgisel olmayan bir yaklaşımdır — çoğu geliştirici giriş ekranıyla başlamak ister çünkü üretken hissettiriyor. Ancak teknik olarak mümkün olmayabilecek bir özellik için kullanıcı arayüzü oluşturmak saf israftır. Zor parçaları önce kanıtlayın, sonra onları güzel bir arayüzle sarın.

Teknoloji yığını için, kanıtlanmış araçlara varsayılan olarak dönüyoruz: ön uç için Flutter veya SwiftUI, arka uç için Supabase (kimlik doğrulama, veritabanı, depolama, kutudan çıktığı gibi gerçek zamanlı abonelikler) ve herhangi bir web bileşeni için Vercel. Bu yığın, küçük bir ekibin kaliteyi feda etmeden inanılmaz hızda ilerlememesine olanak tanır.

Her Cuma kurucuya bir TestFlight derlemesi göndeririz. Bu, uyumsuzlukları erken yakalayan haftalık bir geri bildirim döngüsü oluşturur. Kurucunun aslında Cumartesi ve Pazar günü telefonda uygulamayı kullanması ve Pazartesi günü geri dönüşte belirli, uygulanabilir geri bildirim sunması yerine hiçbir şey yoktur.

5-6. Hafta: Parlatma, test etme ve gönderme

Son aşama, cilalama ve App Store'a hazırlıkla ilgilidir. Bu aşama şunları içerir: TestFlight geri bildiriminden hata düzeltme, performans optimizasyonu (tüm animasyonlarda 60fps ve 2 saniyenin altında soğuk başlatma hedefliyoruz), App Store ekran görüntüsü oluşturma, açıklama metni, gizlilik politikası ve gerçek gönderim.

Gönderim işleminde hiçbir şeyin kaçmamasını sağlayan 47 maddelik bir kontrol listemiz var. Onay gecikmelerine neden olan yaygın gözetilişler: eksik gizlilik etiketleri, yanlış yaş derecelendirmesi, yer tutucu içerik gösteren ekran görüntüleri ve fiili veri toplamaya uymayan gizlilik politikası.

Apple yönergeleri dikkatlice takip ederseniz, çoğu uygulama ilk gönderimde 24-48 saat içinde onaylanır. Tüm uygulamalarımız arasında %95 ilk gönderim onay oranımız vardır. Reddedilen %5, genellikle aynı gün düzeltip yeniden göndereceğimiz küçük meta veri sorunları için.

Başlatmadan sonra: çoğu ekipin yanlış anladığı şeyler

MVP'yi göndermek bitiş çizgisi değil — başlangıç çizgisidir. Başlatmadan sonraki ilk iki hafta kritiktir. Birinci günden itibaren analitiklere ihtiyacınız var (Mixpanel veya PostHog kullanıyoruz), kullanıcı geri bildirimini toplama sistemi (sadece App Store incelemeleri değil, uygulama içi geri bildirim formu) ve ilk üç güncellemeniz için bir plan.

Gördüğümüz en yaygın hata: kurucular başlatır, mütevazı ilk çekim görürler ve bunun yerine işe yarayan şeyi iki katına çıkarmak yerine hemen v2 istek listesi özelliklerini oluşturmaya başlarlar. Verilerinizi dinleyin. Kullanıcılar temel akışı tamamlıyorsa ancak belirli bir adımda çıkıyorsa, o adımı düzeltin. Yeni bir özellik eklemeyin.

6 hafta sizin uygulamanız için gerçekçi mi?

Altı hafta çoğu MVP için işe yarar, ancak hepsi için değil. Düzenleyici uyum gerektiren uygulamalar (fintech, healthtech), karmaşık donanım entegrasyonları veya çok taraflı pazaryerleri tipik olarak 8-12 hafta gerektirir. Çerçeve aynıdır — kapsamı acımasızca daraltın, önce tasarım yapın, riskli parçaları önce oluşturun — sadece her aşama için daha fazla zamanlı.

Eğer bir fikriniz olan bir kurucu iseniz ve spesifik ürününüz için gerçekçi bir zaman çizelgesinin nasıl görüneceğini anlamak istiyorsanız, iletişime geçin. Size dürüst bir değerlendirme vereceğiz — ve eğer 6 hafta gerçekçi değilse, size nedenini ve doğru zaman çizelgesinin ne olduğunu söyleriz.