Geliştirme

Sıfırdan SaaS: ilk sürüme neler girer

SaaS'ın ilk sürümü kırpılmış bir ürün değil, tek bir çalışan senaryosu olan bir üründür. Neyin zorunlu olduğunu, neyin ertelenebileceğini ve her ertelemenin bedelini ele alıyoruz.

30 Ağustos 2026

SaaS'ın ilk sürümü neredeyse her zaman bir özellik listesi olarak tartışılır ama bir senaryodan yola çıkılarak kurulmalıdır. Fark temeldir: özellik listesi istenildiği kadar kırpılıp kullanılamayan bir ürüne dönüşebilir, senaryo ise ya baştan sona çalışır ya da hiç çalışmaz. Aşağıda ilk sürümde neyin zorunlu olduğu, neyin zarar vermeden ertelenebileceği ve her "sonra"nın tam olarak neye mal olduğu var.

Asgari faydalı ürün tek bir uçtan uca senaryodur

Müşterinin size geleceği ana işi alın ve geçici çözümler olmadan sonuna kadar götürün. Ürün talep takibine yardım ediyorsa talep oluşturulabilir, değiştirilebilir, bulunabilir ve kapatılabilir. Raporlarla ilgiliyse veri yüklenebilir, görüntülenebilir ve dışa aktarılabilir.

Senaryonun eksik kaldığının işareti: demoda "bu kısmı şimdilik elle yapıyoruz" demek zorunda kalmak. Böyle tek bir yer ürünü hizmete dönüştürür ve müşteri yazılım için değil, sizin elle verdiğiniz destek için ödeme yapar. Bazen başlangıçta bu bilinçli bir stratejidir ama bu karar kendiliğinden değil, açıkça verilmelidir.

Pratik bir yöntem: ilk sürümü özelliklerle değil, "müşteri giriş yapar ve tek oturumda şu sonucu alır" cümlesiyle tarif edin. Bu cümlede yer almayan her şey bir sonraki sürüm için adaydır.

Kayıt, hesaplar ve roller

Tasarrufun en çok ters teptiği yer burasıdır. SaaS'ta kullanıcı neredeyse hiçbir zaman yalnız değildir: müşterinin bir şirketi, şirkette birkaç kişi ve onların farklı hakları vardır.

Gereksiz görünse bile hemen kurulmaya değer olanlar:

• "Şirket hesabı" ile "kullanıcı" ayrımı. Bunu sonradan değiştirmek veri modelini ve tüm sorguları yeniden yazmak demektir. Başlangıçta her şirkette bir kişi olsa bile organizasyon varlığı var olmalıdır.
• Meslektaşları e-postayla davet etmek. Bu olmadan ürün müşterinin içinde büyümez — ve SaaS genellikle tam olarak böyle büyür.
• En az iki rol: sahip ve üye. Ayrıntılı yetki sistemi ertelenebilir ama veri silme ve paket değiştirme hakkı herkeste olmamalıdır.
• Şifre kurtarma ve e-posta değiştirme. Sıkıcı ama bunlar olmadan destek ekibi bunları veritabanında elle yapmaya başlar.

Ertelenebilecekler: dış servislerle giriş, kurumsal müşteriler için tek oturum açma, iki faktörlü kimlik doğrulama, etkinlik günlüğü. Bunların hepsi hazır kullanıcı modelinin üzerine yeniden yapım gerektirmeden eklenir.

Paketler, deneme süresi, faturalandırma

Fiyat modeli koda pazarlamadan daha çok etki eder, bu yüzden lansmana kadar değil, geliştirmeden önce belirlenmelidir.

Kilit soru: neye para alıyoruz. Seçenek azdır ve ürüne farklı biçimlerde oturur.

1. Kullanıcı başına. Hesaplaması en kolay, müşteri için anlaşılır, ama meslektaş davet etmeyi cezalandırır — oysa tam olarak istediğiniz şey budur.
2. Hacme göre. Kayıt, proje, talep sayısı. İlk günden üründe sayaçlar gerektirir: geriye dönük sayılamaz.
3. Özellik setine göre. Bu durumda kodda bir özelliğin pakete göre kullanılabilirliğini kontrol eden denetimler belirir ve bunlar ekranlara dağıtılmak yerine tek bir yerde yapılmalıdır.

Model ne olursa olsun ilk sürümde şunlar olmalıdır: paket sınırının kendisi, sınıra ulaşıldığında anlaşılır davranış ve üst pakete geçiş. Hiçbir yerde tetiklenmeyen bir sınır paket değil, sitedeki bir yazıdır.

Deneme süresi. Son günde ne olacağına önceden karar verin. Veriler dondurulup ödeme mi bekleniyor? Bir süre sonra mı siliniyor? Hesap kısıtlı özelliklerle ücretsiz pakete mi geçiyor? Bu küçük bir ayrıntı değildir: erişim mantığı ve müşteriye giden e-postalar yanıta bağlıdır. Yanıt olmadığında süresi dolmuş hesaplar sonsuza kadar yaşar ve elle kapatılır.

Ödeme. İlk sürümde tek bir ödeme alma yöntemi ve tek para birimi yeterlidir. Gerçekten hemen gereken, başarısız tahsilatın ve tekrar denemelerin doğru işlenmesi ile, kurumsal müşterilerle çalışıyorsanız onlar için fatura belgeleridir. Karmaşık şemalar — ay ortasında paket değişikliğinde oransal hesaplama, promosyon kodları, ortaklık ödemeleri — rahatlıkla ertelenir.

Müşteri verilerinin yalıtımı

Hatanın bir güncellemeyle düzeltilemediği kısım burasıdır. SaaS'ta farklı şirketlerin verileri tek bir sistemde durur ve onları ayıran tek şey kodunuzdur.

SaaS'ta bir müşterinin verilerinin diğerine sızması bir hata değil, ürünün sonudur. Yalıtım iş mantığının ilk satırından önce tasarlanmalıdır.

Pratik asgari:

• Müşteri verisi içeren her tabloda bir organizasyon kimliği vardır ve bu isteğe bağlı değildir.
• Organizasyon filtresi her sorguya elle eklenmez, sorgunun altına inemeyeceği bir seviyede uygulanır. Elle disiplin burada işe yaramaz: er ya da geç bir sorgu filtresiz yazılır.
• Haklar sunucuda kontrol edilir. Arayüzde gizlenmiş bir düğme hiçbir şeyi korumaz.
• Nesne kimlikleri ardışık sayılar olmamalıdır: adresteki sayıyı bir sonrakiyle değiştirmek meraklı bir kullanıcının ilk yaptığı şeydir.
• Müşterilerin yüklediği dosyalar veritabanı kayıtlarıyla aynı ayrımla saklanır ve doğrudan, tahmin edilebilir bir bağlantıyla sunulmaz.

Silme konusunu da hemen çözmek gerekir: müşteri ayrıldığında ne olur. Veriler tamamen silinir, sınırlı bir süre saklanır ya da talep üzerine ona aktarılır. Kendi verilerini alabilmek aynı zamanda bir satış argümanıdır. Çevreleyen çember — yedekler, izleme, güncellemeler — güvenlik bölümünde ele alınıyor.

Ürünün parçası olarak destek ve güncellemeler

SaaS'ı özel yazılım geliştirmeden ayıran şey herkesin aynı sürümü kullanması ve bu sürümün size ait olmasıdır. Bu hayatı kolaylaştırır ve yükümlülükler ekler.

• Destek kanalı. E-posta veya arayüz içi sohbet. Önemli olan, talebin görüleceği yere düşmesi ve müşterinin ne zaman yanıt bekleyeceğini bilmesidir.
• Gözlemlenebilirlik. Günlükler, çökme uyarıları, hata takibi. Bunlar olmadan bir arızayı müşteriden öğrenirsiniz — hem de ilk karşılaşandan değil, en sabırlısından.
• Kesintisiz yayına alma. Güncellemeler sıktır ve hiçbiri müşterilerin çalışmasını durdurmamalıdır. Bu, sürüm takviminin değil mimarinin gereksinimidir.
• Geri yüklenerek doğrulanmış yedekler. Sistemin hiç ayağa kaldırılmadığı bir yedek, yedek değil varsayımdır.
• Değişiklik notları. Neyin değiştiğinin kısa listesi. Ürünün yaşadığını göstermenin ucuz bir yolu.

Kendi ekibiniz için yönetim paneli de ilk sürüme aittir: hesabı bulmak, paketine bakmak, deneme süresini uzatmak, erişimi kapatmak. O olmadan her talep veritabanına bir ziyarete dönüşür.

Güvenle ertelenebilecekler

Çalışan bir temelin üzerine eklenen ve veri modelinin yeniden yapılmasını gerektirmeyen her şey ertelenebilir:

• mobil uygulama — duyarlı arayüz başlangıcı karşılar;
• herkese açık API ve dış servislerle entegrasyonlar;
• ürün içi gelişmiş analitik — temel rakamlar yeterlidir;
• müşteriye özel ayarlar: kendi alan adı, logo, özel alanlar;
• ilk müşteriler tek dil konuşuyorsa çok dillilik;
• pazarlama otomasyonu ve karmaşık e-posta hunileri.

Bu listede neyin olmadığına dikkat edin: veri yalıtımı, roller, kullanım ölçümü, yedekler. Bunlar temeldir ve canlı müşterilerin altında tamamlamak, baştan yapmaktan daha pahalıdır.

Geliştirmeye başlamadan önce kontrol listesi

1. Müşterinin sizin katılımınız olmadan baştan sona geçtiği tek bir uçtan uca senaryo tanımlandı.

2. Neye para alındığına karar verildi ve üründe bu değerin sayacı var.

3. Deneme süresinin son günündeki ve başarısız ödemedeki davranış tarif edildi.

4. Veri modeli baştan yalnızca kullanıcıyı değil organizasyonu da biliyor.

5. Müşteri verilerinin yalıtımı geliştirici disipliniyle değil, veritabanı erişimi seviyesinde yapılmış.

6. Destek için bir iç panel ve müşterilerin yazdığı bir kanal var.

7. Yedekler var ve onlardan geri yükleme en az bir kez test edildi.

8. ve 2. maddelerin yanıtları belirsizse geliştirmeye başlamak için erkendir: ürünün temeline hangi sayaçların ve sınırların gömüleceğini tam olarak onlar belirler. Bu tür projeleri aşamalara nasıl ayırdığımız SaaS geliştirme bölümünde.