MVP Nedir? Mobil Uygulamada Minimum Uygulanabilir Ürün

MVP nedir? MVP (minimum viable product — minimum uygulanabilir ürün), bir fikri gerçek kullanıcılarla test etmeye yetecek en küçük çalışır ürün sürümüdür. Mobil tarafta tipik bir MVP 6-12 haftada yayına çıkar ve Türkiye'de 100.000 TL'den başlayan bütçelerle geliştirilir; başarı ölçütü özellik sayısı değil, tek bir sorunu çözüp talebi doğrulamasıdır.

Kısaltma sporda "en değerli oyuncu", tıpta mitral kapak prolapsusu anlamına gelir. Yazılımda ise MVP bambaşka bir şeyi anlatır: fikrinizi kanıtlamak için harcamanız gereken en az para ve zaman.

Ekiplerin çoğu bu tanımdaki "minimum" kelimesine odaklanır ve yarım bir ürün çıkarır. Oysa asıl zor kısım "viable" yani yaşayabilir olmasıdır: kullanıcı ilk açılışta bir işini bitirebilmeli, siz de bu davranıştan ders çıkarabilmelisiniz. Bu rehberde kapsamı nasıl daraltacağınızı, hangi özelliği neden erteleyeceğinizi, 10 haftalık gerçekçi bir yol haritasını ve MVP sonrası kararları rakamlarla anlatıyoruz.

İçindekiler

• MVP Nedir? Tanımın Üç Bileşeni
• MVP, Prototip ve PoC Arasındaki Fark
• Neden MVP? Rakamların Söylediği
• MVP'de Ne Olmalı, Ne Olmamalı
• Kapsamı Kısmanın 5 Tekniği
• MoSCoW ile Önceliklendirme: Somut Bir Örnek
• 10 Haftalık Örnek MVP Yol Haritası
• MVP Maliyeti ve Bütçe Planı
• MVP'yi Yayına Almak: Test ve Mağaza Gerçekleri
• MVP Sonrası: Ne Ölçmeli, Ne Zaman Büyümeli
• Türkiye'de MVP: Finansman ve Ekip Seçenekleri
• En Sık Yapılan 7 MVP Hatası
• Sıkça Sorulan Sorular

MVP Nedir? Tanımın Üç Bileşeni

Terimi 2001'de Frank Robinson ortaya attı, 2011'de Eric Ries'in The Lean Startup kitabıyla yaygınlaştı. Tanımı üç parçaya bölmek, ekiplerin en çok tıkandığı noktayı açığa çıkarır.

Minimum: Ürünün yalnızca temel değer önerisini taşıyan sürümü. Ek ayarlar, ikinci kullanıcı rolü, üç farklı ödeme yöntemi ve yönetim panelindeki grafikler bu aşamada yoktur.

Viable (yaşayabilir): Kullanıcı, uygulamayı indirdikten sonra baştan sona bir işi bitirebilir. Yarım kalan akış MVP değil, demodur. Kayıt olup ürün aratabilen ama sipariş veremeyen bir uygulama hiçbir soruyu yanıtlamaz.

Product (ürün): Gerçek kullanıcıların erişimine açık, ölçülebilir ve destek verilebilir bir yazılım. Slayt, tasarım dosyası ya da tıklanabilir ekran akışı ürün sayılmaz.

Kısacası MVP, "az özellikli kötü ürün" değil, "tek işi iyi yapan küçük ürün"dür. Bu ayrım bütün kapsam tartışmalarının kilit noktasıdır.

MVP, Prototip ve PoC Arasındaki Fark

Üç kavram sık sık birbirinin yerine kullanılır; oysa üçü farklı soruları yanıtlar ve farklı bütçeler ister.

Sıralama her projede zorunlu değildir. Yapay zekâ, cihaz entegrasyonu veya karmaşık veri işleme içeren fikirlerde PoC mantıklıdır; standart bir pazar yeri uygulamasında doğrudan prototipten MVP'ye geçmek daha hızlı sonuç verir.

Neden MVP? Rakamların Söylediği

MVP disiplini bir moda değil, sert verilerin dayattığı bir savunma hattıdır.

Girişimler ürünü değil, pazarı ıskaladığı için kapanıyor. CB Insights'ın 2023 sonrasında kapanan 431 yatırım almış şirket üzerine yaptığı analize göre kapanma nedenlerinin başında %70 ile sermayenin tükenmesi geliyor; hemen ardından %43 ile ürün-pazar uyumu eksikliği, %29 ile yanlış zamanlama ve %19 ile sürdürülemez birim ekonomisi sıralanıyor. Sermayenin bitmesi genellikle sonuçtur; kök neden, kimsenin istemediği bir ürüne uzun süre para harcamaktır.

Yazdığınız özelliklerin çoğu kullanılmıyor. Pendo'nun 615 müşterisinin anonim kullanım verisini incelediği Feature Adoption Report çalışması, ürünlerdeki özelliklerin %80'inin nadiren ya da hiç kullanılmadığını, günlük kullanımın %80'ini ise özelliklerin yalnızca %12'sinin ürettiğini gösterdi. Her beş özellikten dördü, teoride bütçenizin dörtte üçünü boşa harcıyor.

Kapsam kaymasının bedeli ölçüldü. Project Management Institute'ün Pulse of the Profession araştırmasına göre projelerin %52'si kapsam kayması yaşıyor; bu projelerde ortalama bütçe aşımı %27 seviyesinde. MVP, kapsamı sözleşmeye ve takvime bağlayarak bu riski baştan sınırlar.

Üç veri aynı sonuca çıkar: erken doğrulama, tasarrufun kendisidir.

MVP'de Ne Olmalı, Ne Olmamalı

Kapsam tartışmalarında "bu da olsun" demek kolaydır. Aşağıdaki tablo, mobil uygulamalarda ilk sürüm için pratik bir sınır çizer.

Buradaki mantık şu: sağ sütundaki her kalem, sol sütundaki soruyu yanıtlamadan önce yapıldığında bilgi değil, maliyet üretir. Analitik ise istisnadır — ölçüm olmadan MVP, pahalı bir tahmin makinesine dönüşür.

Kapsamı Kısmanın 5 Tekniği

Kapsamı daraltmak "özellik silmek" değildir; aynı değeri daha ucuz yollarla sunmaktır.

1. Tek mutlu yolu kodlayın. Kullanıcının uygulamada yapabileceği tek bir ana işi seçin ve yalnızca o yolun kusursuz çalışmasını sağlayın. İstisna senaryolarını (iptal, iade, hata düzeltme) ilk sürümde destek ekibi manuel yönetsin.

2. Perde arkasını insanla çalıştırın. "Wizard of Oz" yaklaşımında kullanıcı otomatik bir sistem görür, arkada işi bir kişi yapar. Eşleştirme algoritması yazmadan önce eşleştirmeyi elle yapın; talebi doğruladığınızda otomasyonu hangi kurallarla yazacağınızı da öğrenmiş olursunuz.

3. Hazır servis satın alın. Kimlik doğrulama, ödeme, harita, SMS, push bildirimi ve dosya depolama için hazır servisler aylık küçük ücretlerle çalışır. Bu bileşenleri sıfırdan yazmak MVP bütçesinin en kolay yanan kalemidir.

4. Yönetim panelini erteleyin. İlk haftalarda sipariş sayınız üç haneli değilse, tam donanımlı bir panel yerine basit bir liste ekranı ya da mevcut bir tablo aracı yeterlidir. Panel, kullanım hacmi arttığında gerçek ihtiyaca göre şekillenir.

5. Tek platformdan başlayın. Hedef kitleniz Türkiye'de yoğun olarak Android kullanıyorsa iOS sürümünü erteleyin; iki platformu birlikte hedefliyorsanız tek kod tabanı tercih edin. Platform kararının maliyet etkisini React Native, Flutter ve native karşılaştırmamızda ayrıntılı ele aldık.

MoSCoW ile Önceliklendirme: Somut Bir Örnek

MoSCoW yöntemi özellikleri dört kovaya ayırır: Must have (olmazsa olmaz), Should have (önemli ama ertelenebilir), Could have (fırsat bulunursa), Won't have (bu sürümde kesinlikle yok). Yöntemin gücü, dördüncü kovayı yazılı hale getirmesindedir; "yapmayacağız" listesi olmayan projede kapsam kayması kaçınılmazdır.

Aşağıda İstanbul'da hizmet veren bir mobil oto yıkama girişimi için hazırlanmış örnek bir öncelik listesi var.

Listeyi hazırlarken tek kural işe yarar: Must kovası, ekibin 6-8 haftada bitirebileceğinden fazlasını içeremez. Fazlaysa listeyi değil, hedefi küçültün.

10 Haftalık Örnek MVP Yol Haritası

Aşağıdaki takvim, orta karmaşıklıkta bir mobil MVP için tipik akışı gösterir. Süreler ekip büyüklüğüne ve karar hızınıza göre değişir; en sık gecikme nedeni geliştirme değil, geç verilen kararlardır.

Dikkat edilecek nokta: 9. haftadaki kapalı test isteğe bağlı bir lüks değildir. Google Play tarafında yeni açılan kişisel geliştirici hesapları için zorunludur ve takvimi doğrudan etkiler.

MVP Maliyeti ve Bütçe Planı

MVP bütçesini belirleyen üç değişken vardır: ekran sayısı, entegrasyon sayısı ve platform sayısı. Aşağıdaki aralıklar Master Web'in mobil uygulama projelerinde uyguladığı başlangıç fiyatlarını yansıtır.

Piyasa rehberlerinde 2026 için verilen MVP aralıkları da benzer bir tabloya işaret ediyor; farkı yaratan kalem genelde entegrasyon sayısı ve tasarım derinliğidir. Kendi fikriniz için hızlı bir tahmin almak isterseniz mobil uygulama maliyet hesaplayıcımızı kullanabilir, kalemlerin ayrıntılı dökümü için mobil uygulama fiyatları rehberimize göz atabilirsiniz.

Bütçe planlarken üç kalemi baştan ayırın: geliştirme dışında mağaza hesapları (Apple 99 $/yıl, Google 25 $ tek seferlik), sunucu ve servis abonelikleri, bir de lansman sonrası ilk üç aylık iyileştirme payı. Bu payı ayırmayan ekipler, ilk kullanıcı geri bildirimi geldiğinde bütçesiz kalır.

MVP'yi Yayına Almak: Test ve Mağaza Gerçekleri

MVP'nin takvimi mağaza kurallarına çarptığında sürprizler başlar. İki platformun oyun kuralları farklıdır.

Apple tarafı görece hızlıdır. TestFlight ile en fazla 100 dahili ve 10.000 harici test kullanıcısına dağıtım yapabilirsiniz; harici teste açılan ilk sürüm Apple'ın beta incelemesinden geçer (TestFlight belgeleri). Apple'ın açıkladığı verilere göre gönderimlerin %90'ı 24 saatten kısa sürede inceleniyor.

Google tarafı MVP takvimini uzatan asıl kalemdir. 13 Kasım 2023'ten sonra açılan kişisel geliştirici hesapları için Google Play, üretime geçmeden önce en az 12 test kullanıcısıyla 14 gün kesintisiz kapalı test yapılmasını şart koşuyor. Testçi sayısı düşerse ya da biri çıkarsa sayaç sıfırlanır. Bu nedenle test kullanıcılarınızı geliştirme bitmeden önce belirleyin.

Mağaza gönderimi, belge ve beyan tarafında ayrı bir kontrol listesi ister. Süreci baştan sona mobil uygulama nasıl yayınlanır rehberimizde anlattık; gönderim öncesi eksik kalan maddeleri uygulama yayın kontrol listemizle hızlıca tarayabilirsiniz.

MVP Sonrası: Ne Ölçmeli, Ne Zaman Büyümeli

Yayına almak MVP'nin sonu değil, ölçüm evresinin başlangıcıdır. İlk 4-8 haftada dört veriye bakın: kayıt tamamlama oranı, temel akışı bitiren kullanıcı yüzdesi, 7. ve 30. gün geri dönüş oranları, bir de ilk ödeme oranı. Sektör kıyaslamalarında ortalama 30. gün elde tutma oranının tek haneli yüzdelerde kaldığını hatırlarsanız, hedefinizi gerçekçi kurarsınız.

Niteliksel tarafta Sean Ellis'in 2009'da tanımladığı klasik anket sorusu hâlâ en pratik ölçüttür: "Bu ürünü artık kullanamasaydınız ne hissederdiniz?" Aktif kullanıcıların %40'ından fazlası "çok hayal kırıklığına uğrardım" diyorsa ürün-pazar uyumu sinyali güçlüdür.

Kritik nokta şu: bu kararı verecek verinin toplanması için analitik kurulumunun MVP kapsamında olması gerekir. Ölçümü sonraya bırakan ekipler, altı ay sonra da aynı tahminlerle tartışır.

Türkiye'de MVP: Finansman ve Ekip Seçenekleri

Türkiye ekosistemi MVP aşamasındaki girişimler için görece erişilebilir. KPMG'nin Türkiye Startup Yatırımları 2025 raporuna göre 2025'te 360 işlemde toplam 1,4 milyar dolar yatırım gerçekleşti; işlemlerin 269'u yani yaklaşık %75'i tohum aşamasındaydı. İşlem sayısı bazında en çok yatırım çeken dikey yapay zekâ oldu. Yani sermaye, hâlâ erken aşamayı besliyor — ancak yatırımcı masasına çalışan bir ürünle ve gerçek kullanım verisiyle oturmak, sunumla oturmaktan farklı sonuç veriyor.

Hibe tarafında TÜBİTAK'ın 1512 BiGG programı ve KOSGEB girişimcilik destekleri teknoloji odaklı fikirler için başvurulabilir kanallardır; güncel çağrı takvimini ve tutarları başvurudan önce kurumların resmî sayfalarından doğrulayın.

Ekip tarafında üç yol var: kendi ekibinizi kurmak, freelance çalışmak ya da bir ajansla ilerlemek. MVP aşamasında ilk seçenek genellikle en pahalısıdır; işe alım süreci tek başına 8-12 hafta alabilir. Yapay zekâ araçlarıyla ilk sürümü kendiniz üretme fikri cazip görünse de, Stack Overflow'un 2025 geliştirici anketi geliştiricilerin %84'ünün yapay zekâ araçlarını kullandığını ya da kullanmayı planladığını, buna karşın %46'sının çıktının doğruluğuna güvenmediğini ve %66'sının "neredeyse doğru ama tam değil" sonuçlardan şikâyetçi olduğunu gösteriyor. Bu araçlar prototip hızını artırır; mağaza gönderimi, güvenlik ve ödeme akışı ise gözden geçirme ister. Karşılaştırmanın ayrıntısını yapay zekâ araçları mı ajans mı yazımızda bulabilirsiniz.

En Sık Yapılan 7 MVP Hatası

1. "Minimum" kelimesini yarım ürün sanmak. Çekirdek akış aksıyorsa toplanan geri bildirim ürün hakkında değil, hatalar hakkında olur.

2. Yapmayacaklar listesini yazmamak. Won't kovası yazılı değilse, her toplantıda kapsam bir özellik büyür.

3. Analitiği sonraya bırakmak. Ölçüm yoksa MVP, pahalı bir görüş anketine dönüşür.

4. Tasarımı tamamen atlamak. 2026'da kullanıcı, temel kullanılabilirlik ve erişilebilirlik beklentisiyle uygulamayı açar. Sade tasarım gerekir; özensiz tasarım geri bildirimi zehirler.

5. İki platformu aynı anda zorlamak. Bütçenin yarısı ikinci platforma giderken doğrulama hızı yarıya iner.

6. Mağaza takvimini hesaba katmamak. Kapalı test ve inceleme süreleri, lansmanı iki-üç hafta öteler.

7. Lansman sonrası için bütçe ayırmamak. İlk geri bildirim dalgası, en değerli geliştirme fırsatıdır; kasada para kalmamışsa fırsat kaçar.

Sıkça Sorulan Sorular

MVP ne kadar sürede hazır olur?

Orta karmaşıklıkta bir mobil MVP tipik olarak 6-12 haftada yayına çıkar. Tek platform, tek kullanıcı rolü ve tek entegrasyonla sınırlı bir kapsam 6-8 haftaya inebilir; ödeme, panel ve çoklu rol içeren projeler 12 haftayı aşar.

MVP maliyeti ne kadardır?

Master Web'de mobil MVP projeleri 100.000 TL'den, iOS + Android kapsayan standart paketler 200.000 TL'den başlar. Net rakamı ekran sayısı, entegrasyon sayısı ve platform tercihi belirler; ücretsiz analiz sonrası sabit fiyatlı teklif sunuyoruz.

MVP ile prototip aynı şey mi?

Hayır. Prototip tıklanabilir bir tasarım dosyasıdır ve deneyimi iç ekiple test eder; MVP mağazada yayında olan, gerçek kullanıcıların gerçek para ve zaman harcadığı çalışan bir üründür. Prototip "akış anlaşılır mı", MVP "bunu isteyen var mı" sorusunu yanıtlar.

MVP'de kaç özellik olmalı?

Sayı değil, akış belirleyicidir. Kullanıcının uçtan uca bir işi bitirmesi için gereken minimum ekran seti yeterlidir; pratikte bu çoğu projede 6-12 ekrana ve tek bir ana senaryoya karşılık gelir.

Yapay zekâ araçlarıyla MVP yapılabilir mi?

Basit fikirlerin ilk sürümü için hızlandırıcı olarak işe yarar. Ancak ödeme akışı, veri güvenliği, mağaza uyumluluğu ve performans tarafında deneyimli bir gözden geçirme gerekir; aksi halde lansman mağaza reddiyle ya da güvenlik açığıyla sonuçlanabilir.

MVP başarısız olursa ne yapmalı?

Önce hangi varsayımın çürüdüğünü ayırt edin: kitle mi, sorun mu, fiyat mı? Kayıt olup kullanmayan bir kitle değer önerisi sorununu, kullanıp ödemeyen bir kitle fiyatlandırma sorununu işaret eder. MVP'nin amacı zaten bu ayrımı ucuza öğrenmektir.

MVP sonrası ikinci sürüm ne zaman planlanır?

İlk 4-8 haftalık kullanım verisi toplandıktan sonra. Temel akışın tamamlanma oranı ve 30. gün geri dönüş rakamları stabilse Should kovasındaki özellikleri açmanın zamanı gelmiştir; veriler zayıfsa yeni özellik değil, mevcut akışın iyileştirilmesi önceliklidir.

MVP, bütçeyi kısmak için bulunmuş bir kısayol değil; belirsizliği para harcamadan önce azaltan bir yöntemdir. Tek bir kullanıcı sorununu seçip onu uçtan uca çözerseniz, ilk sürümünüz size hangi özelliğin gerçekten gerektiğini kullanıcıların davranışıyla söyler. Bu bilgi, altı ay boyunca kapalı kapılar ardında geliştirilen "tam sürüm"den çok daha değerlidir.

Fikrinizi ilk sürüme çevirmeyi planlıyorsanız kapsam listesini bizimle birlikte oluşturabilirsiniz: mobil uygulama geliştirme hizmetimizi inceleyin, sürecin tamamını görmek için mobil uygulama nasıl yapılır rehberimizi okuyun ya da doğrudan bize ulaşın — ilk görüşmede kapsamınızı Must, Should ve Won't kovalarına birlikte ayıralım.