Uygulama fikriniz için MVP kapsamı nasıl belirlenir

Codixus Ekibi1 Temmuz 2026

Aklınızda bir uygulama fikri var ve bitmiş halini şimdiden gözünüzün önüne getirebiliyorsunuz: özenle hazırlanmış karşılama akışı, ayarlar ekranı, davet sistemi, karanlık mod düğmesi. Sorun tam da bu hayal. Hayal ettiğiniz her şeyi yapmaya karar verdiğiniz anda, altı haftada cevaplayabileceğiniz bir soruyu cevaplamak için altı aylık bir işe girmiş olursunuz. MVP (ilk çalışan sürüm) kapsamını belirlemek, fikrinizi, yapmaya değip değmediğini size yine de gösterebilecek en küçük sürüme indirme disiplinidir.

Bu yazı, fikirden yayına hazır bir MVP'ye ulaşmak isteyen kurucular için bir yol haritası. Şu başlıkları ele alıyoruz: fikri kanıtlayan tek çekirdek döngü, önce tek platformla başlama kararı, "olmazsa olmaz" ile "sonra" ayrımı, kapsamın süreye ve maliyete etkisi ve gerçekten bir şey öğrenebilmeniz için uygulamaya ölçümü nasıl kuracağınız. Bunlar, daha kimse kod yazmaya başlamadan vermeniz gereken kararlar.

MVP gerçekte nedir, ne değildir

Eric Ries, minimum uygulanabilir ürünü şöyle tanımlıyor: "Bir ekibin en az çabayla, müşteriler hakkında en fazla doğrulanmış öğrenmeyi toplamasını sağlayan yeni ürün sürümü." "En az çaba" ifadesini aklınızdan çıkarmayın, çünkü çoğu kurucu tanımın tam da bu kısmını sessizce siler.

MVP bir prototip değildir. Prototip, bir etkileşimi yoklamak ya da bir ekranın işe yaradığından emin olmak için yaptığınız geçici bir çalışmadır. Figma'da bir tasarım da olabilir, bir hafta sonunda apar topar yazılmış bir kod da; ertesi gün çöpe atmanızda hiçbir sakınca yoktur. Prototiplerin süreçte nereye oturduğunu ve hızın neden çoğu zaman cilalı bir sonuçtan daha değerli olduğunu prototip ekonomisi yazımızda ayrıntılı anlattık. MVP ise her şeyi değiştiren tek bir noktada farklıdır: gerçek insanlar onu kendi telefonlarında, gerçek bir iş için kullanır. Yani App Store'da ya da TestFlight'ta yayına çıkar, ödeme fikrin bir parçasıysa gerçek hesapları ve ödemeleri yönetir, biri yanlış düğmeye bastığında çökmez. Minimum, özensiz demek değildir.

MVP aynı zamanda çöpe atılacak bir şey de değildir. "Minimum"u "sonra baştan yazacağımız sürüm" diye okuyan ekipler burada tökezler. Fikriniz işe yararsa MVP, gerçek ürünün tohumudur; büyürken veri modelinin ve sunucu tarafının (backend) büyük kısmını korursunuz. Onu kalıcı olacak bir kod gibi yazın, yalnızca çevresine çok daha az özellik koyun. Kırptığınız şey kapsamdır, kalite değil.

Fikri kanıtlayan tek çekirdek döngüyü bulun

İşe yarayan her uygulamanın, değeri kullanıcıya ulaştıran tek bir döngüsü vardır. Bir fotoğraf uygulamasında bu döngü şöyledir: bir fotoğraf görmek, ona tepki vermek, kendi fotoğrafını paylaşmak, karşılığında tepki almak. Bir alışkanlık uygulamasında: hatırlatma almak, görevi tamamlandı diye işaretlemek, serinin uzadığını görmek. MVP'niz yalnızca bu tek döngüyü gerçek kullanıcılarla kanıtlamak için vardır, başka bir şey için değil. Tek satır kod yazmadan önce döngüyü düz bir cümleyle yazın: kullanıcı X'i yapar, uygulama Y ile karşılık verir, kullanıcı X'i yapmak için tekrar gelir.

Steve Blank, kırpılmış sürüme "minimum özellik seti" diyor ve onu şöyle tanımlıyor: "boşa giden mühendislik saatlerini azaltmak" ve "ürünü erken dönemdeki vizyoner müşterilerin eline en kısa sürede ulaştırmak" için bir taktik. MVP'nize girecek özellikler, çekirdek döngünün onlarsız fiilen çalışamayacağı özelliklerdir. Bir özelliği çıkardığınızda döngü hâlâ çalışıyorsa, o özellik sonraya bırakılmaya adaydır. Listenizdeki her fikri bu testten geçirin; çoğu sayfanın en altına iner.

Önce tek bir platformla başlayın

İki platformda değil, tek platformda yayına çıkın. Tek kod tabanından hem iOS hem Android uygulaması çıkaran Expo ve React Native gibi çapraz platform bir yapı kullansanız bile, önce tek bir mağazayı seçmek yine de işinize yarar. İki mağaza demek iki inceleme süreci, cihazlara özgü iki ayrı sorun listesi, iki beta kanalı ve hataların çıkabileceği iki kat geniş bir alan demek; üstelik siz daha tek bir şeyi öğrenmeye çalışırken. Bunların hepsi gerçek bir iş yükü, ama hiçbiri insanların ürünü isteyip istemediğini size göstermez.

İlk kullanıcılarınızın elinde gerçekten hangi telefon varsa o platformu seçin. ABD'deki kurucu ve tasarımcılara satış yapıyorsanız bu neredeyse her zaman iOS'tur. İlk pazarınız Hindistan ya da Brezilya ise Android'dir. Döngüyü o tek platformda iyi kurun, insanların önüne çıkarın ve büyütmeye değer bir sinyal aldıktan sonra ikinci platformu ekleyin. Ortak bir React Native kod tabanı ikinci platformdaki çıkışı ucuzlatır; React Native'le geliştirmemizin büyük bir nedeni de bu. Bu konuya nasıl yaklaştığımızı React Native uygulama geliştirme hizmetimizde görebilirsiniz.

Olmazsa olmaz ile sonraya kalanı ayırın

Bir kâğıt alın ve iki sütun çizin: Olmazsa olmaz ve Sonra. Olmazsa olmaz sütununa yalnızca çekirdek döngünün gerçek bir kullanıcıda baştan sona çalışabilmesi için gereken özellikleri yazın. Sonra sütununa geri kalan her şey girer ve bu liste uzun olacaktır. Davet programları, oyunlaştırma, birden fazla giriş yöntemi, ayrıntılı ayarlar, karanlık mod, uygulama içi mesajlaşma, yönetim paneli: hepsi Sonra sütununa. Şunu da unutmayın: en küçük sürümde bile vazgeçilemeyecek birkaç şey var. Örneğin kullanıcıların hesap açmasına izin veriyorsanız hesap silme özelliği şarttır, çünkü mağazalar bunu zorunlu tutuyor.

Zor olan, bu ayrıma sadık kalmaktır; bunda da iradeden çok bir zaman bütçesi işe yarar. Basecamp'in Shape Up yaklaşımı tahmin mantığını tersine çevirir: "Tahmin bir tasarımla başlar, bir sayıyla biter. İştah (appetite) ise bir sayıyla başlar, bir tasarımla biter." Önce iştahınızı, yani bu işe en fazla ne kadar süre ayırmaya razı olduğunuzu belirleyin; örneğin altı hafta. Sonra bu sabit sayı sizi kapsamı kırpmaya zorlasın. Bir özellik sığmıyorsa tarihi öteletmez, Sonra listesine düşer. Bu tek kural, üç haftalık bir ürünün makul görünen eklemelerle adım adım üç aylık bir ürüne dönüşmesini engeller.

Bu ayrıma ikinci bir gözün de bakmasını isterseniz, bizimle çalışmanın ilk saati zaten bununla geçer. 30 dakikalık görüşme planlayın; daha hiçbir şey geliştirilmeden olmazsa olmaz listenizi döngüyle tek tek karşılaştırıp birlikte, açık açık sınayalım.

Kapsamı bir süreye ve maliyete bağlayın

Olmazsa olmaz listesi gerçekçi olduğunda kapsam soyut olmaktan çıkar, bir takvime ve bir rakama dönüşür. Kod yazılmaya başlanmadan sabit kapsam ve sabit takvimde ısrar etmemizin nedeni de bu: MVP'leri sessizce dokuz aylık projelere dönüştüren şey, ucu açık kapsamdır. Kapsamı sıkı tutulmuş bir Starter projesi yaklaşık dört ila altı haftada yayına çıkar; kendi telefonunuzda TestFlight üzerinden çalışan gerçek bir sürüm ise ikinci haftanın sonunda elinizde olur. Böylece uygulama bitmeden çok önce gerçek uygulamayı görüp ona göre yön verirsiniz.

Olmazsa olmaz listesinin uzunluğu hem sürenin hem fiyatın en büyük belirleyicisidir. Abonelik ve anlık bildirim içeren tek, temiz bir döngü başka bir iştir; beş döngü, bir yönetim paneli ve akışın içinde yapay zeka bambaşka bir iş. Ayrıntılı dökümü mobil uygulama yapmak ne kadar tutar yazımızda paylaştık. Kısa özeti: faturayı saatlik ücret değil, kapsam belirler. Olmazsa olmaz sütunundan Sonra sütununa taşıdığınız her özellik size hem zaman hem bütçe kazandırır; ayrımın bu kadar önemli olmasının pratik nedeni de bu.

Gerçekten öğrenmek için ölçüm ekleyin

Ölçemediğiniz bir MVP deney değil, yalnızca küçük bir üründür. Yayından önce döngünün çalıştığını söyleyen tek bir sayıyı belirleyin; bu sayı neredeyse hiçbir zaman toplam indirme sayısı olmaz. Bir alışkanlık uygulamasında bu, döngüyü üst üste üç gün tamamlayan yeni kullanıcıların oranı olabilir. Bir pazar yeri uygulamasında, ilk yanıtını alan ilanların oranı olabilir. Sayıyı seçin, arkasındaki olayları ölçüme alın; fikrin tutup tutmayacağını birkaç hafta içinde anlarsınız.

Sürümü erkenden gerçek insanların eline verin. TestFlight ile e-posta ya da herkese açık bir bağlantı üzerinden 10.000'e kadar harici test kullanıcısı davet edebilir, geri bildirimleri ve ekran görüntülerini doğrudan uygulamadan toplayabilirsiniz. Kauffman Vakfı'nın girişimcilik içeriğinde dendiği gibi, MVP ile "bir ürün geliştirmiyorsunuz, aslında müşterilerden tepki almaya çalışıyorsunuz." Test kullanıcılarının yalnızca ne söylediğine değil, ne yaptığına bakın. Sonra kararı tek çekirdek döngünüzün sayılarına bırakın: fikre daha çok mu yüklenmelisiniz, döngüyü mü değiştirmelisiniz, yoksa altı haftadan fazlasını kaybetmeden bu işten çekilmeli misiniz?

Sık sorulan sorular

Bir MVP'yi geliştirmek ne kadar sürmeli?

Çoğu mobil fikir için odaklı bir MVP ay değil, hafta işidir. Kapsamı gerçekten tek platformda tek çekirdek döngüye indirdiyseniz, Starter paketiyle yapılan bir uygulama yaklaşık dört ila altı haftada yayına çıkar; ikinci haftanın sonunda da gerçek cihazda çalışan bir TestFlight sürümü elinizde olur. Biri ilk sürüm için size aylar süren bir takvim çıkarıyorsa, kapsam neredeyse kesinlikle fazla büyüktür.

MVP ile prototip aynı şey mi?

Hayır. Prototip, bir etkileşimi ya da görünümü denemek için yaptığınız geçici bir çalışmadır ve gerçek kullanıcıların elinde ayakta kalmak zorunda değildir. MVP ise gerçek insanlara, kendi telefonlarında gerçek bir iş için ulaşır; küçük olsa da kararlı çalışması ve kalıcı olacak kadar sağlam olması gerekir. Fikir işe yararsa MVP'yi korur ve büyütürsünüz, prototipi ise atarsınız.

Önce iOS'ta mı Android'de mi yayına çıkmalıyım?

İlk kullanıcılarınızın gerçekten kullandığı platformla başlayın. Girişimlere ve profesyonellere satış yapan çoğu Batılı kurucu için bu iOS'tur. İlk pazarınız Android'in baskın olduğu bir bölgeyse, onun yerine Android'le başlayın. Ortak bir React Native kod tabanı ikinci platformu sonradan eklemeyi ucuzlatır; bu yüzden fikri doğrulama aşamasındayken iki platformun yükünü birden taşımanıza gerek yok.

Bir MVP'de kaç özellik olmalı?

Çekirdek döngünün baştan sona çalışmasına yetecek kadar az, artı uygulama mağazalarının zorunlu tuttukları. Döngüyü tek cümleyle yazın, sonra yalnızca döngünün onlarsız çalışamayacağı özellikleri bırakın. Geri kalan her şey Sonra listesine gider. Bir özelliği çıkarmak döngüyü bozmuyorsa, ilk sürümde yeri yoktur.

MVP'min işe yarayıp yaramadığını nasıl anlarım?

Yayına çıkmadan önce tek bir başarı ölçütü belirleyin ve bunu indirme sayısına değil davranışa bağlayın. Çekirdek döngünüzün arkasındaki olayları ölçün, sürümü TestFlight üzerinden gerçek test kullanıcılarına verin ve insanların geri gelip döngüyü kendi başlarına tamamlayıp tamamlamadığını izleyin. Bu sinyali birkaç hafta izlemek, devam mı etmeniz, döngüyü mü değiştirmeniz yoksa durmanız mı gerektiğini gösterir.

Kaynaklar

Kapsam belirlemek, yapmaya başlamadan önce vereceğiniz en değerli karardır. Ne kadar hızlı öğreneceğinizi ve öğrenmek için ne kadar harcayacağınızı o belirler. Döngüyü doğru belirleyin, kapsamı acımadan ona göre kırpın, tek platformda yayına çıkın ve sırada ne yapacağınızı gerçek kullanım göstersin. Bunu sizin için yapmamızı ister misiniz? 30 dakikalık görüşme planlayın.