Geliştirici olmadan MVP nasıl yapılır ve kimsenin size baştan söylemediği şey

Kurmak darboğaz olmaktan çıktı. Neredeyse hiç kimse planını bunu hesaba katacak şekilde güncellemedi.

İşte bana sorulan soru ve onun altındaki soru.

Sorulan soru: ürünümü bir geliştirici işe almadan kurabilir miyim? Evet. 2026’da yapay zekâ araçlarına sahip tek kişilik bir kurucu, sekiz ile on altı hafta arasındaki klasik MVP takvimine karşı yaklaşık bir hafta içinde çalışan bir uygulamayı ayağa kaldırabiliyor; Altar.io’nun verileri ortalamayı dört aya daha yakın koyuyor, en yaygın takvim ise üç ay.

Altındaki soru: bu işleyecek mi? Ve dürüst cevap, bunun kurmakla hiç ilgisi olmayan şeylere bağlı olduğu.

CB Insights, girişim sermayesi destekli 431 başarısız şirketi analiz etti ve yüzde 43’ünün zayıf ürün pazar uyumundan başarısız olduğunu buldu. Yüzde 70’i “sermayesini tüketti”; aynı analiz bunu bir neden değil bir belirti olarak ele alıyor. Paranın tükenmesi, gerçek soruna giden yolda olan şey.

Bu başarısızlıkların hiçbiri yavaş geliştirmeden kaynaklanmadı. Bu da geliştirme darboğazını kaldırmanın, tek başına, o sayıyı oynatmadığı anlamına geliyor.

Tam olarak ne değişti

“Yazılım artık kolay” değil. Daha dar ve daha kullanışlı bir şey.

Bir uygulama üretmenin maliyeti çöktü. Uygulamanın ne olması gerektiğine karar vermenin maliyeti hiç kıpırdamadı.

Yirmi yıl boyunca geliştirme darboğazı o ikinci maliyeti gizledi. Kurmak dört ay ve 80 bin dolar sürdüğünde, o dört ay bir tür disiplini zorunlu kılıyordu: mühendislik çalışırken müşterilerle konuşacak zamanınız oluyordu ve masraf sizi taahhüt vermeden önce düşünmeye zorluyordu.

O dört ayı kaldırın ve düşünmek artık seçimlik. 2026’daki gerçek risk bu ve yeni bir risk. Yanlış şeyi eskisinden çok daha hızlı kurabilirsiniz ve yanlış olduğu hâlde etkileyici biçimde tamamlanmış görünecek.

Herhangi bir şey komutlamadan önce verilecek dört karar

Bir süreç değil. Dört soru ve hepsini bir öğleden sonrada cevaplayabilirsiniz.

1. Bu tam olarak kim için ve o kişiler bugün yerine ne yapıyor?

Bir pazar değil. Bir kişi ve onun şimdiki geçici çözümü: bir hesap tablosu, bir WhatsApp grubu, bir ajans, pazar günü üç saat. Geçici çözümü adlandıramıyorsanız sorunun gerçek olup olmadığını henüz bilmiyorsunuz, çünkü gerçekten acıtan sorunlar için herkesin bir geçici çözümü var.

2. Bunun yapması gereken tek şey ne?

Birinin gününü daha iyi kılan tek eylem. Geri kalan her şey ikinci sürüm. Bu artık eskisinden daha önemli, çünkü yapay zekâ araçları tanımladığınız dokuz özelliğin hepsini memnuniyetle kuracak ve dokuz özellik, kimsenin açıklayamadığı bir ürünle bitmenin yolu.

3. Ürününüzdeki şeyler neler ve birbirleriyle nasıl ilişkili?

Kurucuların atladığı bu ve altıncı ayın atlatılabilir olup olmadığını belirleyen bu. Kullanıcılar, siparişler, projeler, faturalar: adlarınız ne ise. Hangisi hangisine ait. Neyin tek olması gerekiyor. Biri silindiğinde ne oluyor.

Teknik sözcük dağarcığına ihtiyacınız yok. “Bir müşteri birçok projeye sahip olabilir, bir projenin tam olarak bir sahibi var, iki müşteri bir posta adresini paylaşamaz” bir veri modeli. Bunu yazmak on beş dakika ve tüm girişimdeki en kaldıraçlı on beş dakika. Sözcük dağarcığı yabancıysa teknik terimler sözlüğü bu terimleri, onları zaten bildiğinizi varsaymadan ele alıyor.

4. İşlediğini nasıl anlayacaksınız?

Sayıyı yayına almadan önce seçin, çünkü yayına aldıktan sonra cesaret verici görünen bir sayı bulacaksınız. Kayıtlar genellikle yanlış olan. Birinin ikinci kez geri gelip gelmediği genellikle doğru olan.

Üçüncü soru neden ısıran soru

Onu atladığınızda ne olduğu yüzünden.

Açıkça vermediğiniz her karar yine de veriliyor. Onu üretici, üretim anında, işinizi içermeyen bir bağlamdan veriyor. Araç durup iki müşterinin bir posta adresini paylaşıp paylaşamayacağını sormuyor. Makul bir şey seçip devam ediyor.

Sonra dördüncü ayda ekipler, faturalandırma ya da ikinci bir kullanıcı tipi eklemeniz gerekiyor ve ilk haftada sessizce seçilen cevabın o değişikliği bir ekleme değil bir yeniden inşa kıldığı ortaya çıkıyor. Her düzeltme başka bir şeyi bozuyor. Daha fazla komut durumu kötüleştiriyor.

Yapıcılar buna yüzde 70 sorunu diyor: uygulama neredeyse bitmiş hale varıyor ve ilerlemeyi bırakıyor. Engel hiçbir zaman eksik kod değil. Yüzlerce üretim önce örtük olarak verilmiş ve artık ucuza değiştirilemeyen bir karar.

Bunun sektör düzeyindeki sürümü ölçülebilir. DORA’nın 2025 araştırması, daha yüksek yapay zekâ kullanımının aynı zamanda yükselen yazılım teslim verimiyle ve yükselen kararsızlıkla ilişkili olduğunu buldu: daha hızlı ve daha kırılgan, birlikte. GitClear’ın 623 milyon kod değişikliği analizi, 2023 taban çizgisine göre tekrarlanmış kodun yüzde 81 yukarıda olduğunu, kodu düzenleme etkinliğinin ise 2022’de değişikliklerin yüzde 21’inden 2026’da yüzde 3,8’e düştüğünü buldu.

Üretim ucuz. Tutarlılık değil ve onu hiçbir şey tesadüfen üretmiyor. Bunu ele almak için kurulmuş uygulama spesifikasyon odaklı geliştirme ve savın mimari sürümü burada.

Gerçekte ne yapmalı, bu sırayla

1. Dört cevabı yazın. Bir sayfa. Bunu herhangi bir aracı açmadan önce yapın. Üçüncü soruyu cevaplayamıyorsanız kurmaya hazır değilsiniz: iki müşteriyle daha konuşmaya hazırsınız.
2. Bir aracı bu öğleden sonra ne olacağına göre değil altıncı ayda ne olacağına göre seçin. Bu kategorideki her seçenek bugün etkileyici bir şey üretecek. Sonradan onu hâlâ genişletebilip genişletemeyeceğiniz konusunda son derece ayrışıyorlar. Manzara, dürüstçe karşılaştırılmış.
3. O tek şeyi kurun. Biri birincisini iki kez kullanana kadar ikinci özelliğe direnin. Özellik eklemek neredeyse bedavayken bu, kulağa geldiğinden çok daha zor.
4. Onu elli değil beş gerçek kişinin önüne koyun. Soruna sahip beş kişi, kibar davranan elli kişiden fazlasını söyler. Beğenip beğenmediklerini sormak yerine nerede durduklarını izleyin.
5. O sayı hakkında ne yapacağınıza karar verin. Kimse geri gelmediyse cevap daha fazla özellik değil. Yine birinci soru.

Gerçekten hâlâ bir geliştiriciye ihtiyaç duyduğunuz şeyler

Size bir fantezi satmaktan çok bu konuda dürüst olmayı tercih ederim.

Yanlış olmanın pahalı olduğu her şey. Standart bir ödeme akışının ötesindeki ödemeler, sağlık verisi, düzenlemeye tabi her şey. Araçlar bunu üretemediği için değil, ürettiklerinin güvenli olup olmadığını değerlendiremediğiniz için ve o alanlarda “iyi görünüyordu” bir ölçüt değil.

Yük altındaki göçler. Üzerinde gerçek müşteriler olan canlı verinin biçimini değiştirmek gerçekten zor ve sessizce ters gidiyor.

İşlediği an. Bu iyi sorun. Kullanım büyüdüğünde sistemi anlayan birinin ona sahip çıkması gerekiyor. O işe alımı, kaçınılmamış bir başarısızlık değil bir başarı kilometre taşı olarak planlayın.

Muhtemelen bir geliştiriciye ihtiyaç duymadığınız şey: bunu isteyen biri olup olmadığını bildiğiniz noktaya varmak. Bu eskiden bir geliştirici gerektiriyordu. Artık gerektirmiyor ve bu, yararlanmaya değer gerçek bir değişim.

Etkileyici gösterimin tuzağı

Çalışan bir ekran, siz dahil, son derece ikna edici.

Onu insanlara göstereceksiniz ve cesaret verici olacaklar, çünkü cilalı bir arayüze bakmak, çalışma biçiminizi değiştirmenizin istenmesinden farklı bir tepki üretiyor. Cesaretlendirme kanıt değil. Gösterim yalnızca biri onu siz odada olmadan iki kez kullanırsa bir şey ifade eder.

Çirkin bir ürünü ve kırk geri dönen kullanıcısı olan bir kurucuyu, güzel bir ürünü ve dört yüz kaydı olup ikinci ziyareti olmayan birine tercih ederim. İkincisini elde etmek çok daha kolay ve ondan kurtulmak çok daha zor, çünkü ilerleme gibi hissettiriyor.

Kolaylaşmayan kısım

Şeyi artık bir haftada kurabilirsiniz. Bu gerçek, gerçekten yeni ve size öyle olmadığını söyleyen herkes son zamanlarda denemedi.

Ama o 431 başarısız şirketin yüzde 43’ü zayıf ürün pazar uyumundan öldü ve bir tanesi bile kurma çok uzun sürdüğü için ölmedi. Darboğaz taşındı. Her zaman zor kısım olan ve dört aylık mühendisliğin arkasında gizlenen kısma taşındı.

Hangi kararlar, hangi sırayla, kim için. İş artık bu. Zaten her zaman iş buydu.

Kurmak yalnızca onu bastıracak kadar gürültülüydü.

İlgili okumalar

Özellikle mimari kararlar üzerine: teknik olmayan kurucular için SaaS uygulama geliştirme. Araçların size gerçekte neye mal olacağı üzerine: simgeler, krediler ya da çaba.

Sıkça sorulan sorular

2026’da gerçekten geliştirici olmadan uygulama kurabilir misiniz? Evet. Teknik olmayan bir kurucu, sekiz ile on altı hafta arasındaki klasik MVP takvimine karşı yapay zekâ uygulama oluşturucularıyla kabaca bir hafta içinde çalışan bir uygulamayı canlıya alabilir. Kısıt artık onu kurup kuramayacağınız değil: başlamadan önce doğru şeylere karar verip vermediğiniz.

Bir MVP kurmak ne kadar sürüyor? Klasik olarak sekiz ile on altı hafta; veriler ortalamayı dört aya daha yakın ve üç ayı en yaygın takvim olarak koyuyor. Yapay zekâ araçlarıyla tek kişilik bir kurucu yaklaşık bir hafta içinde çalışan bir ürüne varabiliyor, ama o hız yalnızca altındaki kararlar bilinçle verilmişse yardım ediyor.

Kurmadan önce neye karar vermeliyim? Dört şeye: bunun kim için olduğu ve o kişilerin bugün yerine ne yaptığı, ürünün desteklemesi gereken tek eylem, ürününüzdeki şeylerin neler olduğu ve birbirleriyle nasıl ilişkili oldukları ve işlediğini size söyleyecek sayı. Üçüncüsü, kurucuların çoğunun atladığı ve sonradan en pahalı sorunlara neden olan olan.

Yapay zekâ ile kurulmuş MVP’ler neden birkaç ay sonra çalışmayı bırakıyor? Çünkü kimsenin açıkça vermediği kararlar üretici tarafından örtük olarak verildi ve o kararlar kendilerinden sonraki her şeyi kısıtlıyor. Bu yüzde 70 sorunu: uygulama neredeyse bitmiş hale varıp duruyor, çünkü engel eksik işlevsellik değil bir mimari seçim.

Bir MVP kurmak için veritabanlarını anlamam gerekiyor mu? Teknik sözcük dağarcığına ihtiyacınız yok ama ürününüzde hangi şeylerin var olduğunu ve nasıl ilişkili olduklarını söyleyebilmeniz gerekiyor. “Bir müşteri birçok projeye sahip olabilir, bir projenin bir sahibi var, iki müşteri bir posta adresini paylaşamaz” sade Türkçeyle ifade edilmiş bir veri modeli ve bunu yazmak yapabileceğiniz en değerli şeylerden biri.

Gerçekte ne zaman bir geliştirici işe almam gerekiyor? Yanlış olmanın pahalı olduğu her şey için (düzenlemeye tabi veri, standart ödeme akışının ötesindeki ödemeler), çünkü çıktının güvenli olup olmadığını değerlendiremiyorsunuz. Yük altında canlı veri göç ettirmek için. Ve ürün işlemeye başladığında ve birinin sisteme düzgün biçimde sahip çıkması gerektiğinde. O son maddeyi bir başarı kilometre taşı olarak ele alın.

Geliştirici olmadan bir MVP kurmak ne kadara mal olur? Araçlar, ne kadar yinelediğinize bağlı olarak ücretsiz kademelerden ayda birkaç yüz dolara kadar gidiyor; bu klasik bir kurmadan dramatik biçimde az. Kurucuları yakalayan maliyetler yayına almadan sonrakiler: kullanım büyüdükçe barındırma ve erken mimari sonraki özelliği kaldıramazsa yeniden inşa.