MVP Geliştirme Rehberi 2026: Türk Girişimciler İçin Teknik Playbook
MVP, piyasada yaygınlaştığından beri hem çok fazla hem de çok az anlama gelir hale geldi. Bu rehber, MVP'nin gerçekte ne olduğunu, neleri içermesi gerektiğini ve Türk girişimcilerin en sık yaptığı mimari hataları açıklıyor.
"MVP geliştir" tavsiyesi o kadar yaygınlaştı ki artık neredeyse anlamsız hale geldi. Bazı kurucular MVP'yi basit bir prototip olarak anlıyor. Bazıları her özelliği çıkarmak için bir bahane olarak kullanıyor. Bazıları ise tam tersine, MVP'yi tam ürünü geliştirirken "başlamak için" bir etiket olarak görüyor.
Bu rehber, MVP'nin teknik anlamını netleştiriyor — ne dahil edilmeli, ne ertelenmeli, mimari kararlar nasıl alınmalı ve KVKK uyumunu baştan nasıl inşa etmelisiniz.
MVP Nedir (ve Ne Değildir)?
MVP, üretime hazır, bilinçli olarak sınırlı kapsamlı bir sistemdir. Bu bir prototip değildir — gerçek verilerle gerçek kullanıcılara hizmet eden gerçek yazılımdır. Eksik olan ikinci, üçüncü ve dördüncü özellik katmanlarıdır.
MVP, "hızlı ve kirli" anlamına gelmez. MVP'nin mimarisi, tam ürünün üzerine inşa edileceği temeldir. Kötü mimariyle hızlı bir MVP, 6 ay sonra büyük bir yeniden yazım maliyetiyle karşınıza gelir.
MVP şu soruyu yanıtlamak içindir: Bu ürün için ödemeye istekli müşteriler var mı? Bu soruyu €40.000-€100.000 harcayarak yanıtlıyorsunuz, €500.000 harcayarak değil.
MVP'ye Dahil Edilmesi Gerekenler
Kimlik Doğrulama ve Yetkilendirme
Her SaaS MVP kimlik doğrulama ile başlar. Doğru yaklaşım: yönetilen bir hizmet kullanın (Supabase Auth, Auth0 veya Clerk). Kimlik doğrulamayı sıfırdan inşa etmek — güvenlik sertleştirme, token yönetimi, oturum yönetimi — haftalarca alır ve bir gram değer yaratmaz.
MVP için minimum kimlik doğrulama kapsamı:
- E-posta/şifre kaydı ve girişi
- Google OAuth (düşük sürtüşmeli giriş seçeneği)
- Şifre sıfırlama akışı
- E-posta doğrulaması
- Oturum yönetimi (HTTP-only cookie tercih edilir)
MVP'de ertelenmesi gerekenler: SSO/SAML (bir anlaşma kaybedene kadar), magic link girişi, çok faktörlü kimlik doğrulama (yüksek güvenlik gereksinimleri olmadan).
Multi-Tenant Veri İzolasyonu
B2B SaaS için multi-tenancy seçimlik değildir — ürünün tanımıdır. Ancak MVP aşamasında doğru uygulama sadeliği korur:
Paylaşımlı veritabanı, tenant_id ile: Her ilgili tabloya tenant_id kolonu ekleyin. ORM katmanında tenant bağlamı middleware'i her sorguya tenant filtresi ekler. Bu yaklaşım MVP için doğrudur.
Şema-başına-kiracı veya veritabanı-başına-kiracı ertelenmeli: Sözleşmesel izolasyon gereksinimleri olan enterprise müşterileriniz olana kadar bu karmaşıklık haklı değildir.
PostgreSQL kullananlar için satır düzeyinde güvenlik (Row-Level Security) — uygulama katmanının yanı sıra veritabanı düzeyinde izolasyonun ikinci bir savunma katmanı olarak — kurumsal kalite standartlar için önerilir.
Ödeme Entegrasyonu
MVP'de ödeme entegrasyonu Stripe üzerinden yapılır. Yapılması gerekenler:
- Abonelik oluşturma ve iptal akışı
- Webhook işleme (ödeme başarısız, abonelik iptal, fatura oluşturuldu)
- Kullanıcı portalı (Stripe'ın yerleşik müşteri portalı yeterlidir — sıfırdan inşa etmeyin)
- Deneme süresi mantığı
MVP'de ertelenmesi gerekenler: karmaşık koltuk bazlı faturalama, kullanıma dayalı faturalama, çoklu para birimi, muhasebe yazılımı entegrasyonu.
Temel Özellikler
MVP'nin temel özellik kapsamı genellikle en çok tartışılan alandır. Basit kural: yalnızca ödemeye istekli müşterileri kazanmak için gereken minimum özellik setini dahil edin.
Bu kural kulağa basit gelir ama uygulamada zordur. Kurucular doğal olarak ürünlerine özellik eklemek ister. Kapsamı disiplinli tutmanın en iyi yolu: her özellik için "Bu özellik olmadan bir müşteri ödeme yapar mıydı?" sorusunu sorun. Cevap hayırsa, erteleme listesine ekleyin.
MVP'de Ertelenmesi Gerekenler
| Özellik | Neden Ertelenmeli | Ne Zaman Eklenmeli |
|---|---|---|
| SSO/SAML | Önemli uygulama çabası; yalnızca enterprise müşteriler ister | İlk enterprise anlaşma kaybedildiğinde |
| API erişimi / geliştirici portalı | Entegrasyon kurucular için değerli, ilk müşteriler için değil | Müşteriler entegrasyon talep ettiğinde |
| Gelişmiş raporlama | İlk kullanıcılar veriden önce ürünü değerlendiriyor | Temel iş akışı doğrulandıktan sonra |
| Mobil uygulama | Web MVP daha hızlı ve daha ucuz doğrulama sağlar | Web ürünü doğrulandıktan sonra |
| White-labeling | Karmaşık altyapı; nadiren ilk ödeme kararını etkiler | Çoklu marka gereksinimi olan enterprise müşteriler için |
| İleri düzey izinler | Üç temel rol (Sahip/Admin/Üye) çoğu MVP için yeterlidir | Müşteriler daha granüler kontrol istediğinde |
Kritik Mimari Kararlar
Teknoloji Stack Seçimi
Teknoloji stack seçimi genellikle aşırı düşünülür. Pratik rehber: en iyi stack, ekibinizin en iyi bildiği ve hedef ölçekte üretim kanıtlanmış stacktir.
Modern SaaS MVP için yaygın ve sağlam bir yaklaşım: React veya Next.js (frontend), Node.js/Express veya Python/FastAPI (backend), PostgreSQL (veritabanı), AWS, GCP veya Hetzner (altyapı). Bu kombinasyon ölçeklenebilir, iyi belgelenmiş ve geniş bir yetenek havuzuna sahiptir.
Monolith mi Microservices mi?
MVP için her zaman monolith. Microservices mimarisi — doğru yapıldığında — ölçeklenebilirlik avantajları sağlar, ancak operasyonel karmaşıklık maliyeti getirir ki bu maliyet MVP aşamasında haklı değildir.
İyi yapılandırılmış bir monolith, iş gerektiğinde microservices'a bölünebilir. Kapsamı ve karmaşıklığı henüz belirsizken microservices başlamak, hizmetler arasındaki sınırları yanlış tanımlamanıza ve bunları yeniden tasarlamanıza neden olur.
Dağıtım Mimarisi
MVP için basit ve güvenilir bir dağıtım pipeline'ı:
- Kod deposu: GitHub veya GitLab
- CI/CD: GitHub Actions veya GitLab CI — her merge'de otomatik test ve deployment
- Staging ortamı: Production'dan önce değişiklikleri onaylayabileceğiniz ayrı ortam
- İzleme: Sentry (hata takibi), Datadog veya Grafana (metrikler), PagerDuty veya benzeri (uyarılar)
- Yedeklemeler: Veritabanı yedeklemeleri günlük, test edilmiş geri yükleme prosedürü ile
KVKK Uyumu: MVP'de Temel Gereksinimler
Türk kullanıcıların kişisel verilerini işliyorsanız, KVKK uyumu üretime çıkmadan önce temel düzeyde yerinde olmalıdır. MVP aşamasında minimum gereksinimler:
- Gizlilik bildirimi: Hangi verileri topladığınızı, neden topladığınızı ve nasıl işlendiğini açıklayan net bir sayfa. Kayıt akışından bağlantı verilmeli.
- Açık onay: Pazarlama iletişimi için açık onay toplayın. İşaretlenmiş kutular yeterli değil — kullanıcı aktif bir eylem gerçekleştirmelidir.
- Veri silme mekanizması: Kullanıcılar hesaplarını ve verilerini silmeyi talep edebilmelidir. Teknik altyapı bu talebi yerine getirebilmelidir.
- Güvenlik temelleri: Beklemedeki veriler için şifreleme (AES-256), iletim için TLS, kişisel veri erişim kontrolü ve temel denetim günlükleri.
KVKK uyumunu sonradan eklemek, genellikle veri modelini yeniden yazmanızı gerektirir. Başından itibaren uyumu inşa etmek hem daha ucuz hem de daha güvenlidir.
Zaman Çizelgesi: Gerçekçi Beklentiler
| Aşama | Süre | Temel Çıktılar |
|---|---|---|
| Discovery | 2 hafta | Gereksinim dokümanı, veri modeli tasarımı, API sözleşmeleri, mimari kararları |
| Temel Platform | 4-6 hafta | Kimlik doğrulama, multi-tenancy, temel özellikler, ödeme entegrasyonu |
| Özellik Tamamlama | 2-4 hafta | Kalan temel özellikler, admin paneli, e-posta bildirimleri |
| Test ve Sertleştirme | 2 hafta | QA, güvenlik testi, performans testi, KVKK doğrulama |
| Toplam | 10-14 hafta | Üretime hazır MVP |
Uyumluluk gereksinimleri veya karmaşık entegrasyonlar ekleyin: 14-20 hafta.
MVP Brief Nasıl Yazılır
İyi bir MVP brief, bir ajansa ne yaptırmak istediğinizi netleştirir. Özellik listesi değil — iş akışları ve sonuçlar üzerinden yazın.
Altı bölüm:
- Problem ve hedef kullanıcı: Kimin hangi sorununu çözüyorsunuz? Mevcut alternatifler neden yetersiz kalıyor?
- Temel iş akışları: Kullanıcı kim, ne yapıyor, adım adım. "Kullanıcı X yapar, ardından Y görür, ardından Z sonucu gerçekleşir" formatında.
- Kapsam dışı: Ne dahil değil? Bu madde, kapsam tartışmalarında sizi korur.
- Teknik kısıtlamalar: Entegre olunması gereken mevcut sistemler, veri kaynakları, uyumluluk gereksinimleri.
- Başarı kriterleri: MVP'nin "başarılı" sayılması için ne gerekiyor? İlk 10 ödeme yapan müşteri? Belirli bir dönüşüm oranı?
- Bütçe ve zaman kısıtlamaları: Bütçe aralığı ve hedef lansman tarihi.
Bu brief formatı, ajansla ilk görüşmede zaman kaybını önler ve hem tarafın ortak bir anlayışla başlamasını sağlar.
Ajans seçimi sürecinde ne sorulacağını öğrenmek için yazılım ajansı seçimi rehberimize bakın. SaaS maliyet bütçelemesi için SaaS geliştirme maliyeti makalemize bakın.
Sık Sorulan Sorular
MVP geliştirme ne kadar sürer?
3-4 kişilik ekiple SaaS MVP, sözleşmeden üretime 10-16 hafta sürer. Discovery dahil. Uyumluluk veya çok entegrasyon olan projeler 16-20 haftaya çıkabilir.
MVP'de multi-tenancy gerekli midir?
B2B SaaS için evet. Paylaşımlı veritabanı ve tenant_id yaklaşımı MVP için doğrudur. Şema veya veritabanı-başına-kiracı modelleri enterprise müşteriye kadar ertelenmelidir.
MVP'de kimlik doğrulama nasıl yapılmalı?
Yönetilen bir hizmet kullanın (Auth0, Supabase Auth veya Clerk). E-posta/şifre ve Google OAuth MVP için yeterlidir. SSO'yu bir anlaşma kaybedene kadar erteyin.
MVP maliyeti ne kadar?
SaaS MVP için €40.000-€100.000. Kimlik doğrulama, multi-tenancy, temel özellikler, ödeme ve KVKK temellerini kapsar. Bu aralığın altındaki teklifler önemli bileşenleri atladığını gösterir.
MVP brief nasıl yazılır?
Altı bölüm: problem ve hedef kullanıcı, temel iş akışları, kapsam dışı, teknik kısıtlamalar, başarı kriterleri, bütçe ve zaman kısıtlamaları. Özellik listesi değil, iş akışı odaklı yazın.