SaaS Platform Nasıl Geliştirilir? Teknik Mimari ve İş Modeli Rehberi

Kısaca: SaaS (Software as a Service), yazılımın internet üzerinden abonelikle sunulduğu iş modelidir. Teknik olarak üç zor konu vardır: kiracı izolasyonu (her müşterinin verisi ayrı ve güvende), abonelik ve faturalandırma yaşam döngüsü ve ölçeklenebilir, güvenli işletim. Türkiye'deki ekipler için ek bir gerçek: Stripe, resmî desteklenen ülkeler listesinde Türkiye'yi içermiyor; yerel şirketler genellikle iyzico/PayTR gibi altyapıları veya yurt dışı yapı/“Merchant of Record” çözümlerini değerlendiriyor. Doğru yol; küçük bir MVP ile başlayıp gerçek kullanıcıyla öğrenmek ve mimariyi gereğinden erken karmaşıklaştırmamaktır.

Son güncelleme: Eylül 2026

SaaS nedir, neden özel bir mühendislik alanı?

Notion, Slack, Figma, Shopify gibi ürünler SaaS'tır: kullanıcı kurulum yapmadan tarayıcı veya mobilden ürüne erişir ve aylık ya da yıllık ücret öder. Klasik yazılım projesinden farkı, ürünün binlerce müşteriye aynı anda, sürekli ve güvenli sunulmasıdır. Bu yüzden mimari kararlar (veri izolasyonu, ödeme, güncelleme) ürün ölçeklendikçe geri dönmesi pahalı hâle gelir.

1. Çok kiracılı mimari (multi-tenancy)

Kiracı (tenant), ürünü kullanan müşteri kuruluşudur. Üç yaygın veri izolasyonu yaklaşımı:

Çoğu ürün için paylaşılan şema + satır düzeyinde güvenlik (Row Level Security, RLS) iyi bir başlangıçtır: PostgreSQL'in RLS özelliği, kural veritabanında tanımlandığı için uygulama kodundaki bir hata olsa bile başka kiracının verisinin dönmesini engelleyebilir. Finans, sağlık veya kurumsal müşteri gibi sıkı izolasyon isteyen segmentler için şema/veritabanı bazlı model değerlendirilebilir. Mimari seçeneklerin daha geniş bir çerçevesi için Microsoft'un çok kiracılı çözümler rehberine bakabilirsiniz. Önemli: İzolasyonu testle doğrulayın: “kiracı A kullanıcısı kiracı B verisini görebiliyor mu?” senaryosu otomatik test setinizde bulunmalı.

2. Abonelik ve faturalandırma

Abonelik sistemi, göründüğünden karmaşıktır:

• Planlar ve limitler: Starter/Pro/Enterprise; kullanıcı, depolama, işlem sayısı gibi kotalar.
• Deneme süresi (trial): Kart olsun/olmasın; deneme bitince ne olur?
• Yükseltme/düşürme (upgrade/downgrade) ve orantılı ücret (proration).
• Başarısız ödeme yönetimi (dunning): Kart reddedildiğinde tekrar deneme, bildirim, hizmeti kısıtlama.
• Kullanıma dayalı faturalandırma (kullanım ölçümü, dönem sonu hesabı).
• Webhook'lar: Ödeme sağlayıcının olayları tekrarlanabilir; işlemler idempotent (aynı olay iki kez gelse de tek kez uygulanan) olmalı.
• Fatura ve vergi: Türkiye'de fatura düzenliyorsanız e-Fatura/e-Arşiv kapsamını ve KDV uygulamasını mali müşavirinizle netleştirin (GİB e-Belge duyuruları).

Türkiye'de ödeme altyapısı: Stripe konusunda dürüst tablo

Stripe, SaaS dünyasının standart ödeme altyapısı olsa da Stripe'ın küresel kullanılabilirlik sayfasında Türkiye, işletmenin bulunabileceği ülkeler arasında yer almıyor. Bu yüzden Türkiye'de kurulu bir şirketin doğrudan Stripe hesabı açması beklenmemeli; seçenekler genellikle şunlardır:

1. Yerel sağlayıcılar (iyzico, PayTR vb.): Türk lirası tahsilat, taksit ve yerel banka entegrasyonu için doğal seçim; abonelik/tekrarlı ödeme kabiliyetini ve API kalitesini ayrıca değerlendirin.
2. Yurt dışı şirket yapısı: Küresel pazara satış yapılacaksa yurt dışında kurulan bir şirket üzerinden Stripe gibi sağlayıcılar (hukuki, vergisel ve muhasebe sonuçları için uzman görüşü şart).
3. Merchant of Record (MoR) çözümleri: Satış, vergi ve faturalandırmayı sizin adınıza yürüten aracı kuruluşlar.

Karar; müşterinizin nerede olduğuna, hangi para birimiyle ödeme alacağınıza ve şirket yapınıza bağlıdır. Ödeme sağlayıcısını değiştirmenin maliyetini azaltmak için ödeme katmanını soyutlayın (sağlayıcıya bağımlı olmayan bir abonelik modeli).

3. Kimlik doğrulama ve yetkilendirme

• Kimlik doğrulama: E-posta/şifre + çok faktörlü doğrulama; kurumsal müşteriler için SSO (SAML/OIDC).
• Rol tabanlı yetki (RBAC): Sahip (Owner), yönetici (Admin), üye (Member), izleyici (Viewer) gibi kiracı içi roller; hassas işlemler (faturalama, kullanıcı silme) için ek doğrulama.
• Davet ve ekip üyeliği: Kullanıcıyı kiracıya davet, rol atama, kaldırma.
• Süper yönetici paneli: Sizin (SaaS işletmecisi) tüm kiracıları, abonelikleri ve kullanımı görüp destek verebileceğiniz ayrı ve sıkı korunan bir alan.

4. API-first yaklaşım ve entegrasyonlar

Ürününüzün her işlevi bir API üzerinden sunulursa web, mobil ve dış entegrasyonlar aynı çekirdeği kullanır. Webhook sistemi, müşterilerin kendi sistemlerine olay bildirimi almasını sağlar. API'de sürümleme, hız sınırlaması (rate limiting) ve dokümantasyon baştan planlanmalı.

5. Güvenlik, KVKK ve işletim

• Güvenlik: OWASP Top 10 web güvenlik risklerine karşı kontrol; girdi doğrulama, yetki kontrolü her katmanda, gizli anahtarların yönetimi, bağımlılık güncellemeleri.
• Yedekleme ve olağanüstü durum: Kiracı bazlı geri yükleme senaryosu; yedekten dönüşü gerçekten deneyin.
• Gözlemlenebilirlik: Loglar, metrikler, hata izleme, uyarılar.
• KVKK ve veri konumu: Müşteri verisi işleyen bir “veri işleyen” olarak sözleşme, aydınlatma yükümlülüklerini destekleyen özellikler (silme/dışa aktarma), veri saklama ve yurt dışına aktarım konularını netleştirin. Kurumsal müşteriler güvenlik değerlendirme soru formları isteyecektir.
• Erişim kaydı: Kim, ne zaman, neyi değiştirdi (audit log).

MVP'den ölçeklemeye yol haritası

Faz 1: MVP (yaklaşık 0–3 ay)

Çekirdek değer önerisini çözen en küçük ürün: tek ana iş akışı, basit plan, temel ödeme, birkaç erken kullanıcı. Hedef, mimari mükemmellik değil, öğrenmedir.

Faz 2: Ürün-pazar uyumu (yaklaşık 3–12 ay)

Kullanıcı geri bildirimiyle özellik geliştirme; aktivasyon, elde tutma ve ödeme dönüşümü metriklerini izleme; ikinci fiyat planı; onboarding iyileştirme.

Faz 3: Ölçekleme (12+ ay)

Kurumsal plan ve sözleşmeler, SSO, gelişmiş raporlama, entegrasyon marketi, performans ve maliyet optimizasyonu. Gerektiğinde bazı bileşenleri ayrı servislere bölmek (mikroservis rehberimiz: önce sağlam bir modüler monolit).

SaaS metrikleri

• MRR/ARR: Aylık/yıllık tekrarlayan gelir.
• Churn (kayıp oranı): Bir dönemde ayrılan müşteri veya gelir yüzdesi.
• Aktivasyon oranı: Kayıt olanların değer aldığı noktaya ulaşma yüzdesi (“time-to-value”).
• ARPU / LTV / CAC: Müşteri başına gelir, müşterinin yaşam boyu değeri, müşteri kazanma maliyeti.
• Özellik benimseme ve kullanım: Hangi özellik kullanılıyor, hangisi kullanılmıyor?

Teknoloji seçimi

Tek bir doğru yığın yok; ekip yetkinliği belirleyicidir. Yaygın ve güvenilir bir kombinasyon: Next.js ön yüz, Node.js (NestJS/Fastify) ya da Python arka yüz, PostgreSQL (RLS destekli) veritabanı, Redis önbellek/kuyruk, konteyner tabanlı dağıtım ve bir bulut sağlayıcı. Kimlik doğrulama için olgun bir sağlayıcı veya kütüphane kullanmak, sıfırdan yazmaktan daha güvenlidir. Yapay zekâ özellikleri için (arama, öneri) vektör desteği (ör. pgvector) eklenebilir (RAG rehberi).

Yaygın hatalar

1. Ürün-pazar uyumundan önce mikroservis ve karmaşık altyapı kurmak.
2. Kiracı izolasyonunu testlemeden yayına çıkmak.
3. Ödeme sağlayıcısına bağımlı, soyutlanmamış abonelik mantığı.
4. Onboarding'i ihmal etmek; kullanıcı ilk değeri göremeden ayrılır.
5. Metrik takibi olmadan özellik eklemek.
6. Güvenlik ve yedeklemeyi “sonra” bırakmak.

Aktaş Digital ne sağlıyor?

SaaS Platform Geliştirme hizmetimizde çok kiracılı mimari, abonelik ve ödeme yönetimi, onboarding akışları, süper yönetici paneli ve SaaS analitiğini içeren uçtan uca çözümler geliştiriyoruz. Ödeme altyapısını şirket yapınıza ve hedef pazarınıza göre birlikte seçiyoruz. Fikrinizin kapsamını ve maliyet çerçevesini teklif formundan konuşabiliriz; maliyet mantığı için yazılım maliyeti rehberimize de bakabilirsiniz.

Sık Sorulan Sorular

SaaS ürünü ne kadar sürede geliştirilir?

Kapsama bağlı; çekirdek işlevli bir MVP genellikle haftalar-birkaç ay içinde çıkarılabilir. Asıl süre, kullanıcı geri bildirimiyle ürünü olgunlaştırmaya gider.

Çok kiracılı mimaride hangi model seçilmeli?

Çoğu ürün için paylaşılan şema + RLS ile başlanır; sıkı izolasyon veya özel uyumluluk isteyen kurumsal müşteriler için şema/veritabanı bazlı modele geçiş planlanır.

Türkiye'de kurulu şirket Stripe kullanabilir mi?

Stripe'ın küresel kullanılabilirlik sayfasında Türkiye desteklenen işletme ülkeleri arasında görünmüyor. Yerel sağlayıcılar, yurt dışı şirket yapısı veya MoR çözümleri değerlendirilir; hukuki ve vergisel sonuçlar için uzman görüşü alın.

SaaS için mikroservis gerekli mi?

Genellikle başlangıçta hayır. İyi düzenlenmiş bir modüler monolit, hız ve öğrenme için daha uygundur; ölçek ve ekip büyüdükçe gerekirse bölünür.

KVKK açısından SaaS sağlayıcısı olarak neye dikkat etmeliyim?

Müşteri adına kişisel veri işliyorsanız “veri işleyen” rolünüz ve sözleşmeler, güvenlik önlemleri, veri silme/dışa aktarma ve yurt dışı aktarım konuları netleştirilmelidir.

Sonuç

SaaS geliştirmek, kiracı izolasyonu, abonelik yaşam döngüsü ve güvenli işletim konularını baştan doğru kurmak ve ürünü gerçek kullanıcıyla öğrenerek büyütmektir. Küçük başlayın, izolasyonu test edin, ödeme katmanını esnek tutun ve metriklerle ilerleyin.