SaaS (Software as a Service, hizmet olarak yazılım), kullanıcıların kurulum yapmadan tarayıcı veya uygulama üzerinden eriştiği, genellikle aylık ya da yıllık abonelikle satılan yazılımdır. Müşteri sunucuyla, güncellemeyle ya da yedekle uğraşmaz; bunların hepsi sağlayıcının sorumluluğundadır. Bir iş fikrini SaaS ürününe dönüştürmek isteyenlerin çoğu ekranlara ve özelliklere odaklanır. Oysa bir SaaS ürününü sıradan bir web uygulamasından ayıran şey görünmeyen katmandır: her müşterinin verisini diğerlerinden ayıran çok kiracılı mimari, rollerle çalışan yetkilendirme, planlara bağlı faturalama, yeni müşteriyi kendi kendine kuran onboarding akışı ve müşteri sayısı arttıkça sistemi ayakta tutan ölçekleme stratejisi. Bu rehberde bu beş katmanı, hangi sırayla ele alınması gerektiğiyle birlikte anlatıyoruz.
Bir SaaS ürününü özel yazılımdan ayıran nedir?
Tek bir firma için geliştirilen özel yazılımda müşteri bellidir: süreçleri, kullanıcıları ve verisi tektir. SaaS'ta ise aynı yazılımı yüzlerce farklı firma kullanır. Bu, birkaç temel farkı beraberinde getirir:
- Kiracı kavramı: Her müşteri firma bir kiracıdır (tenant). Kullanıcılar bir kiracıya bağlıdır ve hiçbir koşulda başka bir kiracının verisini görmemelidir.
- Yapılandırma, özelleştirmenin yerini alır: Bir müşteri için kod değiştirmek yerine her müşterinin kendi ayarlarını yapabileceği seçenekler sunulur.
- Kendi kendine hizmet: Müşteri kaydolur, denemeye başlar, ekibini davet eder ve ödeme yapar; bunların hiçbiri sizin elle müdahalenizi gerektirmemelidir.
- Sürekli teslim: Tüm müşteriler aynı sürümü kullanır; bir güncelleme hepsini aynı anda etkiler. Bu da test ve geri dönüş planını kritik hâle getirir.
Fikrinizin SaaS olarak mı yoksa tek bir müşteriye özel çözüm olarak mı ilerlemesi gerektiğine henüz karar vermediyseniz, özel yazılım ve hazır paket karşılaştırmamız bu soruya diğer taraftan bakıyor.
1. Çok kiracılı (multi-tenant) mimari
Çok kiracılı mimari, tek bir uygulama altyapısının birden fazla müşteriye hizmet vermesi ve her müşterinin verisinin mantıksal olarak ayrılmasıdır. Mimariyi seçerken temel soru, kaynakların ne kadarının kiracılar arasında paylaşılacağıdır. Microsoft'un çok kiracılı mimari rehberi bu yelpazeyi tamamen paylaşımlı yapıdan her kiracıya ayrı altyapıya kadar ele alıyor. Pratikte üç veri modeli öne çıkar:
| Model | Nasıl çalışır? | Avantaj | Dezavantaj |
|---|---|---|---|
| Paylaşımlı veri tabanı, paylaşımlı tablolar | Tüm kiracılar aynı tablolarda, her satırda tenant_id sütunu | En düşük maliyet, kolay bakım, tek şema güncellemesi | Ayrımı uygulama katmanı sağlamalı; bir sorgu hatası veri sızıntısı demek |
| Paylaşımlı veri tabanı, kiracıya ayrı şema | Aynı veri tabanında her kiracının kendi şeması | Daha güçlü ayrım, kiracıya özel yedek almak kolay | Şema güncellemeleri tüm şemalara uygulanmalı; kiracı sayısı arttıkça yönetim zorlaşır |
| Kiracıya ayrı veri tabanı | Her kiracının kendi veri tabanı | En güçlü ayrım, kiracı bazında taşıma ve ölçekleme | En yüksek maliyet ve operasyon yükü |
Çoğu yeni SaaS ürünü için paylaşımlı tablolar ve tenant_id modeli en mantıklı başlangıçtır. Riski azaltmak için ayrımı tek bir yerde zorunlu kılın: her sorguya kiracı filtresini otomatik ekleyen bir veri erişim katmanı kullanın ve geliştiricinin bunu unutabileceği yolları kapatın. PostgreSQL kullanıyorsanız satır düzeyinde güvenlik (Row Level Security) ile bu kuralı veri tabanı seviyesinde de uygulayabilirsiniz; politika tanımlanmış bir tabloda, kural izin vermiyorsa satır hiç görünmez. Kurumsal müşterilerin ayrı veri tabanı istediği durumlar için de karma bir yapı kurulabilir: çoğu kiracı paylaşımlı altyapıda, büyük müşteriler kendilerine ayrılmış kaynaklarda.
Mimari kararlarından biri de "gürültülü komşu" sorunudur: bir kiracının ağır raporu ya da toplu veri aktarımı, aynı altyapıyı paylaşan diğerlerini yavaşlatabilir. Uzun süren işleri kuyruğa almak ve kiracı başına kullanım sınırları koymak bu riski azaltır.
2. Kimlik doğrulama ve yetkilendirme
SaaS'ta yetkilendirme iki katmanlıdır: kullanıcının hangi kiracıya ait olduğu ve o kiracı içinde ne yapabildiği. Önerdiğimiz yapı şöyledir:
- Kullanıcı ve üyelik ayrımı: Bir kişi birden fazla kiracıya üye olabilir (örneğin birkaç müşterisi için çalışan bir muhasebeci). Kullanıcı tablosunu üyelik tablosundan ayırın:
uyelikler(kullanici_id, tenant_id, rol). - Rol tabanlı erişim: Sahip, yönetici, üye ve salt okunur gibi birkaç net rolle başlayın. Her rolün neyi yapabildiğini bir yetki listesinde tanımlayın; kodun içine "eğer yöneticiyse" kontrollerini dağıtmayın.
- Her istekte kontrol: Yetki kontrolünü yalnızca arayüzde (butonu gizleyerek) yapmak yeterli değildir; sunucu her istekte kullanıcının o kayda erişim hakkı olup olmadığını doğrulamalıdır. OWASP'ın yetkilendirme rehberi varsayılan olarak erişimi reddetmeyi ve her istekte yetkiyi kontrol etmeyi öneriyor.
- Kurumsal giriş seçenekleri: Büyük müşteriler zamanla Google Workspace veya Microsoft hesabıyla tek oturum açma (SSO) isteyecektir. İlk sürümde gerekmeyebilir, ama kimlik katmanını buna izin verecek biçimde kurmak sonradan büyük bir yeniden yazımı önler.
Denetim kaydı (audit log) da baştan düşünülmesi gereken bir parçadır: kimin, ne zaman, hangi kaydı değiştirdiğini tutmak hem güvenlik olaylarında hem de müşteri destek taleplerinde işe yarar.
3. Abonelik ve faturalama altyapısı
Faturalama, SaaS'ın en çok hafife alınan parçasıdır. "Aylık ücret alırız" cümlesinin arkasında plan tanımları, deneme süreleri, yükseltme ve düşürme, başarısız ödemeler, iptal ve fatura kesimi gibi çok sayıda durum vardır. Bu yapıyı üç kavrama ayırmak işinizi kolaylaştırır:
- Plan ve özellik tanımı: Her plan bir dizi özellik ve sınırdan oluşur: kullanıcı sayısı, kayıt sayısı, depolama, ileri modüller. Bunları kodun içine değil, bir plan tablosuna yazın; fiyat ve sınır değişikliği yeni bir sürüm gerektirmesin.
- Abonelik durumu: Her kiracının bir abonelik kaydı olur ve bu kayıt bir yaşam döngüsünden geçer: deneme, aktif, ödeme gecikmiş, iptal edildi, süresi doldu. Stripe gibi faturalama platformlarının dokümantasyonu bu durumları ve geçişleri ayrıntılı tanımlar; kendi sisteminizi kurarken bile bu modeli örnek almak işinizi kolaylaştırır.
- Yetki kontrolü: Uygulama, bir özelliğin açık olup olmadığına planın ve aboneliğin durumuna bakarak karar verir. "Bu kiracının planı raporlama modülünü içeriyor mu ve aboneliği aktif mi?" sorusu tek bir fonksiyondan cevaplanmalıdır.
Türkiye'de kartla tekrarlayan tahsilat için banka sanal POS'u veya ödeme kuruluşları kullanılır; bazı ödeme kuruluşları kart saklama ve abonelik özellikleri sunar. Seçim kriterlerini sanal POS ve ödeme altyapısı rehberimizde karşılaştırdık. Her tahsilatın ardından fatura kesilmesi gerekir; müşterinin e-Fatura mükellefi olup olmamasına göre e-Fatura ya da e-Arşiv fatura düzenlenir. Bu akışı otomatikleştirmek için e-Fatura ve e-Arşiv entegrasyonu yazımıza göz atabilirsiniz. Vergi ve fatura yükümlülükleri mükellefiyet durumuna göre değiştiği için bu kısım genel bilgilendirmedir; mali müşavirinizle teyit edin.
SaaS ürününüzün bir mobil uygulaması da olacaksa dikkat: mobil uygulama içinde satılan dijital abonelikler mağaza kurallarına tabidir. Web'de alınan aboneliği uygulamada tanımak ve mağaza üzerinden alınanı web'e yansıtmak için tek bir yetki kaydı kullanmak gerekir; bu konuyu uygulama içi satın alma ve abonelik rehberimizde ayrıntılı anlattık.
Başarısız ödemeleri yönetmek de gelir kaybını doğrudan etkiler. Kartı reddedilen müşterinin erişimini hemen kesmek yerine birkaç gün ek süre tanıyın, ödemeyi otomatik olarak yeniden deneyin ve müşteriyi e-posta ile bilgilendirin. Ödeme sağlayıcısından gelen bildirimleri (webhook) imza doğrulamasıyla alın ve aynı bildirimin iki kez işlenmesine karşı önlem alın.
4. Onboarding: ilk dakikalar ürünün kaderini belirler
SaaS'ta satış görüşmesi çoğu zaman yoktur; müşteri ürünü kendisi dener ve birkaç dakika içinde karar verir. Onboarding, yeni bir kiracının kaydolmasından ürünün ilk değerini görmesine kadar geçen yolculuktur. Bu yolculuğu kısaltmak için:
- Kaydı sadeleştirin: İlk adımda yalnızca e-posta, şifre ve firma adı yeterlidir. Vergi numarası, adres gibi bilgileri ödeme aşamasına bırakın.
- Kiracıyı otomatik kurun: Kayıt tamamlandığında kiracı kaydı, ilk kullanıcı (sahip rolüyle), varsayılan ayarlar ve deneme aboneliği tek bir işlemde oluşturulmalıdır. Bu işlemin yarıda kalması, yarım kurulmuş kiracılar bırakır; bu yüzden ya hep ya hiç mantığıyla çalışmalıdır.
- Boş ekranla karşılamayın: Örnek verilerle dolu bir çalışma alanı, kısa bir kurulum listesi ya da içe aktarma sihirbazı, kullanıcının "şimdi ne yapacağım?" sorusunu cevaplar.
- Ekip davetini öne çıkarın: Bir iş aracı, ekip arkadaşları da kullandığında değer kazanır. Davet akışını kolay bulunur hâle getirin.
- Aktivasyonu ölçün: Ürününüz için "değeri gördü" anını tanımlayın (ilk projeyi oluşturdu, ilk faturayı kesti gibi) ve kayıt olanların ne kadarının bu noktaya ulaştığını takip edin.
Kayıt sırasında toplanan kişisel veriler için aydınlatma metni ve açık rıza gereken durumlar KVKK kapsamında ele alınmalıdır. Kendi müşterilerinizin verilerini işlediğiniz için çoğu senaryoda veri işleyen konumunda olursunuz; bunu sözleşmelerinizde ve gizlilik metinlerinizde netleştirin. Web tarafındaki temel adımlar için KVKK uyumlu web sitesi kontrol listemiz iyi bir başlangıçtır. Bu kısım genel bilgilendirmedir, hukuki danışmanlık değildir.
5. Ölçekleme ve operasyon
Ölçekleme, ilk günden binlerce müşteriye hazır olmak değil, büyüdükçe sistemi baştan yazmak zorunda kalmamaktır. Önerdiğimiz öncelik sırası şöyle:
- Durumsuz uygulama sunucuları: Oturum ve dosyaları uygulama sunucusunda değil, ortak bir depoda tutun. Böylece trafik arttığında aynı uygulamadan ikinci bir kopya çalıştırmak kolaylaşır. On iki faktör uygulama (The Twelve-Factor App) ilkeleri bu yaklaşımı ve yapılandırmanın ortamdan ayrılmasını özetler.
- Arka plan işleri: E-posta gönderimi, rapor üretimi, içe aktarma gibi uzun işleri kullanıcının isteğinden ayırıp bir iş kuyruğuna verin.
- Kiracı başına sınırlar: API isteklerine ve ağır işlemlere kiracı bazında sınır koyun; tek bir müşterinin sistemi yorması diğerlerini etkilemesin.
- Yedekleme ve geri yükleme: Veri tabanını düzenli yedekleyin ve geri yüklemeyi test edin. Paylaşımlı veri tabanında tek bir kiracının verisini geri getirmenin yolunu baştan düşünün. Yedekleme stratejisi için 3-2-1 kuralı yazımız işe yarar.
- İzleme ve uyarılar: Hata oranı, yanıt süresi, kuyruk uzunluğu ve veri tabanı yükü izlenmeli; sorun müşteriden önce size ulaşmalı.
- Güvenli sürüm çıkarma: Veri tabanı değişikliklerini geriye dönük uyumlu yapın, yeni özellikleri özellik bayraklarıyla önce belirli kiracılara açın, geri dönüş planı olmadan yayına çıkmayın.
Altyapı seçiminde paylaşımlı hosting genellikle SaaS için yetersiz kalır; VPS ya da bulut sunucularla başlamak daha uygundur. İlk aşamada tek bir güçlü sunucu ve ayrı bir yönetilen veri tabanı çoğu ürün için yeterlidir; karmaşık konteyner düzenlerine ancak gerçek bir ihtiyaç doğduğunda geçin.
Örnek senaryo: servis firmaları için iş emri SaaS'ı
Varsayımsal bir örnek: klima ve beyaz eşya servisi veren küçük firmalar için iş emri yönetimi sunan bir SaaS. Her servis firması bir kiracıdır; firmada sahip, ofis çalışanı ve saha teknisyeni rolleri vardır. Veri modeli paylaşımlı tablolar ve tenant_id ile kurulur, veri tabanında satır düzeyinde güvenlik açılır.
Planlar teknisyen sayısına göre ayrılır; ileri raporlama ve müşteriye SMS bildirimi üst plandadır. Yeni firma kaydolduğunda örnek bir müşteri ve iş emriyle dolu bir çalışma alanı açılır; kurulum listesinde "ilk teknisyeni davet et" adımı öne çıkar. Aktivasyon ölçütü "ilk iş emrinin teknisyen tarafından tamamlanması" olarak belirlenir. Teknisyenler sahada mobil uygulama kullandığı için zayıf internette çalışan bir senkronizasyon mekanizması ilk sürüme alınır; ileri raporlama ise ikinci sürüme bırakılır. İlk sürümün kapsamını belirlerken ihtiyaç analizi ve kapsam belirleme rehberimizdeki önceliklendirme adımları kullanılır.
Sık Sorulan Sorular
İlk sürümde çok kiracılı mimari şart mı?
İlk birkaç müşteriyle doğrulama yaparken bile tenant_id yapısını baştan kurmanızı öneririz. Tek kiracılı başlayıp sonradan çok kiracılıya geçmek, veri modelinin ve sorguların neredeyse tamamına dokunmayı gerektirir; baştan kurmanın ek maliyeti ise küçüktür.
Kurumsal bir müşteri verisinin ayrı tutulmasını isterse ne yapmalıyım?
Karma bir model kurabilirsiniz: çoğu kiracı paylaşımlı altyapıda kalırken bu müşteri için ayrı bir veri tabanı veya ayrı bir kurulum açılır. Bunun için uygulamanın, kiracıya göre hangi veri tabanına bağlanacağını seçebilecek şekilde tasarlanması gerekir.
Faturalama sistemini kendimiz mi yazmalıyız, hazır bir platform mu kullanmalıyız?
Plan, abonelik durumu ve yetki kontrolü sizin uygulamanızda olmalıdır; tahsilat, kart saklama ve yeniden deneme mantığı ise mümkün olduğunca ödeme sağlayıcısına bırakılmalıdır. Kart verisini kendi sunucunuzda tutmak, ağır güvenlik ve uyum yükümlülükleri getirir.
SaaS ürününde müşteriye özel geliştirme yapmalı mıyız?
Mümkün olduğunca hayır. Tek bir müşteri için kod değiştirmek, tüm müşterilere aynı sürümü sunma avantajını zayıflatır. Bunun yerine özelliği ayarla açılıp kapatılabilir hâle getirin; birden fazla müşterinin ihtiyacıysa ürüne ekleyin.
Bir SaaS ürününü geliştirmek ne kadar sürer?
Kapsama göre değişir. Tek bir ana işi çözen, temel faturalama ve onboarding içeren bir ilk sürüm genellikle birkaç aylık bir iştir. Asıl süre, ilk müşterilerden gelen geri bildirimlerle ürünü olgunlaştırmaya harcanır.
SaaS fikrinizi sağlam bir temele oturtalım
Başarılı bir SaaS ürünü, görünen özelliklerin yanında görünmeyen beş katmanın da doğru kurulmasına dayanır: kiracı ayrımı, yetkilendirme, faturalama, onboarding ve ölçekleme. Bu katmanları ilk sürümden doğru kurmak, büyüdükçe yeniden yazma zorunluluğunu ortadan kaldırır. Fikrinizi mimari ve kapsam açısından birlikte değerlendirmek için özel yazılım hizmetimizi inceleyebilir ya da bizimle iletişime geçebilirsiniz.
