MVP geliştirme: SaaS MVP nedir, nasıl planlanır?

MVP geliştirme, tek bir kullanıcı grubunun tek bir sorununu çözen en küçük çalışan ürünü yapıp gerçek kullanıcılara vermek ve onların davranışına bakarak devam edip etmeyeceğinize karar vermektir. SaaS'ta bu küçük ürün bile oturum açma, müşteri verilerinin birbirinden ayrılması, ödeme ve yedek gibi ertelenemeyen bir altyapı ister.

Bu yazı, ilk SaaS ürününü planlayan kurucular, ürün yöneticileri ve bir iş fikrini yazılıma dönüştürmek isteyen operasyon yöneticileri için hazırlandı. Teknik bilgi beklemiyoruz; bir terim gerektiğinde ilk geçtiği yerde açıklıyoruz. Aşağıda MVP'nin ne olduğunu ve ne olmadığını, doğru problemi ve kullanıcıyı nasıl seçeceğinizi, kapsamı nasıl daraltacağınızı, hangi altyapının ertelenemeyeceğini, dokuz adımlık bir planı, dört MVP seçeneğini karşılaştıran bir tabloyu ve bir yazılım firmasıyla ilk görüşmeye götürmeniz gerekenleri bulacaksınız. Yasal ve teknik bilgiler Ekim 2026 itibarıyla geçerlidir.

Yazılımda MVP nedir, ne değildir?

MVP, İngilizce "minimum viable product" ifadesinin kısaltmasıdır; Türkçede minimum uygulanabilir ürün denir. Kavramı yaygınlaştıran Lean Startup ilkelerine (yeni sekmede açılır) göre MVP, öğrenmeye en kısa yoldan başlamak için yapılan ilk üründür ve asıl iş "yap, ölç, öğren" döngüsünü olabildiğince hızlı çevirmektir. Yani ölçüt özellik sayısı değil, gerçek kullanıcıdan ne kadar çabuk ve ne kadar güvenilir bir kanıt aldığınızdır. "Minimum" kelimesi ürünün küçük olmasını, "uygulanabilir" kelimesi ise gerçek bir kullanıcının gerçek bir işini baştan sona bitirebilmesini anlatır. İkinci kelime çoğu zaman unutulur: kimsenin işini bitiremediği ince bir ürün MVP değil, bir demodur.

MVP'yi anlamanın en kolay yolu, ne olmadığına bakmaktır:

• Prototip değildir. Prototip, tıklanabilir ekranlarla bir akışı göstermeye yarar; arkasında gerçek veri, gerçek hesap ve gerçek ödeme yoktur. MVP'de kullanıcı kendi verisiyle çalışır ve yaptığı iş kalıcıdır.
• Yatırımcı demosu değildir. Tek bir senaryoda kusursuz çalışan ve yalnızca sunumda açılan bir sürüm, kullanıcıların ürünü gerçekte nasıl kullanacağı hakkında size hiçbir şey söylemez.
• Özensiz yapılmış bir ilk sürüm değildir. Az özellik, kötü yapılmış özellik anlamına gelmez. Ürünün içinde ne varsa güvenilir çalışmalı, veriyi kaybetmemeli ve hata verdiğinde ne olduğunu söylemelidir.
• Yol haritasının ilk üçte biri değildir. MVP bir öğrenme deneyidir ve sonunda bir karar vardır: devam etmek, yön değiştirmek ya da durdurmak. Kararı baştan yazmadıysanız, elinizdeki şey yalnızca küçük bir ürün olur.

SaaS MVP nedir?

SaaS MVP, birden fazla firmanın aynı sistemi kendi verisiyle kullandığı ve düzenli ödeme yaptığı, tek bir işi baştan sona çözen en küçük abonelik ürünüdür. SaaS (Software as a Service), tarayıcıdan kullanılan ve abonelikle satılan yazılım demektir. Bu yüzden bir SaaS MVP sıradan bir MVP'den bir adım daha ağırdır: aynı sistemde birden fazla firmanın verisini tutar ve her ay para tahsil eder. Bu iki özellik, en küçük SaaS ürününün bile bazı temel parçalardan vazgeçemeyeceği anlamına gelir. Bunları aşağıda ayrı bir bölümde ele alıyoruz; önce hangi sorunu kimin için çözdüğünüzü netleştirmek gerekiyor.

Tek problem ve tek kullanıcı nasıl seçilir?

MVP'nin kapsamını belirleyen ilk karar özellik listesi değil, kimin hangi işini çözdüğünüzdür. "KOBİ'ler" bir kullanıcı değildir; "on ile elli çalışanlı bir teknik servis firmasında haftalık iş planını hazırlayan operasyon sorumlusu" bir kullanıcıdır. Problemi de aynı netlikte yazın: bu kişi işi bugün nasıl yapıyor, bu ona ne kadar zaman kaybettiriyor ve iş aksadığında ne kaybediyor. Zaman ve kayıp bilgisini tahmin etmeyin, adaylara sorun. Bu tanımı tek bir paragrafa sığdıramıyorsanız, henüz bir yazılım firmasıyla kapsam konuşmaya hazır değilsiniz demektir.

Birden fazla aday problem arasında seçim yaparken şu ölçütler işe yarar:

• Sık yaşanan bir sorun seçin. Yılda bir kez yaşanan bir sorun için kimse her ay ödeme yapmaz. Haftalık ya da günlük tekrar eden bir iş, aboneliğin doğal gerekçesidir.
• Bugün para ya da zaman harcanan bir sorun seçin. Kullanıcı sorunu bugün bir tablo, bir serbest çalışan ya da fazla mesaiyle çözüyorsa, ödeme isteği gerçektir ve karşılaştırma noktanız hazırdır.
• Ulaşabileceğiniz bir kullanıcı seçin. İlk on kullanıcıyla bizzat konuşabilmelisiniz. Tanımadığınız bir pazara ilk günden reklamla girmek, öğrenmeyi hem yavaşlatır hem pahalılaştırır.
• Karar vereni ve kullananı ayırın. B2B SaaS'ta ödemeyi onaylayan kişi ile ürünü her gün kullanan kişi çoğu zaman farklıdır. MVP her gün kullanan kişinin işini kolaylaştırmalı; satış konuşması ise onay verenle yapılır.

Problemi ve kullanıcıyı seçtikten sonra bir cümle daha yazın: en riskli varsayımınız. Bu, yanlış çıkarsa geri kalan her şeyi anlamsız kılan inançtır. Tipik örnekler "kullanıcılar bunun için ödeme yapar", "ekipler alışkanlıklarını değiştirip yeni bir araca geçer" ve "ihtiyaç duyduğumuz veriyi mevcut sistemlerden alabiliriz" cümleleridir. MVP'nin ilk görevi bu varsayımı test etmektir. En riskli varsayımınız ödeme ise, ödeme alma işi MVP'de bir ayrıntı değil, deneyin kendisidir.

MVP kapsamı nasıl daraltılır? Şart, olmalı, sonra

Her özelliği üç kutudan birine koyun. Şart kutusu, olmadan en riskli varsayımın test edilemeyeceği şeyleri içerir. Olmalı kutusu değerli ama ilk kullanıcıların onsuz da işini bitirebildiği özellikleri içerir. Sonra kutusu ise bugün kimsenin istemediği ya da yalnızca sizin aklınızda olan her şeydir. Bu, ürün ekiplerinin dört kategoriyle çalışan MoSCoW önceliklendirme yönteminin üç kutuya indirilmiş, sade bir hâlidir. Basit bir kural koyun: şart kutusu tek bir sayfaya sığmalı. Sığmıyorsa ya kullanıcı tanımınız ya da problem tanımınız fazla geniştir.

Varsayımsal bir örnek: servis firmaları için iş emri takibi

Konuyu somutlaştırmak için kurgusal bir ürün düşünelim: küçük teknik servis firmalarının iş emirlerini takip eden bir SaaS. Kullanıcı, iş planını hazırlayan operasyon sorumlusu; en riskli varsayım, bu firmaların telefon ve mesajlaşma grubuyla yürüttükleri düzeni bırakıp aylık ücret ödeyerek bir araca geçeceği. Üç kutu şöyle dolabilir:

• Şart: sorumlu bir iş emri açar ve teknisyene atar; teknisyen işi telefonundan kapatır ve fotoğraf ekler; sorumlu günün durumunu tek ekranda görür; firma hesabı açılır, kullanıcılar davet edilir ve aylık abonelik ödenir.
• Olmalı: müşteriye otomatik "işiniz tamamlandı" e-postası, aylık özetin dışa aktarılması, tekrarlayan bakım planları.
• Sonra: mağazadan indirilen bir mobil uygulama, stok takibi, muhasebe entegrasyonu, yapay zekâ ile iş süresi tahmini, çoklu dil desteği.

Mobil uygulamanın "sonra" kutusunda olması bilinçli bir tercih: telefon tarayıcısında rahat çalışan duyarlı bir web arayüzü, teknisyenin ilk aşamadaki işini görür. Bu kararın ayrıntısını mobil uygulama mı web uygulaması mı yazımızda ele aldık. Muhasebe entegrasyonu da "sonra" kutusunda, ama veri modeli ileride ona engel olmayacak şekilde kurulur. Yapay zekâ özelliği ise ürünün temel değeri kanıtlandıktan sonra anlam kazanır; o aşamada yapay zekâ ve süreç otomasyonu ayrı bir proje olarak ele alınabilir. Kesilen her özellik için kısa bir not alın: neden kesildi ve hangi işaret onu geri getirir.

SaaS MVP'de hangi altyapı ertelenemez?

Özellikler kesilebilir, ama birden fazla firmanın verisini tutan ve para tahsil eden bir sistemin temeli kesilemez. Bu parçalar kullanıcıya özellik olarak görünmez; eksik olduklarında ise ilk müşteriyle birlikte ortaya çıkarlar. Sonradan eklenmeleri, baştan kurulmalarından neredeyse her zaman daha pahalıdır, çünkü veri modeline ve her ekrana dokunurlar. Aşağıdaki liste, en küçük SaaS MVP'si için bile asgari düzeydir; SaaS platform geliştirme projelerinde ilk sürümün tabanını da bu parçalar oluşturur.

Ertelenemeyenler

• Kimlik doğrulama: e-postayla kayıt ve giriş, şifre sıfırlama, oturum süresi ve mümkünse iki adımlı doğrulama seçeneği. Şifreleri kendiniz saklıyorsanız güvenli özetleme (hashing) ve hatalı deneme sınırı şarttır.
• Çok kiracılı yapının temelleri: çok kiracılı (multi-tenant) yapı, birden fazla müşteri firmanın aynı sistemi kendi verileriyle kullanması demektir. Her kayıt bir firmaya bağlanır ve her sorgu o firmayla sınırlanır. Bir müşterinin başka bir müşterinin verisini görmesi, MVP'de bile güveni bitirecek bir hatadır; bu sınır en baştan veri modeline ve otomatik testlere yazılır.
• Roller ve davet: en az "firma yöneticisi" ve "kullanıcı" ayrımı ve ekip arkadaşını davet etme. Ayrıntılı yetki matrisi bekleyebilir, ayrımın kendisi bekleyemez.
• Abonelik ve ödeme: tek paket ve aylık ödeme çoğu MVP için yeterlidir. Türkiye'de satış yapıyorsanız her tahsilatın faturasını da planlayın: e-Fatura ve e-Arşiv Fatura, Gelir İdaresi Başkanlığı'nın elektronik belge uygulamalarıdır (yeni sekmede açılır). Hangisinin size uygulandığını mali müşavirinizle netleştirin.
• İşlem e-postaları: davet, şifre sıfırlama, ödeme makbuzu ve başarısız ödeme bildirimi. Bunlar pazarlama e-postası değildir ve spam klasörüne düşmemeleri için alan adınızın e-posta ayarlarının doğru yapılması gerekir.
• Hata kayıtları, izleme ve yedek: hataların tutulduğu kayıtlar, bir şey bozulduğunda size haber veren basit bir izleme ve geri yüklemesi en az bir kez denenmiş otomatik veritabanı yedeği. Geri yüklemesi denenmemiş bir yedeğe güvenmeyin.
• KVKK temelleri: kullanıcılar ve onların müşterileri hakkında kişisel veri tutuyorsanız, Ekim 2026 itibarıyla 6698 sayılı Kişisel Verilerin Korunması Kanunu (yeni sekmede açılır) aydınlatma yükümlülüğü (madde 10), ilgili kişinin hakları (madde 11) ve veri güvenliği için idari ve teknik tedbirler (madde 12) ister. Sunucularınız yurt dışındaysa, 2024'te 7499 sayılı Kanunla değiştirilen yurt dışına aktarım kuralları (madde 9) da devreye girer.

KVKK konusunda SaaS'ın bir özelliğini bilmekte fayda var: çoğu zaman iki rolünüz olur. Kendi kullanıcılarınızın hesap bilgileri için veri sorumlusu, müşterilerinizin sisteme girdiği veriler için ise veri işleyen konumundasınızdır. Kişisel Verileri Koruma Kurumu, veri sorumlusunun veri güvenliğine ilişkin yükümlülüklerini (yeni sekmede açılır) ve bir ihlalin Kurula en kısa sürede bildirilmesi gerektiğini ayrıca açıklıyor (Ekim 2026 itibarıyla). MVP aşamasında bunun pratik karşılığı şudur: bir aydınlatma metni, erişim yetkilerinin kayda alınması, şifreli bağlantı ve verinin hangi ülkede tutulduğunu bilmektir. Bu bölüm bilgi amaçlıdır, hukuki görüş değildir; kendi durumunuz için bir hukukçuya danışın.

Bekleyebilecekler

Ertelenebilecek altyapı listesi de en az ertelenemeyenler kadar önemlidir, çünkü MVP bütçesi en kolay bu kalemlerle şişer. Kurumsal tek oturum açma (SSO), ayrıntılı yetki matrisleri, birden fazla paket ve yıllık ödeme seçenekleri, kullanım analitiği panoları, dışarıya açık bir API, beyaz etiket (white label, ürünü müşterinin markasıyla sunma), çoklu dil ve gelişmiş bir iç yönetim paneli ilk on müşterinin değil, sonrakilerin isteğidir. İç ekip için başlangıçta birkaç temel işlem yapan sade bir yönetim ekranı yeter. Bir özelliği ne zaman geri getireceğinizi bilmek için basit bir ölçüt kullanın: ödeme yapan iki farklı müşteri aynı şeyi istediyse, "sonra" kutusundan "olmalı" kutusuna taşıyın.

Hazır bileşen mi, kendi kodunuz mu?

Kural basit: sizi farklılaştırmayan ve hata yapıldığında pahalıya patlayan her şeyi hazır alın, ürününüzü farklı kılan iş kurallarını kendiniz yazın. Bileşen bazında karar şöyle şekillenir:

• Kimlik doğrulama: çoğu MVP'de hazır alın. Barındırılan bir kimlik doğrulama servisi ya da kullandığınız yazılım çatısının olgun bir kütüphanesi; şifre saklama, oturum yönetimi ve iki adımlı doğrulama gibi hata affetmeyen işleri üstlenir. Müşterileriniz verinin tamamen kendi sunucularında kalmasını şart koşuyorsa, açık kaynak bir kütüphaneyle kendi sunucunuzda kurun.
• Ödeme: her zaman hazır alın. Kart bilgisini kendi sunucunuzda saklamak, Ekim 2026 itibarıyla kart verisini saklayan, işleyen ya da ileten herkes için geçerli olan PCI DSS güvenlik standardının (yeni sekmede açılır) yükünü üzerinize alır. Bir ödeme kuruluşunun kart saklama ve yinelenen ödeme özelliğini kullanın; seçtiğiniz servisin şirketinizin ülkesinde ve müşterilerinizin kartlarıyla çalıştığını resmi dokümanından doğrulayın.
• E-posta gönderimi: hazır alın. İşlem e-postası servisleri teslim edilebilirliği, geri dönen e-postaları ve şikâyetleri yönetir. Kendi e-posta sunucunuzu kurmak bir MVP'nin işi değildir; şablonları ve metinleri ise kendiniz yazın.
• Kiracı modeli ve iş kuralları: kendiniz yazın. Firmalar arası veri sınırı, roller ve ürünün asıl iş akışı sizin veri modelinize bağlıdır. Bunları kapalı bir şablona bırakmak, ilk özel müşteri isteğinde duvara çarpmak demektir.

Her hazır servis bir bağımlılık ve bir aylık faturadır. Verinizi dışa aktarabildiğinizi kontrol edin ve servisin fiyatlandırmasının kullanıcı sayısıyla nasıl büyüdüğüne bakın. Ürünün tamamı için hazır mı özel mi sorusu ayrı bir karardır; onu özel yazılım mı hazır yazılım mı rehberimizde tartıştık.

MVP nasıl yapılır? Dokuz adımlık plan

MVP dokuz adımda yapılır: problemi yazmak, kullanıcıyla konuşmak, en riskli varsayımı belirlemek, kapsamı ayırmak, prototiple test etmek, kısa döngülerle geliştirmek, davetli kullanıcılarla yayına almak, ölçmek ve karar vermek. Sıra, kodun mümkün olduğunca geç ve az yazılması için kurulmuştur. Her adımın bir çıktısı vardır ve bir sonraki adım o çıktıya dayanır; atlanan adımın sorusu daha sonra, daha pahalı bir anda yeniden sorulur.

1. Problemi yazın. Tek paragraf: kim, hangi iş, bugün nasıl çözülüyor ve neden yetmiyor.
2. Kullanıcı adaylarını seçin ve onlarla konuşun. İlk on aday kullanıcının adını yazabilmelisiniz. Ürününüzü anlatmadan, bu işi son kez nasıl yaptıklarını sorun.
3. En riskli varsayımı ve başarı ölçütünü belirleyin. Örneğin "davet ettiğimiz firmaların çoğu ikinci haftada da iş emri açıyor ve ilk ayın sonunda ödeme yapıyor." Ölçütü geliştirme başlamadan yazın.
4. Kapsamı üç kutuya ayırın ve yazıya geçirin. Şart, olmalı ve sonra listesi, ertelenemeyen altyapıyla birlikte. Yazılı kapsam, sağlıklı bir fiyat teklifi almanın da temelidir.
5. Prototiple test edin. Tıklanabilir ekranları birkaç aday kullanıcıya gösterin. Akışı kod yazılmadan önce düzeltmek, en ucuz düzeltmedir.
6. Kısa döngülerle geliştirin. İki haftalık döngüler ve her döngünün sonunda test ortamında açıp deneyebileceğiniz çalışan bir sürüm.
7. Az sayıda kullanıcıyla yayına alın. Herkese açık bir lansman değil, davetle gelen ilk kullanıcılar. Kurulumu onlarla birlikte yapın ve nerede takıldıklarını izleyin.
8. Ölçün. Kayıt sayısını değil kullanımı ölçün: ikinci haftada geri gelenler, asıl işi baştan sona tamamlayanlar, ödeme yapanlar. Sayıları kullanıcı görüşmeleriyle birlikte okuyun.
9. Karar verin. Önceden yazdığınız ölçüte göre devam edin, yön değiştirin ya da durdurun. Durdurmak da geçerli bir sonuçtur; MVP'nin varlık sebebi bu kararı ucuza verdirmektir.

Örneğimize dönersek: iş emri takibi ürününde dördüncü adımın sonunda tek sayfalık bir şart listesi ve altyapı listesi olur, beşinci adımda teknisyen ekranı birkaç servis firmasında denenir, yedinci adımda yalnızca davet edilen firmalar sisteme alınır. Dokuzuncu adımda "devam" kararı çıkarsa olmalı kutusundaki müşteri e-postası ve dışa aktarma sıraya girer. Kullanıcılar ürünü kullanıyor ama ödeme yapmıyorsa, sorun büyük ihtimalle özellikte değil, kullanıcı ya da fiyat seçimindedir.

MVP seçenekleri karşılaştırması: no-code, landing page, özel MVP, tam ürün

Her fikir için özel yazılım gerekmez. Neyi test etmek istediğinize göre dört yol vardır ve doğru yol çoğu zaman en ucuz olandır. Aşağıdaki tablo bu dört yolu aynı ölçütlerle karşılaştırıyor.

Tablodaki seçimi şöyle özetleyebiliriz:

• No-code prototipi seçin, akışın anlaşılır olup olmadığını ve kullanıcının ürünü gerçekten kullanmak isteyip istemediğini görmek istiyorsanız ve veri hassas değilse.
• Landing page ve elle hizmeti seçin, en riskli varsayımınız talep ya da ödeme ise. Basit bir landing page (tanıtım sayfası), bir ön kayıt ya da ön ödeme formu ve arkada işi sizin elle yaptığınız bir hizmet, tek satır kod yazmadan talebi ölçer. Sayfanın aramalarda bulunabilmesi için Next.js SEO kontrol listemize göz atabilirsiniz.
• Dar kapsamlı özel MVP'yi seçin, talep kanıtınız varsa ve ürün çok kiracılı veri, ödeme, entegrasyon ya da KVKK açısından hassas veri gerektiriyorsa. Kapsam dar, altyapı sağlamdır.
• Tam ürünü seçin, yalnızca kullanıcıları, problemi ve ödeme isteğini zaten biliyorsanız; örneğin şirket içinde yıllardır elle yürüyen bir süreci ürüne dönüştürüyorsanız. Bu durumda "MVP" dediğiniz şey aslında ilk sürümdür ve öyle planlanmalıdır.

MVP maliyetini ve süresini ne belirler?

Bir MVP'nin maliyetini ve süresini belirleyen şey, ürünün adı ya da sektörü değil, kapsam kararlarıdır. Bu yazıda bir fiyat aralığı vermiyoruz, çünkü kapsamı yazılmamış bir ürün için verilen her rakam tahminden ibarettir. Bunun yerine, rakamı hangi kararların hangi yöne oynattığını görmek daha işe yarar:

• Şart kutusunun büyüklüğü: en büyük etkendir. Her ek iş akışı ekran, veri, test ve dokümantasyon demektir.
• Kullanıcı türü sayısı: yönetici, teknisyen ve son müşteri gibi her rol ayrı ekranlar, ayrı yetkiler ve ayrı testler getirir.
• Entegrasyonlar: muhasebe yazılımı, e-Fatura entegratörü ya da mevcut bir ERP. Başka bir sistemin API'si, onun dokümantasyonu ve test ortamı kadar hızlı ilerler; takvimin bir kısmı sizin elinizde değildir.
• Ödeme modeli: tek paket ve aylık ödeme basittir; deneme süresi, kullanım bazlı fiyatlama ve paket yükseltme her biri ayrı bir iş akışıdır.
• Veri ve uyum gereksinimleri: sağlık gibi özel nitelikli kişisel veriler, verinin Türkiye'de tutulması şartı ya da kurumsal müşterilerin güvenlik anketleri işi büyütür.
• Platform: yalnızca web, web ve mobil ya da mağaza uygulaması; her platform ayrı bir yayın ve bakım sürecidir.
• Karar hızı: sizin tarafınızda onay verecek kişinin haftada ne kadar zaman ayırabildiği, süreyi en az teknik kararlar kadar etkiler.

Bunu teklif aşamasında kendiniz test edebilirsiniz: firmaya, şart kutusundaki bir kalem çıkarılırsa fiyatın ve sürenin nasıl değişeceğini sorun. Cevap net geliyorsa teklif gerçekten kapsama dayanıyordur; belirsiz geliyorsa toplam rakam da belirsizdir. Teklifleri aynı ölçüyle okumak için yazılım yaptırma maliyeti ve teklif karşılaştırma rehberimizi kullanabilirsiniz.

Yazılım firmasıyla ilk görüşme: kontrol listesi ve sık yapılan hatalar

İlk görüşmenin amacı fiyat almak değil, firmanın problemi sizin anladığınız gibi anlayıp anlamadığını görmektir. Aşağıdaki hazırlık, görüşmeyi kısa ve verimli kılar ve sonradan gelen tekliflerin karşılaştırılabilir olmasını sağlar.

İlk görüşmeye götürmeniz gerekenler

• Tek paragraflık problem tanımı ve kullanıcı tanımı.
• En riskli varsayım ve onu ölçecek başarı ölçütü.
• Şart, olmalı ve sonra listesi; ertelenemeyen altyapı kalemleri işaretlenmiş olarak.
• Bugün kullanılan araçların ve bağlanması gereken sistemlerin listesi; tablolar da dahil. Süreç bugün tablolar üzerinde yürüyorsa Excel'den yazılıma geçiş yazımız bu envanteri çıkarmanıza yardım eder.
• Hangi kişisel verileri tutacağınız ve sunucuların hangi ülkede olması gerektiği.
• Ödeme modeli: deneme süresi olacak mı, aylık mı yıllık mı, kaç paket.
• Sizin tarafınızda karar verecek kişi ve haftada ayırabileceği zaman.
• Soracağınız sorular: kod deposu ve bulut hesapları kimin adına açılacak, kapsam değişikliği nasıl fiyatlanır, her döngünün sonunda ne göreceğiz, yayından sonra destek dönemi ne kadar ve yazılı mı?

Sık yapılan hatalar

• Herkes için yapmak. Üç farklı kullanıcı türünü aynı anda memnun etmeye çalışan MVP, hiçbirinden net bir sinyal alamaz.
• Altyapıyı "sonra" kutusuna atmak. Firma bazlı veri ayrımı ya da yedek sonradan eklenmeye çalışıldığında, çoğu zaman veri modelinin ve ekranların önemli bir kısmının yeniden yazılması gerekir.
• Altyapıyı abartmak. Henüz kullanıcısı olmayan bir ürün için birçok ayrı servise bölünmüş mimari, çok bölgeli sunucular ve karmaşık otomatik yayın süreçleri bütçeyi ürüne değil, iskeleye harcatır.
• Ödemeyi ertelemek. En riskli varsayım ödeme ise ve MVP ücretsiz sunuluyorsa, deney asıl soruyu hiç sormamış olur.
• Başarı ölçütünü sonradan yazmak. Sonuçlar geldikten sonra yazılan ölçüt, sonucu haklı çıkaracak şekilde yazılma eğilimindedir.
• Geri bildirimi istek listesi sanmak. Kullanıcının istediği özellik değil, o özelliği istemesine yol açan sorun önemlidir; çözüm çoğu zaman daha küçüktür.

Biz olsak ne yapardık?

Tipik bir durumu düşünelim: sektörünü iyi bilen bir kurucu, net bir problem ve ilk on kullanıcıya ulaşabilecek bir çevre. Biz önce 30 ile 45 dakikalık bir keşif görüşmesi yapar ve problemi nasıl anladığımızı yazılı bir özetle size geri gönderirdik. MVP geliştirme sürecinde talep henüz kanıtlanmadıysa, kod yazmadan önce ucuz bir deneme yapmanızı önerirdik. Talep kanıtı varsa, şart, olmalı ve sonra listesini ertelenemeyen altyapıyla birlikte yazılı bir kapsam dokümanına çevirir, sabit fiyatı ancak bu kapsam yazıldıktan sonra verirdik. Kapsam yolda değişirse, değişiklik geliştirilmeden önce fiyatlanır; faturada sürprizle karşılaşmazsınız.

Teknik tarafta önerimiz, tarayıcıda ve telefonda çalışan duyarlı bir web uygulaması, hazır bir kimlik doğrulama çözümü ve bir ödeme kuruluşunun yinelenen ödeme özelliğidir. Firma bazlı veri ayrımını ise kendimiz yazar ve otomatik testlerle korurduk. Geliştirme iki haftalık döngülerle ilerler ve her döngü, test ortamında açıp deneyebileceğiniz çalışan bir sürümle biter. Kod deposu, bulut hesapları, alan adı, ödeme ve e-posta servisleri ilk günden şirketinizin adına açılır. Yayından sonra yazılı bir destek dönemi boyunca yanınızda kalırız. Bu yaklaşımın ayrıntıları SaaS platform geliştirme sayfamızda; ürün abonelik modeli taşımayan bir iş uygulamasıysa web uygulaması geliştirme sayfamız daha uygun bir başlangıçtır.

Hangi durumlarda bizimle çalışmamalısınız?

Bir yazılım firmasıyla çalışmak her MVP için doğru adım değildir. Aşağıdaki durumlarda bütçenizi başka yere harcamanızı öneririz:

• Talebi henüz bilmiyorsanız. Kimsenin ödeme yapıp yapmayacağını bilmiyorsanız, önce bir landing page ya da no-code prototiple doğrulayın. Özel geliştirme bütçesi, talep kanıtı geldikten sonra çok daha verimli harcanır.
• Kapsam çok küçükse. Tek bir form, bir tablo ve bir e-posta bildiriminden ibaret bir iş için hazır bir araç yeter; bunun için özel yazılım yaptırmak gereksiz bir maliyettir.
• Kendi ürün ekibiniz varsa. Şirketinizde ürünü sahiplenecek mühendisler varsa, MVP'yi onların yapması ürün bilgisinin şirkette kalmasını sağlar. Dışarıdan bir ekip, bu durumda pahalı ve geçici bir katmandır.
• Hazır bir SaaS işinizi görüyorsa. Çözmek istediğiniz problem için olgun bir ürün varsa ve sizi farklılaştıran bir iş kuralı yoksa, önce onu kullanın.

Bu durumların hiçbiri size uymuyorsa ve ilk SaaS ürününüzün kapsamını birlikte yazmak istiyorsanız, iletişim sayfamızdan bize yazın; ilk yanıtı 24 saat içinde veriyoruz.