Bir MVP ajansı seçerken en belirleyici kriter teknoloji listesi ya da portföyün parlaklığı değil, ajansın ilk görüşmede size "bu MVP hangi soruyu cevaplayacak?" diye sorup sormadığıdır. Güvenilir bir MVP ajansı test edilecek hipotezi, kapsam dışında kalacakları, kodun kime ait olacağını, doğrulamanın nasıl ölçüleceğini ve MVP sonrasında ne olacağını sözleşmeden önce net biçimde cevaplar. Aşağıdaki dokuz soru ve kırmızı bayrak tablosu, bu cevapları karşılaştırmanız için hazırlandı.
Bu yazı yalnızca ajans seçimine odaklanıyor. MVP kavramının kendisini, türlerini ve tarihçesini merak ediyorsanız MVP geliştirme rehberimize göz atabilirsiniz.
MVP ajansına sormanız gereken 9 soru nedir?
Bu soruların amacı ajansı sınava sokmak değil, çalışma biçimini görünür kılmaktır. Cevabın içeriği kadar nasıl verildiği de önemlidir: somut örnekle, yazılı bir belgeyle ya da "bizde şöyle işliyor" diye açıklanabilen bir süreçle gelen cevap, genel geçer vaatlerden çok daha fazla şey söyler.
1. Test edeceğimiz hipotezi nasıl tanımlıyorsunuz?
MVP'nin bir özellik listesiyle değil, doğrulanacak bir varsayımla başlaması gerekir. İyi bir ajans "hangi varsayım yanlış çıkarsa geri kalan her şey anlamsızlaşır?" sorusunu sizinle birlikte yazıya döker. Ajans doğrudan ekran tasarımına ya da özellik tahminine geçiyorsa, ortaya çıkacak şey büyük ihtimalle bir MVP değil, yarım kalmış bir üründür.
2. Kapsam dışında ne kalacak ve bunu kim savunacak?
Her MVP'de iki liste vardır: yapılacaklar ve yapılmayacaklar. Asıl zor olan ikinci listeyi korumaktır. Ajansa geçmiş bir projede neyi bilerek dışarıda bıraktığını ve bunu müşteriye nasıl anlattığını sorun. Her isteğe "olur, ekleriz" diyen bir ekip kısa vadede rahat görünür, ama takvim ve bütçe kontrolü bu noktada kaybedilir.
3. Kaynak kod, altyapı hesapları ve alan adı kime ait olacak?
Cevap tek kelime olmalı: size. Kaynak kodun sizin hesabınızdaki bir repoda tutulması, bulut ve mağaza hesaplarının şirketiniz adına açılması, fikri mülkiyet devrinin sözleşmede yazılı olması gerekir. Kodu ancak proje bitince "teslim edeceğini" söyleyen veya kendi hesaplarında barındırmakta ısrar eden bir ajans, ileride sizi ona bağımlı kılar.
4. Doğrulamayı nasıl ölçeceğiz?
Kod yazılmadan önce üç şeyin yazılı olması gerekir: test edilen varsayım, onu ölçecek metrik ve "evet" sayılacak eşik. Eşik önceden konmazsa her sonuç sonradan olumlu yorumlanabilir. Ajansa olay takibinin (event tracking) ilk sürümle birlikte kurulup kurulmayacağını da sorun; sonradan eklenen ölçüm ilk haftaların verisini geri getirmez.
5. Çalışan yazılımı ne sıklıkla göreceğim?
İlerlemenin kanıtı ekran görüntüsü ya da sunum değil, gerçek bir adreste çalışan yazılımdır. Kısa sprint döngüleri, her sprint sonunda demo ve sizin de erişebildiğiniz bir test ortamı (staging ya da pre-prod) beklemeniz makul. Aylarca "arka planda çalışıyoruz" denip sonunda tek seferde teslim edilen MVP'ler, yanlış yönde ilerlendiğini çok geç fark ettirir.
6. Kapsam değiştiğinde süreç nasıl işliyor?
MVP'de kapsamın değişmesi kaçınılmazdır, çünkü öğrendikçe öncelikler kayar. Önemli olan değişikliğin nasıl yönetildiğidir. İyi bir cevap şuna benzer: yeni istek bir sonraki sprintin önceliklendirmesine girer, eklenen iş karşılığında neyin çıkarılacağı birlikte kararlaştırılır ve bu karar yazılı kalır. "Her değişiklik ayrı teklif" ya da "sorun değil, sığdırırız" uçlarının ikisi de dikkat gerektirir.
7. Teknik borcu nasıl belgeliyorsunuz?
Hızlı ilerlemek için bilinçli kısayollar almak MVP'nin doğasında vardır. Sorun kısayol almak değil, onları kayıt dışı bırakmaktır. Ajansa proje sonunda büyümeden önce mutlaka düzeltilmesi gerekenlerle uzun süre olduğu gibi yaşayabilecekleri ayıran yazılı bir teknik borç değerlendirmesi verip vermediğini sorun. Bu belge, bir sonraki ekibin ya da yatırımcının teknik incelemesinin temelidir.
8. MVP ölçeklenebilir mi, yoksa yeniden mi yazılacak?
Dürüst cevap genellikle "duruma göre" ile başlar ve gerekçesi gelir. MVP'yi ilk günden milyonlarca kullanıcıya göre tasarlamak zaman kaybıdır; tamamen atılacak bir koda yatırım yapmak da. Makul yaklaşım, veri modeli, kimlik doğrulama ve ödeme gibi sonradan değiştirilmesi pahalı olan kararları sağlam vermek, geri kalanında sadelikten yana olmaktır. Ajanstan hangi parçaların kalıcı, hangilerinin geçici tasarlandığını açıklamasını isteyin.
9. MVP yayına çıktıktan sonra ne oluyor?
MVP'nin değeri yayından sonra toplanan veride ortaya çıkar. Yayın sonrası destek süresinin, hata düzeltmelerinin nasıl ele alınacağının, sonraki iterasyonun nasıl planlanacağının ve isterseniz işi başka bir ekibe devretmenin nasıl mümkün olacağının net olması gerekir. Yayın gününü projenin bitişi olarak gören bir ajans, aslında işin yarısını teklif ediyordur.
İyi cevap ile kırmızı bayrak nasıl ayırt edilir?
Aşağıdaki tablo, görüşmelerde not alırken kullanabileceğiniz bir karşılaştırma listesidir. Tek bir kırmızı bayrak her zaman eleme sebebi değildir, ama aynı ajansta birkaçı birden görülüyorsa durup düşünmek gerekir.
| Soru | İyi cevap | Kırmızı bayrak |
|---|---|---|
| Hipotez | Varsayım, metrik ve eşik yazılı olarak birlikte belirlenir | Doğrudan özellik listesi ve ekran tasarımıyla başlanır |
| Kapsam dışı | Yapılmayacaklar listesi yazılı, gerekçeleriyle tutulur | Her isteğe itirazsız "ekleriz" denir |
| Kod sahipliği | Repo ve hesaplar baştan müşteri adına, IP devri sözleşmede | Kod proje sonunda teslim edilir, hesaplar ajansta kalır |
| Doğrulama ölçümü | Olay takibi ilk sürümle kurulur | "Önce yayına çıkalım, ölçümü sonra düşünürüz" |
| Görünürlük | Kısa sprintler, erişilebilir test ortamı, düzenli demo | Aylar sonra tek seferlik teslim |
| Kapsam değişikliği | Yeni iş eklenirken neyin çıkacağı birlikte kararlaştırılır | Değişiklikler sessizce sığdırılır ya da her biri pazarlık konusu olur |
| Teknik borç | Proje sonunda yazılı teknik borç devri | "Bizim kodumuzda teknik borç olmaz" |
| Ölçeklenme | Kalıcı ve geçici parçalar gerekçesiyle ayrılır | "Sonsuz ölçeklenir" ya da "zaten atılacak" kesinliği |
| MVP sonrası | Destek, iterasyon ve devir seçenekleri net | Yayın günü projenin bittiği gün sayılır |
Güvenilir bir MVP ajansını nasıl tanırsınız?
Sorulara verilen cevaplar dışında, ajansın güvenilirliğini dışarıdan doğrulayabileceğiniz birkaç işaret vardır:
- Doğrulanabilir işler: Adı verilen, yayında olan ve inceleyebileceğiniz projeler. Mümkünse geçmiş bir müşteriyle kısa bir görüşme isteyin.
- Kendisini sınırlayabilmesi: MVP'nin yanlış cevap olduğu durumları söyleyebilen, bazı işleri reddettiğini açıkça belirten bir ekip.
- Yazılı süreç: Keşif çıktısı, sprint raporu, teknik borç belgesi gibi somut dokümanlar. Örnek bir şablon görmek isteyin.
- Mühendislik pratikleri: Kod incelemesi (code review), otomatik CI/CD hattı ve ayrı bir test ortamı. Bunlar olmadan sık ve güvenli sürüm çıkmak zordur.
- Tarih ve fiyat vaadinde temkin: Keşif yapılmadan kesin tarih ya da sabit fiyat vermek, ya kapsamın anlaşılmadığını ya da riskin sonradan size yansıtılacağını gösterebilir.
MVP için ajans mı, freelancer mı, şirket içi ekip mi?
Üç seçeneğin de doğru olduğu durumlar vardır. Karar, elinizdeki teknik yetkinliğe, ürünün kaç disiplin gerektirdiğine ve MVP'den sonra ne kadar hızlı büyümeyi planladığınıza bağlıdır.
| Kriter | Ajans | Freelancer | Şirket içi ekip |
|---|---|---|---|
| Başlama hızı | Genellikle hızlı, ekip hazır | Hızlı, tek kişiye bağlı | Yavaş, işe alım süreci gerekir |
| Yetkinlik yelpazesi | Ürün, tasarım, backend, mobil ve DevOps bir arada | Genellikle tek ya da iki alan | İşe aldığınız kişilerle sınırlı |
| Süreklilik riski | Düşük, ekip içinde yedeklilik var | Yüksek, kişi ayrılırsa bilgi gider | Orta, kilit kişiye bağımlılık olabilir |
| Ürün bilgisinin şirkette kalması | Belgeleme ve devir süreciyle sağlanır | Çoğunlukla kişinin kafasında kalır | Doğal olarak şirkette kalır |
| Maliyet yapısı | Sprint ya da proje bazlı, esnek | Saatlik ya da iş bazlı | Sabit maaş ve işe alım maliyeti |
| Yönetim yükü | Proje yönetimi ajansta | Yönetim büyük ölçüde sizde | Tamamen sizde |
| En uygun olduğu durum | Birden fazla disiplin gereken, hızlı doğrulama isteyen startup | Dar kapsamlı, tek teknolojili deneme | Teknik kurucusu olan, uzun vadeli ürün ekibi kuran şirket |
Teknik kurucunuz yoksa, hangi seçeneği tercih ederseniz edin ajansın verdiği mimari kararları sizin adınıza değerlendirecek birine ihtiyacınız olur. Bu boşluğu tam zamanlı bir CTO işe almadan kapatmanın yollarını CTO as a Service nedir, kimler için uygundur yazımızda anlattık.
Tipik bir MVP çalışması hangi aşamalardan oluşur?
İsimler ajanstan ajansa değişse de sağlıklı bir MVP çalışması genellikle dört aşamadan geçer. Her aşamanın süresi ürünün karmaşıklığına, entegrasyonlara ve karar alma hızınıza bağlıdır; keşiften önce kesin süre vaat edilmesi bu yüzden temkinle karşılanmalıdır.
- Keşif: Hipotez, hedef kullanıcı, doğrulama metriği ve eşik yazılır. Yapılacaklar ve yapılmayacaklar listesi netleşir, teknik riskler ve mimari kararlar belirlenir. Bu aşamanın çıktısı bir belge olmalıdır, bir izlenim değil.
- Sprint bazlı geliştirme: Kısa döngülerde çalışan yazılım üretilir, her sprint sonunda gerçek bir ortamda demo yapılır ve öncelikler sizinle birlikte güncellenir.
- Yayın: Ürün gerçek kullanıcılarla buluşur. Mağaza gönderimi, ödeme, hata izleme ve olay takibi bu aşamada hazır olmalıdır.
- Öğrenme döngüsü: Toplanan veri önceden belirlenen eşikle karşılaştırılır. Sonuç, devam etmek, yön değiştirmek ya da durmak için bir karar girdisidir. Teknik borç belgesi, sonraki adımın maliyetini görmenizi sağlar.
No-code ya da yapay zekâ ile yapılmış bir prototipiniz varsa ne olur?
Bugün pek çok girişimci ajansa boş bir sayfayla değil, Lovable, Cursor, Replit gibi araçlarla ya da bir no-code platformunda kurduğu çalışan bir prototiple geliyor. Bu kötü bir başlangıç değildir: prototip, hipotezin ilk hâlini somutlaştırır ve kapsam konuşmasını hızlandırır. Ancak ekranların çalışması, ürünün gerçek kullanıcıya açılmaya hazır olduğu anlamına gelmez; yetkilendirme, veri güvenliği, ödeme entegrasyonu ve yük altındaki davranış genellikle eksik kalır.
Böyle bir durumda ajansa şunu sorun: "Söz vermeden önce mevcut kodu okuyacak mısınız?" İyi bir ekip önce neyin gerçekten çalıştığını, neyin tesadüfen çalıştığını ayırır, sonra devam etmek mi yoksa belirli parçaları yeniden yazmak mı gerektiğini gerekçesiyle söyler. Bu geçişi nasıl ele aldığımızı Vibe-Code to Production hizmet sayfamızda, kendi başınıza yapabileceğiniz ön kontrolü ise vibe-code güvenlik kontrol listemizde bulabilirsiniz.
Detartech'te MVP'ye nasıl yaklaşıyoruz?
Detartech olarak MVP'yi şu cümleyle tanımlıyoruz: MVP daha küçük bir ürün değil, bir sorunun cevabıdır. Bu yüzden işe özellik listesiyle değil, doğrulama tasarımıyla başlıyoruz: hangi varsayımı, hangi metrikle, hangi eşiğe göre test edeceğimizi yazılı hâle getiriyoruz.
- İki haftalık sprint döngüleriyle çalışıyor, ilerlemeyi pre-prod ortamında çalışan yazılım üzerinden paylaşıyoruz; proje boyunca müşteriyle sürekli temastayız.
- Kod incelemesi (peer review) ve otomatik CI/CD hattı ilk günden kurulur, böylece sürüm çıkmak bir olay olmaktan çıkar.
- Proje sonunda büyümeden önce değişmesi gerekenlerle olduğu gibi kalabilecekleri ayıran yazılı bir teknik borç devri yapıyoruz.
- Yayın sonrası 30 günlük destek sürece dahildir.
Hizmetin ayrıntıları MVP geliştirme hizmeti sayfamızda, yayındaki örnek çalışmalarımız ise başarı hikayeleri sayfasında yer alıyor.
Bir MVP fikriniz ya da elinizde bir prototip varsa, yukarıdaki dokuz soruyu bize de sorabilirsiniz. Ücretsiz ön görüşme için hızlı teklif formunu doldurmanız yeterli; 24 saat içinde dönüş yapıyoruz.
Sıkça Sorulan Sorular
MVP ajansı seçerken fiyat tekliflerini karşılaştırmak yeterli mi?
Yeterli değildir, çünkü teklifler genellikle farklı kapsamları fiyatlar. Önce her ajansın hipotezi, kapsam dışını ve doğrulama ölçümünü nasıl tanımladığını karşılaştırın. Aynı soruyu cevaplayan kapsamlar üzerinden yapılan fiyat karşılaştırması anlamlı olur.
MVP'nin kaynak kodu kime ait olmalı?
Kaynak kod, altyapı hesapları ve alan adı baştan itibaren startup'a ait olmalıdır. Repo sizin hesabınızda açılmalı ve fikri mülkiyet devri sözleşmede yazılı olmalıdır. Bu, ileride ajans değiştirmek ya da şirket içi ekibe geçmek istediğinizde sizi korur.
Teknik kurucum yoksa MVP ajansıyla nasıl çalışmalıyım?
Ajansın mimari ve teknoloji kararlarını sizin adınıza değerlendirecek bağımsız bir teknik göz edinmeniz faydalı olur. Bu, yarı zamanlı bir teknik danışman ya da CTO as a Service modeliyle sağlanabilir. Ayrıca her önemli kararın gerekçesiyle yazılı tutulmasını talep edin.
MVP daha sonra baştan yeniden yazılmak zorunda mı?
Zorunda değildir, ama bu MVP'nin nasıl kurulduğuna bağlıdır. Veri modeli, kimlik doğrulama ve ödeme gibi temel kararlar sağlam verildiyse ürün genellikle kademeli olarak iyileştirilerek büyür. Yazılı bir teknik borç belgesi, neyin ne zaman değişmesi gerektiğini gösterir.
Lovable veya Cursor ile yaptığım prototipi bir ajans devralabilir mi?
Evet, çoğu durumda devralınabilir. Doğru ilk adım, ajansın söz vermeden önce mevcut kodu incelemesi ve güvenlik, entegrasyon ve dayanıklılık eksiklerini listelemesidir. Bu incelemeden sonra hangi parçaların korunacağı, hangilerinin yeniden yazılacağı gerekçesiyle belirlenir.
MVP ajansıyla ilk görüşmede ne hazırlamalıyım?
Çözdüğünüz problemi, hedef kullanıcınızı ve doğrulamak istediğiniz en kritik varsayımı birkaç cümleyle yazmanız yeterlidir. Varsa rakip ürünler, mevcut prototip ya da tasarımlar ve karar vermeniz gereken tarih de görüşmeyi verimli kılar. Özellik listesi hazırlamak zorunda değilsiniz; onu keşif aşamasında birlikte çıkarmak daha sağlıklıdır.
