SaaS Ürün Geliştirme: MVP'den İlk Ödeyen Müşteriye 9 Adım

Bize gelen girişimcilerin çoğu ilk toplantıya bir özellik listesiyle geliyor. Kimininki otuz satır, kimininki yetmiş. Listeyi birlikte okuduktan sonra sorduğumuz soru hep aynı: “Bunu bugün kim, parasını ödeyerek kullanır?”

Soğuk bir soru gibi duruyor, farkındayız. Ama bir SaaS ürününde en pahalı hata yanlış teknolojiyi seçmek değil; kimsenin para vermeyeceği bir ürünü eksiksiz yapmak. Aşağıdaki adımları, fikri olan girişimcilerle ve kendi iç aracını ürüne çevirmek isteyen firmalarla çalışırken izlediğimiz sırayla yazdık. Bazıları uzun, bazıları tek paragraf; ağırlıkları da öyle.

1. Önce yazılım değil, müşteri

Kod yazılmadan önce, ürünü satın alacağını düşündüğünüz on–on beş kişiyle konuşun. Fikrinizi anlatmak için değil, bugün bu işi nasıl yaptıklarını dinlemek için. Excel'le mi, kâğıtla mı, pahalı bir yabancı yazılımla mı idare ediyorlar; bu işe ayda ne kadar zaman gidiyor ve o zamanı kim harcıyor?

En değerli işaret, “harika fikir” demeleri değildir. “Hazır olunca haber ver, ilk ben kullanırım” deyip telefonunu bırakmalarıdır. Daha da iyisi ön ödeme ya da imzalı bir niyet yazısı. Tek satır kod yazılmadan ödemeye razı birkaç müşteri, hiçbir özellik listesinin veremeyeceği netlikte bir yol haritası verir.

Kendi iç aracını ürüne çevirmek isteyen firmalar için bu adım biraz farklı işliyor. Ürünün bir müşterisi zaten var: firmanın kendisi. Tehlike de burada.

Sizin çalışma biçiminize göre şekillenmiş bir araç, başka firmaların çalışma biçimine uymayabilir. Rakibiniz olmayan, benzer ölçekte birkaç firmaya aracı gösterip kendi işlerinde nasıl kullanacaklarını sormak, hangi kısımların sizin alışkanlığınız, hangilerinin ortak bir ihtiyaç olduğunu ortaya çıkarır.

Girişimcilere bunu söylediğimizde, bir yazılım firması olarak kendi aleyhimize konuştuğumuzu düşünenler oluyor. Durum tam tersi: müşterisi belli bir proje daha hızlı ilerliyor ve daha az yön değiştiriyor. Girişim projelerinin fırsat ve zorluklarını startup proje geliştirme yazımızda da konuşmuştuk.

2. MVP'yi gerçekten küçük tutun

MVP (minimum viable product, Türkçesiyle asgari uygulanabilir ürün), tek bir sorunu çözen ve para istenebilecek kadar işe yarayan en küçük ürün hâlidir. Tanımı herkes biliyor; “küçük” kısmı ise her projede tartışma çıkarıyor.

Kullandığımız test basit: ürünün vaat ettiği ana işi bir kullanıcı baştan sona yapabiliyor mu? Bir kurs yönetim yazılımı için bu; öğrenci kaydı, ders programı ve tahsilat takibi olabilir. Veli uygulaması, sınav modülü, toplu SMS ve gelişmiş raporlar bu teste girmez. Ana işi engellemeyen her şey ikinci sürüme gider.

Küçük, özensiz demek değil. Para isteyeceğiniz bir ürünün az sayıdaki ekranı temiz, hızlı ve hatasız olmalı. Eksik özellik affedilir; çalışmayan düğme affedilmez.

Takvimi de kapsam kadar ciddiye alın. Aylar yerine yıllara yayılan bir MVP, adı ne olursa olsun artık MVP değildir; pazar o sırada sizi beklemez.

Bir ipucu daha: MVP döneminde bazı işleri elle yapmaktan çekinmeyin. İlk müşterilerin hesaplarını siz açın, aylık raporu siz hazırlayıp gönderin. On müşteride elle yapılan iş, müşteri sayısı arttığında otomatikleştirilir. O zamana kadar neyin gerçekten otomatikleşmesi gerektiğini de öğrenmiş olursunuz.

3. Çok kiracılı mimariye baştan karar verin

SaaS ürününü tek bir firmaya yazılmış yazılımdan ayıran teknik fark şu: aynı uygulama, birbirinin verisini asla görmemesi gereken çok sayıda müşteriye hizmet veriyor. Buna çok kiracılı (multi-tenant) mimari deniyor ve sonradan eklenmesi en zor şeylerden biri.

Yaygın üç yol var. Birincisinde tüm müşteriler aynı veritabanını ve aynı tabloları paylaşır, her kayıtta hangi müşteriye ait olduğu yazar. İkincisinde her müşteri aynı veritabanında ayrı bir şema kullanır. Üçüncüsünde her müşterinin veritabanı tamamen ayrıdır; ayrım en güçlü hâlini alır ama sunucu maliyeti ve bakım yükü de artar.

Çoğu MVP için ortak veritabanını öneriyoruz, bir şartla: müşteri ayrımı, geliştiricinin her sorguya elle eklediği bir filtreye bırakılmamalı. .NET tarafında Entity Framework Core'un global sorgu filtreleri, PostgreSQL'de satır düzeyi güvenlik (row-level security) gibi mekanizmalarla bu ayrımı altyapıya gömüyoruz. Bir geliştiricinin tek bir sorguda filtreyi unutması, bir müşterinin diğerinin faturalarını görmesi demek. SaaS'ta bundan daha hızlı güven kaybettiren hata azdır.

Kendi iç aracını ürüne çevirmek isteyen firmalarda en büyük iş de burada çıkıyor. Tek firma için yazılmış bir özel yazılımda firma adı, vergi ayarları, onay kuralları, belge şablonları gibi pek çok şey koda gömülüdür. Bunları müşteri bazlı ayara çevirmek, yeni özellik eklemekten daha fazla emek ister.

Müşterinin kendi alt alan adıyla giriş yapması, ekranlarda kendi logosunu görmesi gibi küçük kişiselleştirmeler de bu kararla birlikte düşünülmeli. İlk sürümde olmasalar bile mimari onlara yer bırakmalı.

4. Aboneliği ve tekrarlayan ödemeyi hafife almayın

“Karttan her ay çekeriz” cümlesinin arkasında, tahmin edilenden çok iş var:

• Kartı saklayan ve tekrarlı çekim yapabilen bir ödeme kuruluşuyla çalışmak gerekir. Kart bilgisi hiçbir zaman sizin veritabanınızda durmamalı.
• Çekim başarısız olduğunda kaç kez yeniden denenecek, müşteriye ne zaman haber verilecek, hesap ne zaman kısıtlanacak; bunların kuralı yazılı olmalı.
• Ay ortasında paket yükseltme ya da düşürme yapılırsa farkın nasıl hesaplanacağı baştan belirlenmeli.
• Her tahsilatın faturası kesilmeli. e-Fatura ve e-Arşiv entegrasyonunu plana koyun; müşteri sayısı arttıkça faturayı elle kesmek birinin bütün gününü alır.
• Yıllık peşin ödeme seçeneği, ilk dönemin nakit akışı için aylık ödemeden daha değerli.

İlk sürümde bunların hepsini otomatikleştirmek şart değil. Ama veri modeli bunlara göre kurulmazsa ikinci sürümde yeniden yazmak gerekir.

Fiyatlandırmayı da bu adımda düşünün: kullanıcı başı mı, kullanım miktarına göre mi, paket bazlı mı? İlk aşamada iki üç sade paket, ayrıntılı bir fiyat hesaplayıcısından daha kolay satılıyor. Düşük fiyatla başlamak cazip gelir, ama ucuz fiyatla gelen müşteriyi sonradan zamla tutmak zordur. Gerçekçi bir fiyatla başlayıp ilk müşterilere süreli bir kurucu indirimi tanımak daha rahat bir yol.

5. Deneme süresine bir amaç verin

Deneme süresinin uzunluğundan çok, kullanıcının o süre içinde ürünün değerini görüp görmediğine bakın. On dört günlük denemede kullanıcı ilk gün hesabını açıp bir daha girmiyorsa süreyi otuz güne çıkarmak bir şey değiştirmez. Kayıttan hemen sonra kullanıcıyı ana işe götüren kısa bir kurulum akışı ve örnek verilerle dolu bir demo hesabı, süreden daha çok işe yarıyor. Kart bilgisi isteyip istememe konusunda ise evrensel bir doğru yok: kartsız deneme daha çok kayıt, kartlı deneme daha istekli kayıt getirir.

6. İlk ödeyen müşteriyi kendiniz bulun

İlk müşteri reklamla gelmez. Birinci adımda konuştuğunuz insanlara, sektör derneklerine, eski iş bağlantılarınıza tek tek ulaşın ve ilk satışları kurucu olarak kendiniz yapın; ürün hakkında en çok şeyi o görüşmelerde öğreneceksiniz. İlk müşterilere indirim verebilirsiniz ama ürünü bedava vermeyin. Ödeme yapmayan kullanıcının geri bildirimiyle ödeyeninki aynı ağırlıkta olmuyor.

7. Sonraya bırakılanları yazılı tutun

MVP'yi küçük tutmanın en pratik yolu, “şimdi değil” dediğiniz özellikleri bir kenara yazmak. İlk sürüme girmemesini önerdiğimiz başlıklar:

• Mobil uygulama; telefonda iyi çalışan bir web arayüzü başlangıç için yeterli
• Çoklu dil ve çoklu para birimi
• Kullanıcının kendi raporunu tasarladığı rapor oluşturucu
• İlk müşterilerin gerçekten istediği bir iki tanesi dışındaki entegrasyonlar
• Ürünü müşterinin kendi markasıyla sunma (beyaz etiket)
• Ayrıntılı yetki matrisi; başlangıçta “yönetici” ve “kullanıcı” rolleri yetiyor

Bu listeye itiraz genellikle tek bir cümleyle geliyor: “Ama rakipte var.” Rakibin o özelliğini kaç müşterisinin gerçekten kullandığını bilmiyorsanız bu bir gerekçe değil, tahmin. Bizim sorduğumuz soru hep aynı: bu özellik olmadan ilk on müşteri ödemeyi reddeder mi? Cevap hayırsa, özellik listede kalır.

Listeyi de silmeyin. Bir özelliği farklı müşteriler üst üste istemeye başladığında listeden çıkar, yol haritasına girer.

8. Teknolojiyi ürünün ömrüne göre seçin

Teknoloji tartışması genellikle en uzun süren ama sonuca en az etki eden tartışma. Bizim tercihimiz, yıllarca bakımı yapılabilecek ve ekip bulmanın zor olmadığı araçlar: sunucu tarafında .NET, arayüzde React ya da Next.js, veritabanında PostgreSQL. Seçim ne olursa olsun kaynak kodun ve sunucu erişiminin sizde olduğundan, uygulamanın Docker gibi taşınabilir bir yapıda paketlendiğinden emin olun. Bir gün yazılım ekibinizi değiştirmek isterseniz, ürünü baştan yazmakla bir devir teslim toplantısı arasındaki farkı bu ikisi belirler.

Canlıya çıktığınız gün hazır olması gereken iki şey daha var: canlıdaki hataları size anında bildiren bir hata izleme aracı ve düzenli olarak geri yüklenip denenen yedek. İlk müşterileriniz karşılaştıkları hatayı size bildirmez; sessizce kullanmayı bırakır.

Barındırma kararını da teknik bir ayrıntı saymayın. Kurumsal müşterilerin ilk sorduğu şeylerden biri verinin nerede durduğu. Müşterilerinizin sisteme girdiği veriler çoğu durumda onların sorumluluğundaki kişisel verilerdir ve KVKK karşısında sizin rolünüz, sözleşmelerinize girmesi gereken bir konudur. Bu maddeleri hukuk danışmanınızla birlikte hazırlayın; ilk kurumsal müşteride sorulduğunda elinizde hazır olsun.

9. Ölçmeden ikinci sürüme geçmeyin

Dört sayıyı ilk günden takip edin: kaç kişinin kayıt olduğu, kaçının ilk hafta ana işi en az bir kez yaptığı, kaçının denemeden sonra ödediği ve ödeyenlerin kaçının üçüncü ayda hâlâ ödediği. Bunları gösteren sade bir panel, pahalı analitik araçlarından daha çok işe yarar. İkinci sürümün kapsamını bu sayılar belirlesin; en yüksek sesle konuşan müşteri değil.

Aboneliğini iptal eden her müşteriyi de arayın. Form göndermeyin, telefonla arayın. İptal nedenlerini birkaç ay boyunca bir tabloya yazdığınızda, ikinci sürümün yol haritasının yarısı kendiliğinden ortaya çıkıyor.

SaaS ve üyelik platformları, web yazılım tarafında en sevdiğimiz işler arasında. Müşteri görüşmelerinizi yaptıysanız ve elinizde “ilk ben kullanırım” diyen birkaç isim varsa, ilk sürümün sınırlarını birlikte çizebiliriz.