Bir MVP’yi nasıl kurardım - ve stack’i gerçekten nasıl seçerim

Yarın benden bir MVP kurmam istense, 40 framework’lük bir tablo açmazdım. Mikroservis haritası çizmezdim. Daha ödeyen bir kullanıcıyla tanışmamış bir ürünü «geleceğe dayanıklı» yapmazdım. Bir cümle yazardım: bu kimin için, hangi işi yapıyor, dört haftada ne ölçeceğiz. Stack o cümleden sonra gelir - önce değil.

Başarısız MVP’lerin çoğu çok küçük değildir. Sahte-büyüktür: auth, panel, bildirim ve üç ortamı olan yarım bir «platform» - ve fikri kanıtlayacak o tek işi hâlâ kimse bitirmemiştir. Teknoloji çoğu zaman bahanedir. Bu yazı, gerçekten nasıl teslim ederdim.

1. MVP nedir - ve neye öyle demeyi reddederim

MVP «daha az ekranlı sürüm 1» değildir. En riskli varsayımı öldürebilecek veya güçlendirebilecek en ucuz deneydir. Varsayım «insanlar bu hizmeti online rezerve etmek için ödeyecek» ise, MVP rezervasyon akışı artı ödeme artı diğer uçta bir insandır - CRM değil, sadakat programı değil, native uygulama değil.

• Viable demek: gerçek bir kullanıcı gerçek bir işi bitirebilir. Tıklanabilir bir Figma prototipi araştırmadır, MVP değildir.
• Minimum demek: o işe yaramayan her şey sonraki bir iş kartıdır - «eklemesi kolay» görünse bile.
• Product demek: gelecek hafta kahramanlık olmadan tekrarlayabilirsiniz. Google Form artı bir tablo MVP olabilir. Netflix mimarisini yeniden yazmak olamaz.

2. Bir repo var olmadan önce beş soru

Stack tartışmaları ucuzdur. Cevapsız ürün soruları pahalıdır. Bunu sesli yanıtlayana kadar Postgres’i Mongo’ya karşı seçmem - kurucuyla, bir blog yazısıyla değil.

• İlk on kullanıcı kim, mümkünse adıyla - «telefonu olan herkes» değil.
• Bu ay ürünü hangi tek iş için «işe alıyorlar»? Bir. Platform değil.
• Para veya sinyal nereden geliyor - kart çekimi, imzalı sözleşme, rezerve slot, nitelikli lead?
• Hangi kısıt gerçek: dört hafta, bir geliştirici, düzenlenen bir alan, mevcut bir CRM, bir Telegram kitlesi?
• Bizi ne durdurur? Bir kesme ölçütü adlandıramıyorsak, deney değil hobi kuruyoruz.

3. Teknoloji seçmek için beş filtre

Araçları trend oldukları için seçmem. Solo bir geliştirici, küçük bir bütçe ve ilk öfkeli kullanıcıyla teması atlattıkları için seçerim. Her teknoloji bu filtrelerden geçer.

• İlk gerçek kullanıcıya kadar süre. Stack ilk tıklamadan önce bir hafta ekliyorsa, MVP için yanlış stack’tir. Production’da zaten teslim ettiğim sıkıcı araçlar, deadline altında öğreneceğim moda bir araçtan iyidir.
• Tek kişiyle işletilebilir. Platform ekibi olmadan deploy edebilmeli, log okuyabilmeli, yedek geri yükleyebilmeli ve bir anahtar döndürebilmeliyim. Kubernetes bu testi neredeyse her erken ürün için kaybeder.
• İşe alınabilir ve değiştirilebilir. TypeScript, Postgres ve React heyecan verici değildir. Başka iyi insanların zaten konuştuğu dillerdir. Yalnızca benim genişletebildiğim bir MVP rehindir, varlık değil.
• Verinin ağırlığı. Kullanıcı ve para varsa, gerçek kaynak birinci günden göçlü gerçek bir veritabanındadır. Tablolar ürünün yanındaki deney için olur - ödeme adımının içinde değil.
• Kaçış kapağı. Managed auth, hosted Postgres, bir ödeme sağlayıcısı kullanırım. Dışa aktarması acıtan beş yıllık kilit imzalamam. Tedarikçi olur. Tuzak olmaz.

4. 2026’da başlayacağım varsayılan web stack

Tipik bir B2B veya hizmet MVP’si için - rezervasyon, lead yakalama, küçük müşteri portalı, teklife dönüşen hesaplayıcı - buradan başlardım. Moda olduğu için değil. Teslim edebildiğim, SEO yapabildiğim ve altı ay içinde başka birini işe alabildiğim için.

• Next.js + TypeScript + Tailwind: pazarlama sayfaları (SEO, sunucu render) ve ürün UI’si için bir uygulama. Daha az repo, bir deploy, paylaşılan tipler. Ekip zaten biliyorsa App Router olur; çalışan bir Pages uygulamasını «saflık için» yeniden yazmam.
• Postgres (çoğu zaman Supabase, Neon veya küçük bir VPS ile): ilişkisel veri, işlem ve gece 2’de okuyabileceğim SQL. Belge deposuna yalnızca şekil gerçekten belgesel ise uzanırım - «NoSQL daha hızlı» diye değil.
• Auth: ürün auth değilse yönetilen bir sağlayıcı (Clerk, Auth.js + bilinen bir IdP, veya Supabase Auth). Birinci haftada özel oturum, token sızıntısının ve asıl özelliğin durmasının yoludur.
• Ödemeler: Stripe (veya ilk kullanıcıların gerçekten kullandığı yerel eşdeğer). Ev yapımı fatura motoru yok. Faturalar bekleyebilir; çalışan bir çekim bekleyemez.
• Hosting: trafik «web» ve ekip önizleme istiyorsa Next.js uygulaması için Vercel; uzun worker, öngörülebilir maliyet veya veri yerleşimi gerekiyorsa Hetzner/VPS + Docker Compose. Bu dengeyi ayrıca yazdım. MVP kuralı: anladığınız bir ortam, gece yedek, HTTPS, bir alan adı.
• E-posta ve dosyalar: Resend veya benzer bir işlem API’si; S3 uyumlu depolama. «Ekler modülü kuracağız» değil.

5. Varsayılanı ne zaman bırakırım

Varsayılan bir başlangıç bahsidir, din değil. Kısıt ürün olduğunda değiştiririm.

• Kitle zaten Telegram’da yaşıyorsa: bir bot veya Mini App tüm MVP olabilir. Açmayacakları bir site «daha profesyonel» değildir. İkinci boş bir odadır.
• İş zayıf sinyalli sahadaysa: birinci haftada native yeniden yazım değil, local-first veya PWA’ya bakarım. Native bir dağıtım kararıdır, rozet değil.
• Çekirdek dildir (destek, teklif, belge çıkarımı): sıkı bir şema ve insan inceleme adımı arkasına bir LLM API eklerim. Bir sohbet widget’ını sarıp ürün demem.
• Kurucu operatör ve içerik üründür: hızlı bir site artı gerçekten kullanacakları bir CMS, özel admin’i geride bırakabilir. İş uygulama kurmak değil yayınlamaksa WordPress hâlâ serbesttir.
• İki taraflı pazar yeri: yine de önce bir tarafı teslim ederim. Arz veya talep - hangisi daha zor. Her iki tarafta boş sandalyeli bir «platform», fazla tablolu bir landing’dir.

6. İlk kullanıcılardan önce eklemeyi reddettiğim şeyler

Deneyi kaçırmanın en hızlı yolu, deneyi şirketin etrafına kurmaktır. Bu liste backlog’un yanında durur.

• Mikroservis, mesaj bus’ı ve Kubernetes. Bir süreç, bir veritabanı, bir deploy. Gerçek bir darboğaz veya gerçek bir ekip sınırı belirdiğinde bölün - diyagram kıdemli durduğu için değil.
• 80 token’lı, sıfır ekranlı bir design system. Parayı toplayan üç ekranı teslim edin. Üçüncü kopyala-yapıştır acıdığında bileşen çıkarın.
• Roller, izinler, denetim günlüğü ve SSO - ödeyen bir B2B alıcı anlaşmayı onlara takmadıkça yok. O zaman MVP olurlar, yan görev değil.
• İkinci bir mobil uygulama. Gördüğüm çoğu hizmet işinde responsive web veya Mini App ilk yüz kullanıcıyı karşılar.
• Yapıştırıcı kodun kusursuz test kapsamı. Para, auth ve asıl iş için test isterim. Bir landing formu için bir haftalık mock istemem.

7. İlk dört hafta gerçekten nasıl görünürdü

Takvimi bir ürün kararı olarak ele alırım. Haftaları tarif edemiyorsak planımız yoktur - bir dileğimiz vardır.

• Hafta 0 (iki gün, iki hafta değil): tek sayfalık özet. Kullanıcı, iş, kesme ölçütü, yapılmayacaklar. Üç ekranı çizin. «Bitti» üzerinde anlaşın: bir yabancı, Zoom’umuz olmadan işi bitirebilir.
• Hafta 1: dikey dilim. Alan adı, deploy, veritabanı, boş yerleşim, production’da bir mutlu yol (çirkin olsa da). Üçüncü günde deploy edemiyorsak stack zaten yalan söylüyor.
• Hafta 2: iş. Rezervasyon, teklif, yükleme, ödeme - hafta 0’da adlandırdığımız. Arayüz arkasındaki elle işlem serbest: döngüyü kapatıyorsa sahibe Telegram ping bir özelliktir.
• Hafta 3: çirkin kenarlar. Boş durumlar, hatalar, mobil, e-posta, temel analitiks (nerede düştükleri). Veri ambarı değil. Okunabilir bir huni.
• Hafta 4: adı olan on kişinin önüne koyun. İzleyin. Görüşme sırasında özellik eklemeyin. İstediklerini söyledikleri şeyi değil, yaptıklarını yazın.

8. Lansmandan sonra: tut, çıkar veya yeniden yaz

İyi bir MVP biraz utandırıcı olma hakkına sahiptir. Tuzak olma hakkına sahip değildir. Yukarıdaki stack kasten sıkıcıdır: içine büyüyebilirsiniz. İlk yıl ondan çıkmanız nadirdir.

• Tutun: dil, veritabanı, koddaki alan adları. Birlikte yaşaması ucuz, atması pahalı.
• Çıkarın: bir worker, ikinci bir servis, gerçek bir kuyruk - iş yavaş, tehlikeli veya başka bir ekibe ait olduğunda. Daha önce değil.
• Yalnızca yanlış dersi öğrenen parçayı yeniden yazın. Checkout yanlışsa checkout’u yeniden yazın. Tüm uygulama vibe-coded bir labirentse: önce insan sorunudur. Birisi gece 2’de açıklayabilmelidir.

Sonuç: ilk hayıra dayanan stack’i seçin

MVP’yi süssüz kurardım: bir iş, bir veritabanı, bir deploy, tek başıma işletebileceğim araçlar, ve devam mı dur mu diyeceğimiz bir tarih. «En iyi» teknoloji o karardan bizi saptırmayandır. Next.js, TypeScript, Postgres, managed auth ve bir ödeme sağlayıcısı bir kişilik değildir. Kıt haftaları platforma değil ürüne harcamanın yoludur.

Bir fikriniz, bir son tarihiniz ve «yanlış» stack seçme korkunuz varsa - iletişim bölümünden yazın. Tek işi çerçeveleyebilir, yapılmayacakları adlandırabilir ve önce sahte bir platform kurmadan gerçek insanların önüne koyabileceğiniz bir dilim teslim edebiliriz.