Yapay zekâ ile geliştirdiğiniz MVP müşterilere hazır mı? 12 kontrollük lansman planı

İlk sürümünüz ikna edici görünüyor. Panoyu gösterebiliyor, örnek bir kayıt oluşturabiliyor ve ödeme adımına kadar tıklayarak ilerleyebiliyorsunuz. Asıl zor soru şu: Uygulamanızı hiç görmemiş biri yarın aynı şeyi yapabilir mi? Bu yapay zekâ MVP canlıya alma kontrol listesi, ister Lovable, Bolt, Replit, Base44 ister başka bir araçla başlamış olun, tam da bu boşluk için hazırlandı.

Bir MVP için canlıya hazır olmak ne demek?

Canlıya hazır bir MVP, dar kapsamlı vaadini hedeflenen müşterilere güvenilir şekilde sunar; uygun erişim kontrollerine ve uygulanabilir bir kurtarma planına sahiptir. Yol haritanızdaki her özelliğe ya da henüz sahip olmadığınız bir kitle için tasarlanmış altyapıya ihtiyaç duymaz.

Aşağıdaki kontrolleri sürüm kanıtı olarak ele alın. Her biri için kimin test ettiğini, hangi URL ve sürümü kullandığını ve ne olduğunu kaydedin. Test edilmemiş bir maddeyi "bilinmiyor" olarak işaretleyin. Temiz görünen bir arayüz ya da sorunun düzeltildiğini söyleyen bir yapay zekâ mesajı test sonucu değildir.

Yeni bir kullanıcı ana akışı tamamlayabiliyor mu?

Yeni bir müşteri, sizin müdahaleniz olmadan ürünün işe yarar sonucuna ulaşabilmelidir. Tüm akışı yayındaki uygulamada; mevcut yetkisi, kayıtlı oturumu veya örnek verisi olmayan bir hesapla test edin.

• Kontrol 1 — İlk kullanım: Kaydolun, gerekiyorsa e-postayı doğrulayın, ilk işe yarar öğeyi oluşturun, çıkın ve geri dönün. Sözlü olarak açıklamak zorunda kaldığınız her talimatı not edin; akışı veya metinlerini iyileştirin.
• Kontrol 2 — Hesap kurtarma: Oturumu kapatın, destekleniyorsa şifreyi sıfırlayın, süresi dolmuş bir bağlantıyı açın ve oturum sona erdikten sonra geri dönün. Kurtarma işleminin canlı alan adına yönlendirdiğini ve müşterinin işine devam edebildiğini kontrol edin.

Kullanıcılar yalnızca erişmeleri gereken verilere mi erişiyor?

Kimlik doğrulama (authentication) kullanıcının kim olduğunu belirler; yetkilendirme (authorization) ise o kullanıcının neye erişebileceğini. Çalışan bir giriş ekranı, müşteri kayıtlarının, yüklenen dosyaların veya yönetici işlemlerinin korunduğunu kanıtlamaz.

Supabase kullanan uygulamalar için satır düzeyi güvenlik belgeleri, veritabanı politikalarının satır erişimini nasıl kısıtladığını açıklar. Uygulamanızı gerçek sahiplik kurallarınıza göre incelettirin. Diğer backend'ler de kendi yetki modelleriyle eşdeğer kontrollere ihtiyaç duyar.

• Kontrol 3 — Müşteri izolasyonu: Her birinin özel bir kaydı olan iki sıradan kullanıcı oluşturun. Bir istekteki kayıt kimliğini değiştirmenin, diğer kullanıcının kaydını açığa çıkaramadığını veya değiştiremediğini bir geliştiriciye doğrulatın.
• Kontrol 4 — Ayrıcalıklı işlemler: Sıradan bir kullanıcının kendine ücretli plan tanımlayamadığını, yönetici davet edemediğini veya URL tahmin ederek özel yüklemelere erişemediğini sunucu tarafında doğrulayın. Aynı kontrolü oturum kapalıyken tekrarlayın.

Ödemeler ve entegrasyonlar hatalara dayanıyor mu?

Güvenilir bir entegrasyon, hataları ve yeniden denemeleri iş kaybetmeden veya yanlış erişim vermeden yönetir. Başarıyı ödeme animasyonuna bakarak değil, uygulamanızın kaydettiği duruma bakarak doğrulayın.

Stripe kullanıyorsanız, webhook belgeleri asenkron ödeme olaylarını, imza doğrulamayı ve yinelenen teslimatları açıklar. Entegrasyonunuz gelen olayları doğrulamalı ve aynı olayı iki kez işlemekten kaçınmalıdır. Hangi olayların söz konusu olduğu ödeme akışınıza bağlıdır.

• Kontrol 5 — Ödeme durumu: Sağlayıcının test ortamında başarılı, başarısız, iptal edilmiş ve gecikmiş ödemeleri test edin. Erişimin yalnızca uygun ve doğrulanmış sunucu tarafı olayı geldiğinde değiştiğini teyit edin.
• Kontrol 6 — Harici hata: Kontrollü bir testte e-posta sağlayıcısını, yapay zekâ hizmetini veya gerekli başka bir entegrasyonu başarısız hâle getirin. Kullanıcı anlaşılır bir sonuç görmeli ve yinelenen ücretlendirme ya da yinelenen kayıt oluşmadan güvenle yeniden deneyebilmelidir.

Canlı uygulama doğru verileri koruyacak mı?

Yayındaki uygulama, hedeflenen canlı ortam veritabanına bağlanmalı ve müşteri dosyaları için kalıcı depolama kullanmalıdır. Verilerle dolu bir önizleme, canlı uygulamanın aynı kuruluma sahip olduğunu kanıtlamaz.

• Kontrol 7 — Ortam ayrımı: Her ortamın hangi veritabanını kullandığını belirleyin. Bir özelliği test etmenin canlı müşteri kayıtlarını değiştiremeyeceğini doğrulayın ve onaylanan şema değişikliklerinin canlı ortama nasıl taşındığını belgeleyin.
• Kontrol 8 — Kalıcılık ve kurtarma: Bir kayıt kaydedin ve bir dosya yükleyin; ardından kontrollü bir yeniden başlatma veya dağıtım sonrasında erişilebilir olup olmadıklarını test edin. Yedeklemenin sorumlusunu belirleyin ve sürece güvenmeden önce kurtarmayı güvenli bir kopya üzerinde prova edin.

Replit, ayrı geliştirme ve canlı ortam veritabanlarını açıkça belgeler. Hangi aracı kullanırsanız kullanın aynı pratik soruları sorun: Canlı veri nerede, onu kim değiştirebilir ve nasıl geri getiririz? Her platformun aynı şekilde davrandığını varsaymak yerine hesabınızın imkânlarını kontrol edin.

Bir hatayı fark edip bir sürümü geri alabiliyor musunuz?

Birinin başarısız bir müşteri akışını fark etmesi ve sonrasında ne yapacağını bilmesi gerekir. Hata görünürlüğü ve bir kurtarma prosedürü, küçük bir lansmanı yönetmeyi çok daha kolaylaştırır.

• Kontrol 9 — İşe yarar hata kanıtı: Zararsız bir test hatası tetikleyin ve ilgili sunucu hatasını veya başarısız isteği bulun. Şifreleri, özel belgeleri veya ödeme bilgilerini loglamadan zamanı ve işlemi kaydedin.
• Kontrol 10 — Sürüm kurtarma: Bilinen son çalışan kod sürümünü, onu kimin geri yükleyebileceğini ve hangi veritabanı değişikliklerini beklediğini belirleyin. Kodu geri yüklemek, veri değişikliklerini otomatik olarak geri almanın bir yolu değildir; iki prosedürü ayrı ayrı prova edin.

Ürün, demo kurulumunuzun dışında da çalışıyor mu?

Müşteriye açılan bir sürüm, ilk kullanıcılarınızın gerçekten sahip olduğu cihazlarda ve ağ koşullarında çalışmalıdır. Ürünü yalnızca kısa örnek isimlerle ve hızlı bir ofis bağlantısıyla değil, gerçekçi içerikle kontrol edin.

• Kontrol 11 — Günlük kullanılabilirlik: Ana akışı dar bir telefon ekranında ve klavyeyle gezinerek tamamlayın. Uzun isimleri, boş listeleri, doğrulama hatalarını ve yarıda kesilen yüklemeleri deneyin. Yükleme ve hata durumlarını anlaşılır hâle getirin.
• Kontrol 12 — Hedeflenen lansman yükü: İlk kitle üzerinde anlaşın ve temsili miktarda veri ile eşzamanlı etkinliği test edin. Yanıt sürelerini ve kaynak kullanımını gözlemleyin. Destekleniyorsa bir harcama limiti veya uyarı tanımlayın ve birinin ne zaman inceleme yapması gerektiğini belirleyin.

Müşterileri davet etmeden önce neyi düzeltmelisiniz?

Kitleyi genişletmeden önce bozuk ana akışları, hatalı ödeme erişimini ve uygunsuz veri erişimini düzeltin. İsteğe bağlı özellikleri ve görsel iyileştirmeleri bu önceliklerin etrafında planlayın.

Varsayımsal bir randevu uygulamasını düşünün: Rezervasyon kurucu için çalışıyor, ancak yeni bir kullanıcı hesabını kurtaramıyor, başarısız bir ödeme yine de onaylanmış bir rezervasyon oluşturuyor ve iki sekme aynı saati ayırabiliyor. Bir sonraki sürüm bu akışları onarmalıdır. Sohbet eklemek veya panoyu yeniden tasarlamak lansmanı engelleyen sorunları çözmez.

Hata ayıklama sürecinin kendisi tıkandıysa Lovable ve Bolt hata döngüsü rehberine göz atın. Bir sonraki adım mobil içeriyorsa mevcut Lovable App Store rehberini inceleyin. Uygulamalı destek için MVP'nizi canlıya taşımak üzerine bir görüşme planlayın. Uygulama bağlantısını ve başarısız kontrollerinizi getirin; bir sonraki sürümün kapsamını kanıtlara dayanarak belirleyebiliriz.