SaaS Ürünü Geliştirmeden Önce Verilmesi Gereken 12 Karar

Kısa özet: Başarılı bir SaaS ürünü yalnızca iyi koddan oluşmaz. Hedef müşteri, çözülen problem, MVP kapsamı, kullanıcı rolleri, abonelik modeli, tenant mimarisi, veri sahipliği, güvenlik, entegrasyonlar, destek ve bakım modeli geliştirme başlamadan önce belirlenmelidir. Bu kararlar ertelendiğinde proje maliyeti büyür ve ürün, satışa hazır olmadan teknik olarak tamamlanmış görünebilir.

Kısa doğrudan cevap

SaaS ürünü geliştirmeden önce “hangi teknoloji kullanılacak?” sorusundan daha önemli 12 karar vardır: ürünün kime hizmet edeceği, hangi problemi çözeceği, ilk sürümün kapsamı, web veya mobil önceliği, kullanıcı ve şirket yapısı, çok kiracılı mimari, fiyatlandırma, ödeme sistemi, veri sahipliği, entegrasyonlar, güvenlik seviyesi ve ürünün nasıl işletileceği. Bu kararlar geliştirme sürecinin başında verilmezse aynı özellik birkaç kez yeniden yazılabilir. Örneğin kullanıcı yapısının sonradan şirket hesaplarına dönüştürülmesi, sabit abonelik sistemine kullanım bazlı faturalandırma eklenmesi veya tek müşterili mimarinin çok kiracılı hale getirilmesi yalnızca arayüz değişikliği değildir; veri modelini, yetkilendirmeyi, raporlamayı ve operasyon altyapısını etkiler.

SaaS ürünü geliştirmek neden normal bir yazılım projesinden farklıdır?

Bir işletme için özel geliştirilen yazılım genellikle belirli bir şirketin kullanıcılarını, süreçlerini ve kurallarını destekler. SaaS ürünü ise aynı sistemi birbirinden bağımsız çok sayıda müşteri veya organizasyonun kullanabilmesini gerektirir. Bu fark aşağıdaki alanları doğrudan etkiler:

• Kullanıcı ve şirket hesapları
• Verilerin müşteriler arasında ayrılması
• Abonelik ve ödeme
• Paket ve kullanım limitleri
• Müşteri onboarding süreci
• Ürün içi yetkilendirme
• Destek
• İzleme ve raporlama
• Ölçeklenme
• Veri dışa aktarma
• Müşteri kaybı ve hesap kapatma
• Güncelleme yönetimi

AWS, SaaS sistemlerinde tenant isolation konusunu temel mimari başlıklardan biri olarak tanımlar. Paylaşımlı altyapının operasyonel ve maliyet avantajı sağlarken her müşterinin diğer müşterilerin kaynaklarına erişmesini engelleyecek açık bir izolasyon modeli gerektirdiğini belirtir. Bu nedenle bir SaaS projesinde yalnızca ilk ekranların ve temel özelliklerin tanımlanması yeterli değildir. Ürünün nasıl satılacağı, işletileceği ve büyütüleceği de teknik tasarımın parçasıdır.

Karar 1 — Ürün tam olarak kimin hangi problemini çözüyor?

SaaS projesi başlamadan önce cevaplanması gereken ilk soru şudur: Hangi kullanıcı, hangi işi bugün nasıl yapıyor ve ürün bu işi nasıl daha iyi hale getirecek? “Firmalar için CRM”, “sektöre özel yönetim sistemi” veya “AI destekli platform” gibi tanımlar geliştirme kapsamı oluşturmak için yeterli değildir.

Daha somut bir problem tanımı

Zayıf tanım: Denizcilik firmalarının işlerini kolaylaştıran bir SaaS platformu. Daha güçlü tanım: Türkiye limanlarında maliyet teklifi hazırlayan acentelerin, tarife kalemlerini Excel ve PDF dosyalarından elle birleştirme süresini azaltan; teklif, onay ve raporlama sürecini tek panelde yöneten platform. İkinci tanım şu kararları kolaylaştırır:

• İlk kullanıcı kim?
• Hangi veri sisteme girilecek?
• Hangi çıktı üretilecek?
• Hangi işlemin süresi azaltılacak?
• İlk sürümde hangi özellik gerekli?
• Ürünün değeri nasıl ölçülecek?
• Müşteri neden ödeme yapacak?

Hedef müşteri tek bir başlık olmamalıdır

“B2B şirketler” çok geniş bir hedef kitledir. Şunlar ayrılmalıdır:

• Şirket büyüklüğü
• Sektör
• Karar verici
• Ürünü günlük kullanacak kişi
• Mevcut çözüm
• Satın alma bütçesi
• Satış döngüsü
• Regülasyon ihtiyacı
• Kullanıcı sayısı
• Operasyon hacmi

Örneğin ürünü satın alan kişi şirket sahibi olabilir; ancak ürünü her gün operasyon ekibi kullanabilir. Satın alma mesajı ve ürün deneyimi aynı kişiye göre tasarlanmamalıdır.

Bu karar verilmezse ne olur?

• Özellik listesi sürekli büyür.
• Her müşteri talebi ürün yönünü değiştirir.
• Pazarlama mesajı belirsiz kalır.
• Demo sırasında ürünün değeri anlatılamaz.
• Kullanıcılar çok sayıda özellik görür fakat temel işini tamamlayamaz.
• Fiyatlandırma gerçek değer yerine rakiplere göre belirlenir.

Karar 2 — Ürün gerçekten SaaS mı, yoksa tek müşteriye özel yazılım mı?

Her internet üzerinden kullanılan yazılım SaaS değildir. Bir ürünün SaaS olarak ölçeklenebilmesi için aynı çekirdek ürünün çok sayıda müşteriye sunulabilmesi gerekir.

SaaS’a uygun yapı

• Müşterilerin temel problemi benzerdir.
• Ürünün çekirdek akışı standartlaştırılabilir.
• Müşteriye özgü ihtiyaçlar ayarlarla yönetilebilir.
• Yeni müşteri için ayrı kod tabanı açılması gerekmez.
• Güncellemeler bütün müşterilere ortak biçimde sunulabilir.
• Onboarding süreci tekrarlanabilir.
• Fiyatlandırma paketlenebilir.

Özel yazılıma kayan yapı

• Her müşteri için farklı iş akışı yazılıyorsa
• Her satış yeni bir entegrasyon projesine dönüşüyorsa
• Müşteri başına ayrı kaynak kod tutuluyorsa
• Güncellemeler müşteriye göre farklılaşıyorsa
• Ürünün ortak çekirdeği sürekli bozuluyorsa
• Satış gelirinin büyük bölümü kurulum ve özel geliştirmeden geliyorsa

ürün, SaaS’tan çok ürünleştirilmiş hizmet veya özel yazılım modeline yaklaşabilir. Bu durum mutlaka kötü değildir. Ancak maliyet ve büyüme modeli farklıdır.

Karar sorusu

Müşterilerin yüzde 80’inin kullanacağı ortak ürün nedir; yalnızca belirli müşterilere özel kalan yüzde 20 nasıl yönetilecek? Özel ihtiyaçlar için üç seçenek bulunabilir:

• Ürün ayarı veya özellik bayrağı
• Ücretli entegrasyon ya da eklenti
• Ürün kapsamı dışında özel geliştirme

Bu ayrım yapılmazsa satış ekibi her talebe “yapabiliriz” derken ürün ekibi tek bir müşteriye bağlı hale gelebilir.

Karar 3 — MVP’de ne olacak, ne olmayacak?

MVP, yarım çalışan veya kalitesiz ürün anlamına gelmez. MVP; belirli bir hedef kullanıcının belirli bir problemi baştan sona çözebildiği en küçük ürün kapsamıdır.

MVP’de bulunması gerekenler

• Temel kullanıcı akışı
• Gerekli kullanıcı rolleri
• Veri kaydetme ve görüntüleme
• Güvenli giriş
• Kritik işlem geçmişi
• Temel hata yönetimi
• Gerekli bildirimler
• Minimum raporlama
• Yedekleme ve izleme
• Kullanıcı desteği için gerekli yönetim ekranı

MVP’de ertelenebilecekler

• Çok sayıda tema
• Ayrıntılı kişiselleştirme
• Her raporun PDF ve Excel çıktısı
• Bütün üçüncü taraf entegrasyonlar
• Karmaşık AI özellikleri
• Gelişmiş otomasyon kuralları
• Her platform için ayrı mobil uygulama
• Çok sayıda fiyat paketi
• Düşük öncelikli yönetim raporları

Kapsam belirleme yöntemi

Her özellik için şu dört soru sorulmalıdır:

MVP başarı metriği

MVP’nin başarı ölçütü “yazılım tamamlandı” olmamalıdır. Örnek başarı ölçütleri:

• İlk iş sonucuna ulaşan kullanıcı oranı
• Onboarding tamamlanma oranı
• İlk hafta aktif kullanıcı oranı
• Denemeden ücretli pakete geçiş
• Temel işlemin tamamlanma süresi
• Manuel iş yükündeki azalma
• Kullanıcının ürüne geri dönme oranı
• Destek talebi sayısı
• Ürünü bırakma nedeni

Karar 4 — Önce web uygulaması mı, mobil uygulama mı geliştirilecek?

Bir SaaS fikrinin mobil cihazda kullanılacak olması, ilk günden native mobil uygulama gerektirdiği anlamına gelmez.

Web uygulamasıyla başlamak mantıklı olabilir

• Kullanıcılar masa başında çalışıyorsa
• Büyük tablo ve raporlar kullanılıyorsa
• Karmaşık veri girişi yapılıyorsa
• Ürün şirket içi operasyon paneliyse
• MVP hızlı doğrulanmak isteniyorsa
• Tek kod tabanıyla daha hızlı ilerlemek isteniyorsa
• Mobilde temel görüntüleme yeterliyse

Mobil uygulama öncelikli olabilir

• İşlem sahada yapılıyorsa
• Kamera, konum, Bluetooth veya sensör gerekiyorsa
• Anlık bildirim ürünün temel değeriyse
• Kullanıcı işlemi hareket halindeyken tamamlıyorsa
• Çevrim dışı kullanım gerekiyorsa
• Mobil kullanım sıklığı masaüstünden yüksek olacaksa
• App Store veya Google Play dağıtımı satış modeli için önemliyse

Melez yaklaşım

Birçok B2B SaaS ürünü için doğru yapı şu olabilir:

• Yönetim ve ayrıntılı işlem: web
• Bildirim ve hızlı onay: mobil
• Raporlama ve ayarlar: web
• Saha veri girişi: mobil

İlk sürümde iki platformu aynı anda geliştirmek geliştirme, test, mağaza yönetimi ve bakım maliyetini artırır. Mobil ürünün yalnızca web uygulamasının küçültülmüş kopyası olmaması gerekir.

Karar sorusu

Kullanıcı hangi işlemi hangi ortamda, hangi cihazla ve ne kadar sürede tamamlayacak?

Karar 5 — Kullanıcılar, şirketler ve roller nasıl yapılandırılacak?

B2B SaaS ürünlerinde yalnızca kullanıcı hesabı yeterli değildir. Genellikle aşağıdaki ilişkiler gerekir: Platform └── Müşteri şirket ├── Şirket yöneticisi ├── Operasyon kullanıcısı ├── Finans kullanıcısı ├── Sadece görüntüleyen kullanıcı └── Dış paydaş veya misafir

Geliştirme başlamadan belirlenmesi gerekenler

• Bir kullanıcı birden fazla şirkete bağlı olabilir mi?
• Bir şirketin birden fazla şubesi olabilir mi?
• Kullanıcı davetini kim gönderebilir?
• Kullanıcı rolünü kim değiştirebilir?
• Rol mü, izin mi kullanılacak?
• Kullanıcı yalnızca kendi oluşturduğu kayıtları mı görür?
• Şirket yöneticisi bütün şirket verisini görebilir mi?
• Dış danışman veya müşteri erişimi olacak mı?
• Birden fazla onay seviyesi var mı?
• Kullanıcı şirket değiştirirse eski kayıtlara erişimi ne olur?
• Hesap kapatıldığında veriler nasıl korunur?

AWS SaaS Lens, tenant bilgisinin kimlik doğrulama ve yetkilendirme modelinde birinci sınıf bir unsur olarak ele alınmasını önerir. Kullanıcının kim olduğu kadar hangi tenant bağlamında işlem yaptığı da güvenlik kararının parçasıdır. OWASP da çok kiracılı sistemlerde tenant bağlamının her istekte doğrulanmasını ve istemciden gelen tenant kimliğine tek başına güvenilmemesini önerir.

En sık yapılan hata

Yetkilendirmeyi yalnızca arayüzde buton gizleyerek yönetmektir. Bir kullanıcının ekranda “Sil” butonunu görmemesi, API üzerinden silme işlemini yapamayacağı anlamına gelmez. Yetki kontrolü her kritik sunucu işleminde yeniden uygulanmalıdır. OWASP, authentication ile authorization kavramlarının ayrı olduğunu ve her erişim kararının uygun biçimde doğrulanması gerektiğini vurgular.

Karar 6 — Tek kiracılı mı, çok kiracılı mı olacak?

SaaS mimarisindeki en önemli kararlardan biri müşterilerin altyapıyı nasıl paylaşacağıdır.

Temel tenancy modelleri

AWS bu modelleri silo, pool ve bridge olarak tanımlar. Microsoft da tenant başına ayrı kaynak, paylaşımlı kaynak veya ikisinin birleşiminden oluşan farklı izolasyon seviyelerinin kullanılabileceğini belirtir.

Tek veri tabanı mı, müşteri başına veri tabanı mı?

Ortak veri tabanı

Avantajları:

• Başlangıç maliyeti düşük olabilir.
• Yeni müşteri açmak daha kolaydır.
• Güncelleme ve raporlama merkezi yürütülebilir.
• Küçük müşteriler için kaynak kullanımı daha verimlidir.

Riskleri:

• Her sorguda tenant filtrelemesi gerekir.
• Hatalı sorgu çapraz müşteri veri sızıntısına yol açabilir.
• Büyük müşteriler diğerlerini etkileyebilir.
• Müşteri bazlı yedekleme ve geri yükleme zorlaşabilir.

Microsoft, müşterilerin aynı veri tabanını paylaştığı yapılarda sorguların başka bir tenant’ın verisini göstermemesinin özellikle güvence altına alınması gerektiğini belirtir; row-level security gibi kontroller bu amaçla kullanılabilir.

Müşteri başına ayrı veri tabanı

Avantajları:

• Daha güçlü veri izolasyonu
• Müşteri bazlı yedekleme
• Büyük müşteriye özel kaynak
• Kurumsal satışlarda daha kolay güvenlik anlatımı

Riskleri:

• Migration ve sürüm yönetimi zorlaşır.
• Operasyon maliyeti artabilir.
• Çok sayıda veri tabanının izlenmesi gerekir.
• Merkezi raporlama zorlaşabilir.

Karar yalnızca bugünkü müşteri sayısına göre verilmemelidir

Şunlar birlikte değerlendirilmelidir:

• Beklenen müşteri sayısı
• Müşteri başına veri hacmi
• Kurumsal müşterilerin izolasyon talebi
• Regülasyon
• Yedekleme ve geri yükleme
• Bölgesel veri saklama
• Raporlama
• Müşteri başına maliyet
• Büyük müşterilerin özel kaynak ihtiyacı
• Gelecekte tenant taşıma ihtimali

Microsoft, müşterilerin paylaşımlı ortamdan kendilerine özel ortama taşınmasının gerekebileceği durumların başlangıçta planlanmasını önerir.

Karar 7 — Ürün nasıl fiyatlandırılacak?

Fiyatlandırma yalnızca satış kararı değildir. Veri modeli, abonelik sistemi, kullanım ölçümü ve raporlama altyapısını doğrudan etkiler.

Yaygın SaaS fiyatlandırma modelleri

Stripe’ın kullanım bazlı faturalandırma yapısı; API çağrısı, işlem süresi veya depolama gibi kullanım verilerinin meter event olarak kaydedilip dönem içinde belirli bir formüle göre toplanmasını destekler.

Fiyatlandırmadan önce cevaplanması gerekenler

• Müşteri hangi değer için ödeme yapıyor?
• Altyapı maliyeti hangi kullanım arttıkça yükseliyor?
• Kullanıcı sayısı gerçek değeri temsil ediyor mu?
• Ücretsiz deneme olacak mı?
• Kredi kartı zorunlu mu?
• Aylık ve yıllık paket olacak mı?
• Paket yükseltme ve düşürme nasıl hesaplanacak?
• Kullanılmayan haklar sonraki aya aktarılacak mı?
• Ücretsiz paket kötüye kullanılabilir mi?
• Kurumsal müşteriye özel fiyat olacak mı?
• Vergi ve para birimi nasıl yönetilecek?
• İade ve iptal politikası nasıl işleyecek?

Paket değişiklikleri basit değildir

Müşteri ay ortasında paket yükselttiğinde:

• Eski paket için kullanılmayan süre
• Yeni paketin kalan dönem ücreti
• Kullanım bazlı kalemler
• Vergi
• Kredi veya promosyonlar

hesaplanmalıdır. Stripe, abonelik değişikliklerinde proration hesaplamasını en karmaşık alanlardan biri olarak tanımlar ve paket değişikliklerinin hemen, sonraki dönemde veya prorationsız uygulanabileceğini açıklar.

Fiyatlandırma sonradan tamamen değiştirilebilir mi?

Değiştirilebilir; ancak mevcut müşterilerin:

• Eski paketleri
• İndirimleri
• Kullanım geçmişi
• Taahhütleri
• Yıllık ödemeleri
• Faturalandırma tarihleri

korunmak zorunda kalabilir. Bu nedenle ilk günden yüzlerce fiyat kuralı oluşturmak da, gelecekte hiç değişmeyecek kadar katı bir yapı kurmak da risklidir.

Karar 8 — Onboarding, deneme ve ödeme akışı nasıl çalışacak?

Bir SaaS ürününün ilk değeri kullanıcı kayıt olduğunda değil, temel iş sonucuna ulaştığında oluşur.

Onboarding soruları

• Kullanıcı kendi kendine kayıt olabilir mi?
• Şirket hesabını kim oluşturur?
• E-posta doğrulaması gerekli mi?
• Şirket bilgileri kayıt sırasında mı alınacak?
• İlk kullanıcı otomatik yönetici mi olacak?
• Ürün boş ekranla mı açılacak?
• Örnek veri gösterilecek mi?
• Kullanıcı ilk işlemi nasıl öğrenecek?
• Demo verisi ile gerçek veri ayrılacak mı?
• Satış ekibi hesabı önceden hazırlayabilir mi?
• Kurumsal müşteride toplu kullanıcı aktarımı olacak mı?
• SSO gerekli mi?

AWS, tenant onboarding sürecini SaaS mimarisinin ayrı bir bileşeni olarak ele alır. Onboarding sırasında tenant kimliği, kullanıcılar, yapılandırmalar ve billing sistemindeki müşteri karşılığı oluşturulabilir.

Ücretsiz deneme kararı

Ücretsiz deneme şu biçimlerde olabilir:

• 7, 14 veya 30 gün
• Kredi kartlı deneme
• Kredi kartsız deneme
• Özellik sınırlı deneme
• Kullanım kotası
• Satış ekibi onaylı pilot
• Ücretsiz ürün paketi

Stripe, deneme sürelerinin sabit aboneliklerde ve kullanım bazlı ürünlerde uygulanabildiğini belirtir.

Deneme kötüye kullanım riski

• Aynı kişi birden fazla hesap açabilir.
• Sahte e-posta hesapları kullanılabilir.
• Yüksek maliyetli işlemler ücretsiz tüketilebilir.
• Promosyon kredileri kötüye kullanılabilir.
• API veya otomasyon özelliği suistimal edilebilir.

Deneme döneminde:

• Kullanım limiti
• E-posta veya telefon doğrulama
• IP ve cihaz kontrolleri
• Kurumsal domain doğrulama
• Riskli özelliklerin sınırlandırılması
• Otomatik hesap kapatma

değerlendirilebilir.

Karar 9 — Verinin sahibi kim ve müşteri ayrıldığında ne olacak?

SaaS ürününde veri sahipliği yalnızca sözleşme maddesi değildir. Teknik olarak dışa aktarma, silme, saklama ve geri yükleme süreçlerini gerektirir.

Başlangıçta belirlenmesi gerekenler

• Müşteri kendi verisinin sahibi mi?
• Platform hangi verileri hizmet geliştirme amacıyla kullanabilir?
• Anonimleştirilmiş kullanım verileri tutulabilir mi?
• Hesap kapandığında veri hemen mi silinir?
• Belirli bir saklama süresi var mı?
• Müşteri verisini hangi formatta dışa aktarabilir?
• Dosyalar da dışa aktarılabilir mi?
• Kullanıcı geçmişi ve audit log dâhil mi?
• Yedeklerdeki veriler ne zaman silinir?
• Yanlışlıkla silinen veri ne kadar sürede geri getirilebilir?
• Kurumsal müşteri yalnızca kendi tenant’ının yedeğini alabilir mi?
• Veri hangi ülkede veya bölgede tutulur?

Avrupa Komisyonu, kişisel verilerin taşınabilirlik hakkı kapsamında yapılandırılmış ve makine tarafından okunabilir biçimde alınabilmesini açıklar. Ayrıca AB Data Act, veri işleme hizmetleri arasında geçişin kolaylaştırılması ve SaaS sağlayıcılarının en azından yaygın, makine tarafından okunabilir bir formatta veri dışa aktarımı sunması yönünde kurallar içerir. AB pazarına hizmet veren ürünlerde güncel yükümlülükler hukuk uzmanıyla ayrıca değerlendirilmelidir.

Veri dışa aktarma özelliği sonradan eklenirse ne olur?

Veri modeli karmaşıklaştıktan sonra export geliştirmek şu problemleri ortaya çıkarabilir:

• Tablo ilişkilerinin anlaşılmaması
• Dosyaların verilerle eşleştirilememesi
• Silinmiş kullanıcıların geçmiş kayıtlarda bulunması
• Audit log’un müşteri verisinden ayrı tutulması
• Ortak verilerin hangi müşteriye ait olduğunun belirlenememesi
• Büyük export işlemlerinin sistemi yavaşlatması

Bu nedenle veri taşınabilirliği ürünün ilk sürümünde kullanıcı ekranında bulunmasa bile mimari karar olarak en başta ele alınmalıdır.

Karar 10 — Hangi entegrasyonlar ürünün çekirdeğinde olacak?

SaaS ürünleri zamanla başka sistemlerle konuşmak zorunda kalır. Yaygın entegrasyonlar:

• Ödeme
• Muhasebe
• CRM
• ERP
• E-posta
• SMS
• WhatsApp
• Depolama
• Elektronik imza
• Harita
• Kimlik doğrulama
• Raporlama
• Webhook
• Mobil bildirim
• Yapay zekâ servisleri

Her entegrasyon için sorulması gerekenler

• Entegrasyon ürün için zorunlu mu?
• Tek bir sağlayıcıya mı bağlı?
• Sağlayıcı değişirse ne olur?
• API limiti var mı?
• Müşteri kendi hesabını mı bağlayacak?
• API anahtarlarını kim saklayacak?
• Bağlantı kesilirse işlem tekrar denenebilir mi?
• Aynı olay iki kez gelirse sistem ne yapar?
• Başarısız işlemler kullanıcıya nasıl gösterilir?
• Entegrasyon maliyeti müşteriye mi yansıtılır?
• Webhook imzası doğrulanacak mı?
• Veri hangi ülkedeki servise gönderiliyor?

API ilk günden gerekli mi?

Kamuya açık API ilk sürümde gerekli olmayabilir. Ancak sistem içindeki modüllerin açık sorumluluklarla tasarlanması gelecekte API oluşturmayı kolaylaştırır. Entegrasyon altyapısında en az şu yetenekler düşünülmelidir:

• Kimlik doğrulama
• Yetkilendirme
• Rate limit
• Idempotency
• Retry
• Webhook doğrulama
• İşlem geçmişi
• Hata kuyruğu
• API versiyonlama

OWASP, API’lerin kendilerine özgü güvenlik riskleri bulunduğunu ve authentication, authorization, veri doğrulama ve kaynak sınırlarının ayrıca ele alınması gerektiğini belirtir.

Karar 11 — Güvenlik, erişilebilirlik ve hizmet seviyesi ne olacak?

“Güvenliği sonra ekleriz” yaklaşımı SaaS ürünlerinde en pahalı kararlardan biri olabilir.

Minimum güvenlik kararları

• Parola politikası
• Çok faktörlü kimlik doğrulama
• Oturum süresi
• Şüpheli giriş kontrolü
• Hesap kurtarma
• Rol ve izin sistemi
• Tenant isolation
• Audit log
• Veri şifreleme
• Secret yönetimi
• Dosya yükleme güvenliği
• Yedekleme
• Güvenlik güncellemesi
• Olay müdahalesi
• Kullanıcı ve yönetici işlemlerinin kaydı

OWASP, çok kiracılı uygulamalarda tenant bağlamının güvenilir kimlik doğrulama verilerinden elde edilmesini, sorguların tenant ile sınırlandırılmasını ve çapraz tenant erişimi için otomatik güvenlik testlerinin kullanılmasını önerir. NIST Secure Software Development Framework ise güvenlik uygulamalarının geliştirme yaşam döngüsüne sonradan eklenmek yerine süreç boyunca entegre edilmesini önerir.

Erişilebilirlik

Ürün:

• Klavye ile kullanılabiliyor mu?
• Form alanlarının etiketleri var mı?
• Hata mesajları anlaşılır mı?
• Renk körlüğü dikkate alınıyor mu?
• Ekran okuyucu temel akışları tamamlayabiliyor mu?
• Mobil dokunma alanları yeterli mi?
• Grafiklerin metinsel karşılığı var mı?

Erişilebilirlik yalnızca mevzuat konusu değildir. Ürünün daha geniş kullanıcı kitlesi tarafından kullanılabilmesini ve kurumsal müşterilerin satın alma kriterlerini karşılamasını etkileyebilir.

Hizmet seviyesi

Aşağıdaki hedefler başlangıçta belirlenmelidir:

• Aylık erişilebilirlik hedefi
• Kritik hata müdahale süresi
• Yedekleme sıklığı
• Recovery Point Objective
• Recovery Time Objective
• Planlı bakım bildirimi
• Destek saatleri
• Enterprise müşteriye farklı SLA
• Veri işleme süresi
• Bildirim ve entegrasyon gecikmesi

Google Cloud, kritik iş yükleri için SLO ve SLA hedeflerinin tanımlanmasını operasyon ekibinin temel sorumlulukları arasında gösterir. SLO; erişilebilirlik veya yanıt süresi gibi istenen hizmet düzeyini ifade eder ve geçmiş ölçümler mimarinin veriyle geliştirilmesini sağlar.

Yüzde 99,9 erişilebilirlik yazmak yeterli değildir

Şunlar da tanımlanmalıdır:

• Ölçüm hangi servis üzerinde yapılacak?
• Planlı bakım hesaplamaya dâhil mi?
• Ayın hangi zaman aralığı esas alınacak?
• Bölgesel cloud kesintisi nasıl ele alınacak?
• Müşterinin internet problemi hizmet kesintisi sayılacak mı?
• SLA ihlalinde kredi veya iade var mı?

Karar 12 — Ürün kim tarafından ve hangi bütçeyle işletilecek?

SaaS geliştirme maliyeti yalnızca ilk sürümün yazılım ücretinden oluşmaz.

İlk geliştirme maliyetleri

• Ürün analizi
• UX ve UI tasarımı
• Frontend
• Backend
• Veri tabanı
• Yönetim paneli
• Ödeme sistemi
• Entegrasyonlar
• Test
• Güvenlik
• Cloud kurulumu
• Veri ve içerik aktarımı
• Mobil uygulama
• Dokümantasyon

Sürekli maliyetler

• Cloud altyapısı
• Veri tabanı
• Depolama
• E-posta ve SMS
• Ödeme komisyonu
• Harici API’ler
• Log ve izleme
• Yedekleme
• Güvenlik taramaları
• Teknik destek
• Hata düzeltme
• Framework ve paket güncellemeleri
• App Store ve Google Play süreçleri
• Yeni özellik geliştirme
• Müşteri desteği
• Satış ve onboarding

AWS SaaS Lens, tenant bazlı kullanım ve tüketim verisinin hem faturalandırma hem de tenant maliyetlerinin anlaşılması için izlenmesini önerir. Altyapı maliyeti, tenant geliri ve kullanılan kaynakların birlikte ölçülmesi kârlılık kararlarını destekler.

Geliştirme maliyetini tahmin etmek için formül

İlk ürün maliyeti = Analiz + tasarım + geliştirme + test + altyapı + entegrasyon + yayın hazırlığı 12 aylık toplam ürün maliyeti = İlk ürün maliyeti + cloud ve üçüncü taraf hizmetler + bakım + müşteri desteği + satış ve onboarding + sonraki sürüm geliştirmeleri

Sahiplik kararları

Proje başlamadan netleştirilmelidir:

• Kaynak kod kime ait?
• GitHub veya GitLab hesabı kimin?
• Cloud hesabı kimin adına?
• Domain kimin hesabında?
• Ödeme sağlayıcısı hesabı kimin?
• App Store ve Google Play hesapları kimin?
• Teknik dokümantasyon teslim edilecek mi?
• Geliştirme ekibi değişirse devir nasıl yapılacak?
• Üçüncü taraf lisanslar kimin adına?
• Veritabanı erişimi kimlerde?
• Production’a kim dağıtım yapabilir?
• Acil durumda kim müdahale edecek?

Ürün sahibi kim olacak?

SaaS projesinin yalnızca yazılım ekibine bırakılması doğru değildir. Bir ürün sahibi şunlardan sorumlu olmalıdır:

• Önceliklendirme
• Müşteri geri bildirimleri
• Kapsam kontrolü
• İş kuralları
• Kabul kriterleri
• Fiyatlandırma
• Lansman
• Ürün metrikleri
• Yol haritası

Ürün sahibi bulunmazsa yazılım ekibi her talebi teknik açıdan yorumlar; fakat hangi talebin ticari olarak önemli olduğuna karar veremez.

12 kararın hızlı özeti

SaaS projesine başlamadan önce kontrol listesi

Ürün ve pazar

• Hedef sektör açıkça belirlendi mi?
• Ürünü satın alacak kişi belli mi?
• Günlük kullanıcı belli mi?
• Çözülen iş problemi tek cümlede anlatılabiliyor mu?
• Kullanıcının mevcut çözümü biliniyor mu?
• Ürünün ölçülebilir faydası tanımlandı mı?
• İlk müşteri segmenti sınırlandırıldı mı?

MVP

• Temel kullanıcı akışı yazıldı mı?
• MVP dışı özellikler ayrıca listelendi mi?
• Kabul kriterleri hazır mı?
• Başarı metrikleri belirlendi mi?
• Demo ile production kapsamı ayrıldı mı?
• Pilot müşteriler belirlendi mi?

Kullanıcı ve tenant yapısı

• Şirket ve kullanıcı ilişkisi tanımlandı mı?
• Roller ve izinler çıkarıldı mı?
• Bir kullanıcının birden fazla şirkete bağlanması değerlendirildi mi?
• Tenant izolasyon modeli seçildi mi?
• Büyük müşteriye özel ortam ihtimali planlandı mı?
• Tenant taşıma senaryosu düşünüldü mü?

Fiyatlandırma ve ödeme

• Fiyatlandırma birimi belirlendi mi?
• Paket limitleri tanımlandı mı?
• Ücretsiz deneme kararı verildi mi?
• Paket yükseltme ve düşürme kuralları tanımlandı mı?
• Kullanım ölçümü gerekiyorsa meter yapısı planlandı mı?
• İptal, iade ve başarısız ödeme süreçleri tanımlandı mı?
• Aylık ve yıllık planlar değerlendirildi mi?

Veri

• Veri sahipliği sözleşmede tanımlanacak mı?
• Veri dışa aktarma formatı belirlendi mi?
• Hesap kapatma ve silme süreci tanımlandı mı?
• Yedekleme süresi belirlendi mi?
• Tenant bazlı geri yükleme ihtiyacı değerlendirildi mi?
• Veri saklama bölgesi kararlaştırıldı mı?

Güvenlik ve operasyon

• MFA ihtiyacı değerlendirildi mi?
• Audit log kapsamı belirlendi mi?
• Yedekleme ve felaket kurtarma planı var mı?
• Kritik olay müdahale süresi belirlendi mi?
• Cloud ve production erişimleri sınırlandırıldı mı?
• SLA ve destek saatleri tanımlandı mı?
• Güvenlik güncelleme sorumlusu belli mi?

Ticari ve operasyonel sahiplik

• Ürün sahibi atandı mı?
• Kaynak kod sahipliği tanımlandı mı?
• Cloud ve domain hesapları şirket kontrolünde mi?
• İlk 12 aylık bakım bütçesi ayrıldı mı?
• Müşteri destek süreci planlandı mı?
• Satış ve onboarding sorumluları belirlendi mi?
• Tedarikçi değişiminde devir planı var mı?

SaaS projesine kimler başlamalı?

Başlamaya daha hazır olanlar

• Tekrarlanan ve ölçülebilir bir sektör problemi bulanlar
• Hedef müşterilerle görüşmüş olanlar
• İlk pilot müşterilere erişebilenler
• MVP kapsamını sınırlandırabilenler
• En az 12 aylık ürün ve bakım bütçesi ayırabilenler
• Ürün sahibi belirleyenler
• Müşteri geri bildirimlerini düzenli toplayabilecek olanlar
• SaaS’ı tek seferlik yazılım projesi olarak görmeyenler

Önce hazırlık yapması gerekenler

• Ürün fikrini yalnızca rakiplerden alanlar
• Hedef müşterisi “her şirket” olanlar
• Bütün özellikleri ilk sürümde isteyenler
• Satış ve pazarlama bütçesi planlamayanlar
• İlk sürümden hemen yüksek kullanıcı sayısı bekleyenler
• Bakım bütçesi ayırmayanlar
• Ürün sahibi belirlemeyenler
• Kaynak kod, cloud ve veri sahipliğini konuşmayanlar
• Teknik ekibin ürünü kendiliğinden yöneteceğini düşünenler

InoviqLab değerlendirmesi

Bu bölüm InoviqLab’ın değerlendirmesidir; resmî teknik kaynaklardaki doğrulanmış bilgilerden ayrıdır. SaaS projelerinde en pahalı hata yanlış teknoloji seçimi değildir. En pahalı hata, ürün kararlarının geliştirme başladıktan sonra verilmesidir. Örneğin:

• Bireysel kullanıcı yapısıyla başlayan ürünün şirket ve şube yapısına dönüştürülmesi
• Sabit paket olarak geliştirilen ürünün kullanım bazlı faturalandırmaya geçirilmesi
• Tek müşterili uygulamanın çok kiracılı SaaS’a çevrilmesi
• Web ürünü tamamlandıktan sonra mobilin temel kanal olduğunun anlaşılması
• Veri dışa aktarma ihtiyacının müşteri ayrılmak istediğinde fark edilmesi
• Yetkilendirmenin yalnızca arayüzde yapılması
• Ürün tamamlandıktan sonra enterprise müşterinin SSO ve audit log istemesi

küçük özellik eklemeleri değildir. Sistemin veri modelini, güvenlik sınırlarını ve operasyon yapısını değiştirir. İkinci önemli hata, MVP’nin yalnızca özellik sayısıyla tanımlanmasıdır. Bir MVP’nin küçük olması gerekir; fakat temel süreci baştan sona güvenilir biçimde tamamlaması gerekir. Giriş ekranı, birkaç form ve gösterge paneli bulunması ürünü MVP yapmaz. Kullanıcı ürüne girdiğinde gerçek bir iş sonucuna ulaşabilmelidir. Üçüncü hata, SaaS geliştirme bütçesinin yalnızca yazılım teklifinden oluştuğunu varsaymaktır. Ürünün çalışması için:

• Hosting
• Veri tabanı
• E-posta
• Ödeme
• İzleme
• Yedekleme
• Müşteri desteği
• Bakım
• Güvenlik güncellemeleri
• Satış
• Onboarding

gibi sürekli maliyetler bulunur. Dördüncü hata, ilk müşterinin bütün ürün yönünü belirlemesine izin vermektir. İlk müşteriler değerlidir; fakat her müşteri talebi ürüne eklenmemelidir. Talebin:

• Başka müşterilerde tekrar edip etmediği
• Ürünün temel değerini güçlendirip güçlendirmediği
• Paketlenebilir olup olmadığı
• Bakım maliyeti
• Mevcut kullanıcıları nasıl etkileyeceği

değerlendirilmelidir. InoviqLab açısından sağlıklı SaaS geliştirme süreci şu sırayla ilerlemelidir:

• Problem ve hedef müşteri doğrulaması
• İş akışı ve ürün analizi
• MVP kapsamı
• Kullanıcı, tenant ve veri modeli
• Fiyatlandırma ve kullanım ölçümü
• UX prototipi
• Teknik mimari
• Geliştirme
• Güvenlik ve test
• Pilot müşteri
• Ölçüm ve geri bildirim
• Kontrollü büyüme

Sonuç

SaaS ürünü geliştirmeye teknoloji seçerek başlanmamalıdır. İlk olarak şu kararlar verilmelidir:

• Ürün kimin hangi problemini çözüyor?
• Çözüm gerçekten tekrarlanabilir bir SaaS ürünü mü?
• İlk sürümde hangi iş akışı tamamlanacak?
• Web ve mobil önceliği ne?
• Kullanıcı, şirket ve rol modeli nasıl çalışacak?
• Müşteri verileri nasıl ayrılacak?
• Ürün nasıl fiyatlandırılacak?
• Onboarding ve ödeme nasıl işleyecek?
• Veri nasıl dışa aktarılacak ve silinecek?
• Hangi entegrasyonlar çekirdek ürüne ait?
• Güvenlik ve hizmet seviyesi ne olacak?
• Ürün geliştirme sonrasında kim tarafından işletilecek?

Bu soruların cevapları net değilse kod yazmaya başlamak projeyi hızlandırmaz. Belirsizliği yazılım katmanına taşıyarak ileride daha pahalı hale getirir. Başarılı SaaS ürünü, çok fazla özelliği bulunan ürün değildir. Başarılı SaaS ürünü: Belirli bir müşteri grubunun önemli bir problemini, güvenilir, tekrarlanabilir ve sürdürülebilir bir iş modeliyle çözen üründür.