Kısa cevap
Bir SaaS ürünü geliştirirken en baştan karar verilmesi gereken beş konu vardır: çoklu kiracı (multi-tenant) veri modeli, kimlik doğrulama ve rol yetkileri, abonelik ve ödeme akışı, e-Fatura dahil faturalama, ölçekleme ve izleme. Bu kararlar sonradan değiştirilebilir ama pahalıdır. İlk sürümde hepsini en basit sağlam haliyle kurmak, sonraki büyümeyi kolaylaştırır.
SaaS (Software as a Service), yazılımın müşterinin bilgisayarına kurulmak yerine internet üzerinden abonelikle kullanıldığı iş modeli demektir. Müşteri lisans satın almaz; kullandığı süre, kullanıcı sayısı ya da cihaz sayısı kadar öder, güncellemeler ve altyapı sağlayıcının sorumluluğundadır.
Biz kendi SaaS ürünlerimizi de geliştiriyoruz: Assisto Signage TV başına abonelikle çalışan bir dijital tabela yazılımı, AssistoOne ise küçük ekipler için görev, proje ve zaman takibi. Bu yazıda bu ürünlerde ve müşteri projelerinde karşılaştığımız temel mimari kararları anlatıyoruz.
SaaS ürününde ilk hangi kararlar verilmeli?
Bir SaaS ürününe kod yazmaya başlamadan önce iş modelini teknik kararlara çevirmek gerekir. "Kim öder, neye göre öder, ne zaman öder?" sorularının cevabı veritabanı tasarımını doğrudan etkiler.
- Kiracı kim? Bir şirket mi, bir şube mi, bir kişi mi? Bir kullanıcı birden fazla kiracıya üye olabilecek mi?
- Ücretlendirme birimi ne? Kullanıcı başına, cihaz başına, kullanım miktarına göre ya da sabit paket.
- Deneme süresi olacak mı? Kart bilgisi alınarak mı, alınmadan mı?
- Paketler arası fark nasıl uygulanacak? Özellik açma kapama mı, limit mi?
- Veri nerede tutulacak? Türkiye'de mi, yurt dışında mı? Bu karar KVKK açısından da önem taşır.
Ürün henüz doğrulanmadıysa kapsamı daraltmak için MVP rehberimize de göz atabilirsiniz.
Çoklu kiracı mimarisi nedir?
Çoklu kiracı (multi-tenant) mimari, tek bir uygulama kurulumunun birden fazla müşteriye hizmet verdiği ve her müşterinin verisinin diğerlerinden yalıtıldığı yapıdır. Üç yaygın yaklaşım vardır:
| Yaklaşım | Nasıl çalışır? | Artısı | Eksisi |
|---|---|---|---|
| Ortak tablo, kiracı kolonu | Her satırda tenant_id bulunur |
Basit, ucuz, tek göç (migration) | Yalıtım tamamen koda ve sorgulara bağlı |
| Kiracı başına şema | Aynı veritabanında her kiracıya ayrı şema | Daha güçlü ayrım | Şema sayısı arttıkça göç ve bakım zorlaşır |
| Kiracı başına veritabanı | Her müşteriye ayrı veritabanı | En güçlü yalıtım, kurumsal müşteriye uygun | Maliyet ve operasyon yükü yüksek |
Küçük ve orta ölçekli SaaS ürünlerinin çoğu için ortak tablo modeli yeterlidir. Burada en büyük risk, bir sorguda kiracı filtresinin unutulup başka müşterinin verisinin görünmesidir. Bu riski azaltmak için:
- Kiracı filtresini her sorguya elle yazmak yerine veri erişim katmanında otomatik ekleyin.
- PostgreSQL kullanıyorsanız satır düzeyi güvenlik (Row Level Security) ile veritabanı katmanında ikinci bir kilit kurun.
- Otomatik testlere "A kiracısı B kiracısının verisini göremez" senaryolarını ekleyin.
Kimlik doğrulama ve yetkilendirme nasıl kurulur?
SaaS ürünlerinde iki ayrı soru vardır: "Bu kişi kim?" (kimlik doğrulama) ve "Bu kişi bu kiracıda ne yapabilir?" (yetkilendirme). İkincisi genellikle daha çok iş çıkarır.
Pratik bir başlangıç modeli şöyledir:
- Kullanıcı bir kez kaydolur, e-posta ve parola ya da Google gibi bir kimlik sağlayıcıyla giriş yapar.
- Üyelik tablosu kullanıcıyı bir kiracıya bağlar ve rolünü tutar (sahip, yönetici, üye, salt okunur).
- Yetki kontrolü her istekte kiracı ve rol üzerinden yapılır; arayüzde bir düğmenin gizlenmesi güvenlik sayılmaz, kontrol sunucuda olmalıdır.
Kurumsal müşteriler zamanla tek oturum açma (SSO), iki adımlı doğrulama ve erişim kayıtları isteyecektir. Bunları ilk günden kurmak gerekmez ama veri modelinin bunlara yer bırakması gerekir.
Abonelik ve ödeme altyapısı nasıl çalışır?
Abonelik sistemi, kart bilgisinin güvenli şekilde saklanıp her dönem başında otomatik çekim yapılmasına dayanır. Kart verisini kendi sunucunuzda tutmak, ödeme kartı güvenlik standardı (PCI DSS) yükümlülüklerini üstlenmek demektir. Bu yüzden kart bilgisi doğrudan ödeme kuruluşuna gönderilir, sizin sisteminizde yalnızca o kuruluşun verdiği bir anahtar (token) tutulur.
Türkiye'de kurulu bir şirket için seçenekler genellikle bankaların sanal POS hizmetleri ve abonelik ya da kart saklama özelliği sunan lisanslı ödeme kuruluşlarıdır. Seçim yaparken bakılacak noktalar:
- Tekrarlayan çekim ve kart saklama desteği
- Başarısız ödemede yeniden deneme ve bildirim (webhook) altyapısı
- 3D Secure akışının abonelik başlangıcında nasıl işlediği
- Yurt dışı müşteriye döviz ile satış yapılıp yapılamayacağı
Abonelik durum makinesi
Abonelik bir durum makinesi gibi modellenmelidir: deneme, aktif, ödeme gecikti, askıda, iptal edildi. Her geçişin bir tetikleyicisi (ödeme başarılı, ödeme başarısız, kullanıcı iptal etti) ve bir sonucu (özellik kısıtlaması, bilgilendirme e-postası) vardır. Bu yapı netleşmeden yazılan ödeme kodu, kenar durumlarda müşteriye yanlış fatura kesilmesine yol açar.
SaaS faturalama ve e-Fatura entegrasyonu
Ödeme alınması ile faturanın kesilmesi ayrı işlerdir. Türkiye'de satış yaptığınız müşteri e-Fatura mükellefiyse e-Fatura, değilse genellikle e-Arşiv Fatura düzenlenir. Bu belgeleri doğrudan Gelir İdaresi Başkanlığı sistemine bağlanarak ya da özel entegratör aracılığıyla oluşturmak mümkündür.
SaaS ürününde faturalama akışı şu adımları içerir:
- Müşterinin fatura bilgilerini (unvan, vergi dairesi, vergi numarası ya da T.C. kimlik numarası, adres) kayıtta ya da ilk ödemede alın.
- Başarılı ödeme bildirimi geldiğinde fatura taslağını otomatik oluşturun.
- Entegratör ya da GİB servisi üzerinden belgeyi düzenleyin ve müşteriye e-posta ile iletin.
- Faturayı ürün içinde "Faturalarım" ekranında da gösterin.
Hangi belge türünün size uyduğu ve mükellefiyet eşikleri mevzuata göre değiştiği için güncel bilgiyi GİB'in e-Belge sitesinden kontrol etmek ve mali müşavirinizle teyit etmek gerekir.
SaaS ürünü nasıl ölçeklenir?
Ölçekleme sorunu çoğu SaaS ürününde beklenenden geç gelir. İlk aşamada tek bir sunucu ve yönetilen bir veritabanı çoğu zaman yeterlidir. Erken optimizasyon yerine şu temelleri sağlam kurmak daha değerlidir:
- Durumsuz uygulama sunucusu: Oturum bilgisini sunucu belleğinde değil, veritabanında ya da önbellekte tutmak, ileride sunucu sayısını artırmayı kolaylaştırır.
- Arka plan işleri: E-posta, rapor, dışa aktarma gibi uzun işleri bir iş kuyruğuna taşıyın.
- İzleme ve uyarılar: Hata oranı, yanıt süresi ve veritabanı yükü için baştan bir izleme kurun.
- Yedekleme ve geri dönüş: Günlük yedek yetmez; yedekten geri dönmeyi de düzenli deneyin.
Altyapı seçiminin ayrıntıları için sunucu ve veritabanı seçimi rehberimize bakabilirsiniz.
Hangi SaaS metrikleri takip edilmeli?
Teknik altyapı kadar, ürünün sağlığını gösteren metrikleri de baştan ölçebilecek şekilde kurmak gerekir. Bu veriler sonradan geriye dönük toplanamaz.
| Metrik | Ne anlatır? | Nereden hesaplanır? |
|---|---|---|
| MRR (aylık yinelenen gelir) | Her ay düzenli gelen abonelik geliri | Aktif abonelikler |
| Churn (kayıp oranı) | Belirli dönemde aboneliğini bırakan müşteri payı | Abonelik durum geçişleri |
| Aktivasyon | Kaydolanların ürünün asıl değerine ulaşma oranı | Ürün içi olaylar |
| Denemeden ücretliye geçiş | Deneme kullanıcılarının ödeme yapan müşteriye dönme oranı | Abonelik kayıtları |
| Destek talebi yoğunluğu | Ürünün nerede zorladığı | Destek sistemi |
Bu metriklerin anlamlı olması için abonelik değişikliklerinin (paket yükseltme, düşürme, iptal) tarih damgasıyla ayrı bir tabloda tutulması gerekir.
SaaS geliştirirken KVKK'da nelere dikkat edilmeli?
SaaS sağlayıcısı, müşterilerinin sisteme girdiği kişisel veriler açısından çoğunlukla veri işleyen konumundadır; kendi müşteri hesaplarının bilgileri açısından ise veri sorumlusudur. Bu ayrımı sözleşmelerde ve aydınlatma metinlerinde netleştirmek gerekir. Sunucular yurt dışındaysa KVKK'nın 9. maddesindeki yurt dışı aktarım şartları da devreye girer. Konuyu ayrıntılı olarak KVKK uyumlu yazılım geliştirme yazımızda ele aldık.
SaaS ürün geliştirme yaklaşımımızı SaaS hizmet sayfamızda bulabilirsiniz.
Sık sorulan sorular
SaaS ile klasik lisanslı yazılım arasındaki fark nedir?
Klasik lisanslı yazılımda müşteri yazılımı satın alıp kendi bilgisayarına ya da sunucusuna kurar, güncellemeleri kendisi yapar. SaaS'ta yazılım sağlayıcının altyapısında çalışır, müşteri tarayıcı ya da uygulama üzerinden erişir ve dönemsel ücret öder. Bakım, yedekleme ve güncelleme sorumluluğu sağlayıcıdadır.
Çoklu kiracı mimarisi için hangi yaklaşımı seçmeliyim?
Çoğu yeni SaaS ürünü için ortak tablo ve kiracı kolonu modeli yeterli ve en ekonomik yoldur. Müşterileriniz sözleşmeyle ayrı veritabanı ya da ayrı sunucu talep ediyorsa kiracı başına veritabanı modeli düşünülebilir. Karma yapı da mümkündür: küçük müşteriler ortak yapıda, büyük kurumsal müşteriler ayrı veritabanında.
Abonelik ödemelerinde kart bilgisini kendi veritabanımda saklayabilir miyim?
Teknik olarak mümkün olsa da önerilmez, çünkü bu durumda PCI DSS standardının ağır yükümlülüklerini üstlenirsiniz. Doğru yöntem, kart bilgisini doğrudan ödeme kuruluşuna gönderip sisteminizde yalnızca kuruluşun verdiği token'ı saklamaktır. Böylece kart verisi hiçbir zaman sizin sunucunuza dokunmaz.
SaaS ürününde e-Fatura zorunlu mu?
Türkiye'de yapılan satışlarda fatura düzenleme yükümlülüğü vardır; belgenin e-Fatura mı, e-Arşiv Fatura mı olacağı karşı tarafın mükellefiyet durumuna ve sizin yükümlülüğünüze göre değişir. Güncel eşik ve kurallar GİB'in e-Belge sitesinde yayımlanır. Mali müşavirinizle birlikte belirleyip faturalamayı otomatik hale getirmek en sağlıklı yoldur.
SaaS ürününün ilk sürümü ne kadar kapsamlı olmalı?
İlk sürüm, tek bir müşteri sorununu uçtan uca çözecek kadar kapsamlı olmalıdır. Kiracı yalıtımı, güvenli giriş, ödeme ve yedekleme ilk günden sağlam kurulmalı; gelişmiş raporlar, entegrasyonlar ve SSO gibi özellikler müşteri talebine göre sonraki sürümlere bırakılabilir.
Kaynaklar
AssistoTech Ekibi
İstanbul'da web, mobil, masaüstü, oyun, SaaS ve kurumsal yazılım geliştiren ekibiz. Bu yazı, kendi ürünlerimizde ve müşteri projelerinde edindiğimiz deneyime dayanır. Projeniz için bize yazın.
