# MVP nasıl yapılır? Ürünü küçük başlatıp gerçek kullanıcıyla sınamak

> MVP, bir ürün fikrini en az işle gerçek kullanıcı önünde sınayan ilk sürümdür. MVP yapmak için önce sınanacak tek bir varsayım yazılır, sonra özellikler olmazsa olmaz, sonra ve hiç diye üçe ayrılır ve sadece ilk kova yapılır. Süre ve bütçe baştan sabitlenir, ölçüm ilk günden kurulur ve MVP sonrası karar veriye göre verilir.

- Adres: https://radkod.com/blog/mvp-nasil-yapilir
- Yayıncı: RadKod
- Yayın: 2026-09-12

## Kısaca

- MVP, bir ürün fikrini en az işle gerçek kullanıcı önünde sınayan ilk sürümdür.
- MVP yarım ürün değildir. Az şey yapar ama yaptığını düzgün yapar.
- Kapsam üç kovaya ayrılır: olmazsa olmaz, sonra ve hiç. Sadece ilk kova yapılır.
- Süre ve bütçe baştan sabitlenir, kapsam onlara göre kesilir.
- Ölçüm ilk günden kurulur. MVP sonrası karar görüşe değil veriye göre verilir.

## MVP nedir ve MVP nasıl yapılır?

MVP, bir ürün fikrini en az işle gerçek kullanıcı önünde sınayan ilk sürümdür ve MVP şu sırayla yapılır: sınanacak varsayım yazılır, kapsam en küçük hâline indirilir, süre ve bütçe sabitlenir, ölçüm kurulur ve ürün gerçek kullanıcıya açılır. İngilizcede minimum viable product denir. Türkçede "en küçük çalışan ürün" diye düşünebilirsiniz. Terimi sözlükteki [MVP](/sozluk/mvp) maddesinde kısaca açıkladık.

MVP'nin amacı ürünü ucuza yapmak değildir. Amaç, büyük bir bütçeyi harcamadan önce doğru şeyi yapıp yapmadığınızı öğrenmektir. Bir fikrin tutup tutmayacağını toplantı odasında bilemezsiniz. Kullanıcı ürünü açar, dener, geri döner ya da dönmez. MVP bu cevabı en kısa yoldan almanın yoludur.

Bu yazıda bir MVP'yi nasıl kurguladığımızı anlatıyoruz: neyin MVP olmadığı, kapsamın nasıl daraltıldığı, süre ve bütçenin nasıl belirlendiği, neyin ölçüleceği ve MVP'den sonra ne yapılacağı.

## MVP ne değildir?

MVP yarım bir ürün, bir demo ya da tüm özelliklerin kötü yapılmış bir sürümü değildir. En sık karışan dört şey şunlardır:

- **Yarım ürün değildir:** Az şey yapar ama yaptığı şeyi baştan sona, hatasız yapar. Kullanıcı bir işi başlatıp bitirebilmelidir.
- **Prototip değildir:** [Prototip](/sozluk/prototip) fikri göstermek için yapılır, çoğu zaman gerçek veriyle çalışmaz. MVP ise gerçek kullanıcıya açılır ve gerçek veri üretir.
- **Ucuz sürüm değildir:** Her özelliği yarım yapmak yerine az özelliği tam yapmaktır. On özelliğin yüzde 50'si değil, üç özelliğin yüzde 100'üdür.
- **Atılacak kod değildir:** MVP başarılı olursa üzerine inşa edilir. Bu yüzden kodu, veri yapısı ve hesapları ilk günden düzgün kurulmalıdır.

Son madde çoğu zaman gözden kaçar. "Nasılsa MVP" diye aceleyle yazılan kod, ürün tuttuğunda en büyük engel olur. Ürün tuttuğu anda baştan yazmak zorunda kalmak, MVP'nin kazandırdığı zamanı geri alır.

## MVP'nin kapsamı nasıl daraltılır?

MVP'nin kapsamı, her özelliği üç kovadan birine koyarak daraltılır: olmazsa olmaz, sonra ve hiç. Olmazsa olmaz kovası, sınamak istediğiniz varsayım için zorunlu olan özelliklerdir. Sonra kovası, ürün tutarsa eklenecek olanlardır. Hiç kovası ise aslında kimsenin istemediği ama listeye girmiş fikirlerdir.

Her özellik için tek bir soru sorun: "Bu olmazsa kullanıcı ana işi yapabilir mi?" Yapabiliyorsa o özellik olmazsa olmaz değildir. Bu soru acımasız görünür ama işe yarar. Çoğu listede özelliklerin yarısından fazlası sonra kovasına düşer.

Aşağıdaki tablo, küçük işletmeler için bir randevu uygulaması fikrinde bu ayrımı nasıl yaptığımızı gösteren bir örnektir.

**Örnek: randevu uygulaması fikrinde özelliklerin üç kovaya ayrılması**

| Özellik | Kova | Gerekçe |
| --- | --- | --- |
| Müşterinin boş saati seçip randevu alması | Olmazsa olmaz | Sınanan varsayımın kendisi budur. |
| İşletmenin randevuları tek ekranda görmesi | Olmazsa olmaz | İşletme görmezse randevu işe yaramaz. |
| Randevu öncesi hatırlatma mesajı | Olmazsa olmaz | Gelmeyen müşteri sorununu çözmek varsayımın parçasıdır. |
| Online ödeme | Sonra | Önce randevunun alınıp alınmadığını görmek gerekir. Ödeme ikinci adımdır. |
| Çoklu şube desteği | Sonra | İlk kullanıcılar tek şubeli işletmelerdir. |
| Sadakat puanı | Sonra | Tekrar gelen müşteri varsa anlam kazanır. |
| Yorum ve puanlama | Hiç | Varsayımla ilgisi yok. Kimse istemedi. |
| Sosyal medya paylaşımı | Hiç | Ana işi kolaylaştırmıyor. |

## MVP nasıl yapılır: altı adım

1. **Sınanacak varsayımı yazın** — Tek cümle: "Küçük işletmelerin müşterileri randevuyu telefon yerine uygulamadan almak ister." MVP bu cümlenin doğru olup olmadığını sınar. Birden fazla varsayım varsa en riskli olanı seçin.
2. **Tek kullanıcı tipi seçin** — İlk sürüm herkese hitap etmez. Kimin için olduğunu dar tanımlayın. Dar tanım, kapsamı da kendiliğinden daraltır.
3. **Ana akışı çizin** — Kullanıcının baştan sona izlediği tek yolu adım adım yazın. Bu yolda olmayan her ekran MVP dışıdır.
4. **Özellikleri üç kovaya ayırın** — Olmazsa olmaz, sonra ve hiç. Olmazsa olmaz kovası kalabalıksa bir tur daha kesin.
5. **Süreyi, bütçeyi ve bitiş tanımını sabitleyin** — Bitiş tarihini ve bütçeyi yazın, kapsamı onlara sığdırın. İşin ne zaman bitmiş sayılacağını ölçülebilir maddelerle ilk gün imzalayın.
6. **Ölçümü kurup yayına alın** — Neyi ölçeceğinizi yayından önce belirleyin ve ölçümü kurun. Sonra ürünü gerçek kullanıcılara açın.

## MVP ne kadar sürer?

MVP'nin süresi kapsama bağlıdır ama iyi kurgulanmış bir MVP genellikle birkaç hafta ile birkaç ay arasında yayına çıkar. Süre bundan uzuyorsa kapsam büyük olasılıkla MVP olmaktan çıkmıştır. Altı ay süren bir ilk sürüm, altı ay boyunca hiçbir şey öğrenmemek demektir.

Biz süreyi kapsamdan sonra değil, kapsamla birlikte belirleriz. Tarih önce konur, sonra olmazsa olmaz kovası o tarihe sığacak kadar daraltılır. Sığmıyorsa tarih ileri itilmez. Kova bir tur daha kesilir. Bu yaklaşım, bitiş tarihinin gerçekten tutmasını sağlar. Bizde bitiş tarihi ilk gün yazılır ve söz verilen günde teslim edilir.

## MVP bütçesi nasıl belirlenir?

MVP bütçesi, "bu varsayımı öğrenmek için ne kadar harcamaya razıyım" sorusuyla belirlenir. Bütçe önce konur, kapsam ona göre kesilir. Tersini yapmak, yani önce tüm özellikleri yazıp sonra fiyatını sormak, MVP'yi tam ürüne dönüştürür.

Fiyatı en çok artıran kalemler şunlardır: kullanıcı tipi sayısı, entegrasyonlar, ödeme, çoklu dil, yönetim paneli ihtiyacı ve hem web hem mobil için ayrı ayrı arayüz. Her biri kendi başına makuldür. Hepsi birlikte ilk sürüme girdiğinde MVP ortadan kalkar. Mobil tarafta maliyeti belirleyen etkenleri [mobil uygulama maliyeti](/blog/mobil-uygulama-maliyeti) yazısında ayrıntılı anlattık.

Kesin bir rakam vermiyoruz, çünkü rakam kapsama göre değişir. Ama şu kural genelde geçerlidir: MVP bütçesinin bir kısmını yayından sonraki ilk düzeltmeler ve ilk eklemeler için ayırın. İlk kullanıcı geri bildirimleri mutlaka bir şey değiştirecektir.

## MVP web mi olmalı, mobil uygulama mı?

Varsayım telefona özgü bir şey gerektirmiyorsa MVP çoğu zaman web olarak daha hızlı yayına çıkar. Web sürümü mağaza incelemesine takılmaz, güncellemesi anında yayına girer ve bağlantıyla paylaşılır. Bildirim, kamera, konum ya da çevrimdışı çalışma varsayımın parçasıysa mobil uygulama gerekir.

Mobil MVP yapılacaksa iki şeye dikkat edin. Birincisi, App Store ve Google Play inceleme kurallarına uyulması gerekir. Apple'ın inceleme kuralları, yeterli işlev sunmayan uygulamaları reddedebileceğini açıkça yazar. Yani mağazadaki bir MVP de gerçekten çalışan bir ürün olmalıdır. İkincisi, iki platform için tek kod tabanı çoğu MVP'de zaman kazandırır. Bu kararın ayrıntıları [native mi Flutter mı](/blog/native-mi-flutter-mi) yazısında.

## MVP'de ne ölçülür?

MVP'de, sınanan varsayımın doğru olup olmadığını gösteren tek bir ana ölçü ve onu destekleyen birkaç yan ölçü takip edilir. Ana ölçü baştan yazılır. Randevu örneğinde bu, "ilk ay içinde uygulamadan alınan randevu sayısı" ve "ikinci kez randevu alan müşteri oranı" olabilir.

- **Başlama:** Kaç kişi ürünü açtı ve ana akışı başlattı?
- **Tamamlama:** Başlayanların kaçı ana işi bitirdi? Nerede bıraktılar?
- **Geri dönüş:** Kullanıcılar bir hafta ya da bir ay sonra tekrar geldi mi?
- **Nitel geri bildirim:** Beş on kullanıcıyla yapılan kısa görüşmeler. Sayılar neyin olduğunu, görüşmeler nedenini gösterir.

Başarı eşiğini de yayından önce yazın. "Yüz randevu alınırsa devam ederiz" gibi. Eşik baştan yazılmazsa, sonuçlar ne olursa olsun yorumlanarak başarılı sayılır. Ölçüm kurulmadan yayına çıkan MVP ise sadece bir izlenim bırakır, bilgi bırakmaz.

## MVP sonrası yol haritası nasıl çıkarılır?

MVP sonrası yol haritası, ölçüm sonuçlarına göre üç karardan biri verilerek çıkarılır: devam, değiştir ya da durdur. Devam kararı çıkarsa sonra kovası veriye göre yeniden sıralanır. Kullanıcıların en çok takıldığı yer ya da en çok istediği şey ilk sıraya gelir. Değiştir kararı çıkarsa varsayım yeniden yazılır ve aynı döngü daha küçük bir kapsamla tekrarlanır. Durdur kararı da bir sonuçtur. Büyük bütçeyi harcamadan öğrenilmiş bir sonuçtur.

Yol haritasında iki kalemi unutmayın. Birincisi, MVP sırasında bilerek ertelenen teknik işler. Hız için bırakılan kısayollar listelenmeli ve büyümeden önce kapatılmalıdır. İkincisi, altyapı. Kullanıcı sayısı artınca sunucu, yedekleme ve izleme ihtiyacı da artar. Her yeni aşamaya da ayrı bir bitiş tanımı yazılır.

## Her şeyi yazılımla yapmak gerekir mi?

Hayır, MVP'de bazı işler bilerek elle yürütülebilir. Randevu örneğinde hatırlatma mesajları ilk haftalarda elle gönderilebilir, raporlar bir tabloda tutulabilir, yeni işletmeler tek tek sisteme eklenebilir. Kullanıcı bunu fark etmez. Siz ise o işi otomatikleştirmeye değer mi, önce görürsünüz.

Bu yaklaşımın bir sınırı vardır. Sınanan varsayımın kendisi elle yapılamaz. Kullanıcının randevuyu uygulamadan alıp almadığını ölçüyorsanız, randevu alma akışı gerçekten çalışmalıdır. Elle yürütülen kısım ancak varsayımın dışında kalan işlerdir. Hangi işin elle yürütüleceği de kapsamla birlikte yazılır, böylece "sonra otomatikleştiririz" sözü unutulmaz ve MVP sonrası yol haritasında kendi satırını alır.

## MVP yaparken en sık yapılan hatalar nelerdir?

En sık yapılan hata, MVP'ye sürekli özellik eklemektir. Diğerleri de genellikle aynı kökten gelir:

- Varsayımı yazmadan işe başlamak.
- İlk sürümde birden fazla kullanıcı tipine hitap etmeye çalışmak.
- Yayın tarihini "bir özellik daha" diye sürekli ertelemek.
- Ölçümü yayından sonra kurmaya çalışmak.
- Kodu atılacakmış gibi yazmak, sonra üzerine inşa etmek zorunda kalmak.
- Alan adını, sunucuyu ya da mağaza hesabını geliştiricinin adına açmak.

## RadKod MVP'yi nasıl yapar?

Biz MVP'ye kapsamı birlikte daraltarak başlarız. İlk görüşmede varsayımı yazar, özellikleri üç kovaya ayırırız. Ardından tek sayfa teklif gelir: kapsam, fiyat, tarih ve kapsam dışı. Teklifin ardından bitiş tanımını birlikte yazar ve imzalarız. Kod deposu, sunucu, alan adı ve mağaza hesapları ilk günden sizin adınıza açılır. MVP tutarsa ürün sizindir ve üzerine inşa edilebilir.

Teslimden sonraki 30 gün içinde çıkan hataları ücretsiz düzeltiriz. Sizinle konuşan kişi kodu yazan kişidir. Kovalar tartışılırken teknik bedeli hemen söyleyebilmemizin sebebi budur. Web tabanlı ürünler için [özel yazılım](/hizmetler/ozel-yazilim), telefon için [mobil uygulama](/hizmetler/mobil-uygulama) sayfalarına bakabilirsiniz. Birden fazla firmadan teklif alıyorsanız [yazılım tekliflerini karşılaştırmak](/blog/yazilim-teklifi-karsilastirma) yazısı işinize yarar. İşin bittiğini nasıl tanımladığımızı ise [bitiş tanımı nedir](/blog/bitis-tanimi-nedir) yazısında anlattık.

## Sık sorulanlar

### MVP ile prototip arasındaki fark nedir?

Prototip fikri göstermek için yapılır ve çoğu zaman gerçek veriyle çalışmaz. MVP gerçek kullanıcıya açılır, gerçek veri üretir ve başarılı olursa üzerine inşa edilir.

### MVP için kaç özellik yeterlidir?

Sayı yoktur. Kullanıcının ana işi baştan sona yapabilmesi için gereken özellikler yeterlidir. Genellikle bu, düşünülen listenin küçük bir kısmıdır.

### MVP'yi kaç kullanıcıyla sınamalıyım?

Başarı eşiğinizi anlamlı biçimde ölçebileceğiniz kadar. Nitel geri bildirim için beş on kullanıcıyla yapılan görüşmeler bile çok şey gösterir. Sayısal ölçüm için daha fazla kullanıcı gerekir.

### MVP başarısız olursa para boşa mı gider?

Hayır. Büyük bir bütçe harcamadan fikrin tutmadığını öğrenmişsiniz demektir. Çoğu zaman sonuçlar, varsayımı değiştirip daha küçük bir kapsamla yeniden denemek için yeterli bilgi verir.

### MVP'nin kodu sonra atılır mı?

Atılmamalıdır. İyi kurgulanmış bir MVP'nin kodu, veri yapısı ve hesapları ürün tuttuğunda üzerine inşa edilecek biçimde kurulur. Hız için bilerek alınan kısayollar ise listelenir ve sonra kapatılır.

### MVP için yönetim paneli gerekli mi?

Her zaman değil. İlk aşamada bazı işler elle ya da basit bir ekranla yürütülebilir. Panel, elle yürütülen iş gerçekten yük olmaya başladığında sonra kovasından öne alınır.

### Mobil MVP mağazaya yüklenebilir mi?

Evet, ama mağaza kurallarına uyması ve gerçekten işlev sunması gerekir. Test için mağazaların sunduğu kapalı test kanalları da kullanılabilir.

### Fikrimi paylaşmadan teklif alabilir miyim?

Teklif için ne yapmak istediğinizi anlatmanız gerekir. Gizlilik önemliyse görüşmeden önce bir gizlilik sözleşmesi imzalanabilir. Ayrıntı için hukuk danışmanınıza sorun.

## Kaynaklar

- [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/), Apple Developer
- [Developer Policy Center](https://play.google.com/about/developer-content-policy/), Google Play

**MVP kapsamını birlikte daraltalım** [Teklif al](https://radkod.com/teklif-al)