Bir yazılım fikri olan hemen herkes bugün aynı cümleyi kuruyor: "Bunu SaaS yapalım." Mantıklı bir istek — çünkü SaaS, bir kere yazıp defalarca satabildiğiniz tek yazılım modeli.
Ama arada çoğu zaman fark edilmeyen bir detay var: SaaS bir iş modelidir, bir teknoloji değil. Ve o iş modelini ayakta tutan teknik kararlar, sıradan bir web projesinde hiç karşınıza çıkmaz. Bu yazıda SaaS'ın ne olduğunu, bir SaaS projesinin nasıl kurulduğunu ve yolun neresinde tökezlendiğini anlatıyoruz.
SaaS nedir?
SaaS (Software as a Service — hizmet olarak yazılım), yazılımın satın alınan bir ürün değil, abone olunan bir hizmet olarak sunulmasıdır. Kullanıcı hiçbir şey kurmaz, sunucu yönetmez, sürüm güncellemez. Tarayıcıdan girer, kullanır, aylık ya da yıllık öder.
Klasik yazılımdan farkını en net şu tablo gösterir:
| Klasik (kurulumlu) yazılım | SaaS | |
|---|---|---|
| Teslim | Müşterinin sunucusuna kurulur | Tarayıcıdan erişilir |
| Sürüm | Her müşteride farklı sürüm | Tek sürüm, herkes aynı anda |
| Bakım | Müşteri ya da bayi yapar | Üreticiye aittir |
| Gelir | Tek seferlik lisans | Tekrar eden abonelik |
| Büyüme maliyeti | Her müşteri yeni kurulum | Yeni müşteri = yeni kayıt |
Son satır işin özüdür. Klasik yazılımda yüzüncü müşteri, birinci müşteri kadar emek ister. SaaS'ta yüzüncü müşteri neredeyse bedava gelir — eğer mimariyi baştan doğru kurduysanız. Bu şart, yazının geri kalanının konusu.
SaaS projesi neden sıradan bir web projesinden zordur?
Bir kurumsal siteyi ya da tek şirkete özel bir paneli yazmak ile SaaS yazmak arasında, dışarıdan bakınca görünmeyen dört katman farkı vardır:
- Çok kiracılılık — Aynı yazılımı aynı anda kullanan birbirinden habersiz onlarca şirket.
- Kendi kendine kurulum — Yeni müşteri sizi aramadan kaydolup çalışmaya başlayabilmeli.
- Abonelik ve faturalama — Tahsilat, yükseltme, düşürme, iptal, deneme süresi.
- Kesintisizlik — Tek bir müşteri için bakıma alamazsınız; herkes aynı sistemde.
Bu dördü, tek şirkete yazılan bir özel yazılım projesinde ya hiç yoktur ya da çok basittir. SaaS'ta dördü de zorunludur ve dördü de baştan planlanmadığında sonradan eklenmesi en pahalı işlerdir.
1. Çok kiracılı (multi-tenant) mimari: ilk ve en kritik karar
SaaS'ın kalbi şu sorudur: A firmasının verisi ile B firmasının verisi nerede ayrılıyor?
Üç yaygın cevap vardır ve üçü de meşrudur — hangisinin doğru olduğu müşteri profilinize bağlıdır.
Ortak veritabanı, ortak tablo. Tüm kiracılar aynı tablolarda durur, her satırda bir kiracı kimliği taşınır. En ucuz ve en hızlı ölçeklenen yöntemdir. Riski tek cümlede özetlenir: bir sorguda o kiracı filtresini unutan geliştirici, bir müşteriye başka bir müşterinin verisini gösterir. Bu yüzden filtre uygulama koduna bırakılmaz, veri katmanına zorunlu kılınır.
Ortak veritabanı, ayrı şema. Her kiracının kendi tablo kümesi olur. Orta yol: izolasyon belirgin biçimde artar, maliyet çok yükselmez. Kiracı sayısı binleri bulduğunda şema yönetimi ağırlaşır.
Ayrı veritabanı. Her müşteri için ayrı veritabanı. En güçlü izolasyon, en kolay KVKK savunması, müşteri bazında yedekleme ve geri dönüş imkânı. Karşılığında en yüksek işletme maliyeti.
Pratik kural şudur: müşteriniz kurumsal ve veri hassasiyeti yüksekse izolasyona doğru, müşteriniz küçük işletme ve fiyat hassasiyeti yüksekse ortak yapıya doğru gidin. Aynı üründe ikisini birden yapmak da mümkündür — küçük paketler ortak yapıda, kurumsal paketler ayrı veritabanında çalışır.
Hangisini seçerseniz seçin, tek bir test her sürümde tekrarlanmalıdır: A kiracısının oturumuyla B kiracısının kaydına erişilebiliyor mu? Bu testi otomatik hale getirmeyen bir SaaS, er ya da geç o hatayı canlıda öğrenir.
2. Bulut sunucu neden tercih değil, zorunluluk?
SaaS'ı fiziksel bir sunucuda ya da tek bir sanal makinede çalıştırmak teknik olarak mümkündür. Ama SaaS'ın iş modeli bunu birkaç noktada kırar:
Yük tahmin edilemez. Müşteri sayınız arttıkça değil, müşterilerinizin işi arttıkça yüklenirsiniz. Ay sonu, kampanya dönemi, sezon başı — hepsi aynı güne denk gelebilir. Bulut altyapısında kaynak birkaç dakikada artırılır; kendi donanımınızda haftalar sürer ve o kapasite yılın kalanında boş bekler.
Tek makine tek arıza demektir. SaaS'ta bir sunucunun düşmesi tüm müşterilerin aynı anda durması demektir. Bulut, uygulamayı birden fazla kopya hâlinde ve birden fazla fiziksel bölgede çalıştırmayı standart hale getirir.
Veri nerede duruyor sorusu artık sözleşmeye giriyor. Kurumsal müşteriler ve KVKK açısından verinin hangi ülkede tutulduğu somut bir gerekliliktir. Bulut sağlayıcıları bölge seçimini bir ayar hâline getirir; Türkiye'de veri saklamayı taahhüt etmek istiyorsanız bunu altyapı seviyesinde çözebilmeniz gerekir.
Yedekleme ve geri dönüş otomatik olmalıdır. Burada yaygın bir yanılgı var: yedek almak yeterli sanılıyor. Yeterli değil. Ölçü, yedeğin varlığı değil, geri dönüşün ne kadar sürdüğüdür. Hiç denenmemiş bir yedek, yedek sayılmaz — üç ayda bir gerçek bir geri yükleme provası yapılmalıdır.
Altyapı kararının performansa etkisini küçümsemeyin; kullanıcının hissettiği yavaşlık doğrudan iptal sebebidir. Bu tarafı web sitesi hızlandırma ve Core Web Vitals yazımızda ayrıca ele almıştık.
3. Güvenlik: SaaS'ta hata tek müşteriyi değil, tüm işi etkiler
Tek şirkete yazılmış bir yazılımda güvenlik açığı o şirketin sorunudur. SaaS'ta aynı açık tüm müşteri portföyünüzün sorunudur ve şirketin sonu olabilir. Asgari liste şudur:
Rol bazlı yetkilendirme (RBAC). "Kullanıcı" ve "yönetici" ikilisi yetmez. Kiracı yöneticisi, kiracı kullanıcısı, salt okuyucu ve sizin tarafınızdaki sistem yöneticisi ayrı ayrı tanımlanmalıdır. Kritik nokta: sizin destek ekibinizin müşteri hesabına girebilmesi bir yetkidir — kayıt altına alınmalı ve müşteriye görünür olmalıdır.
Şifreleme, iki yerde birden. Veri hem taşınırken (HTTPS zorunlu, istisnasız) hem de dururken şifrelenmelidir. Diskte açık duran bir veritabanı yedeği, sızdığında her şeyi sızdırır.
Parola ve oturum hijyeni. Parolalar geri döndürülemez biçimde saklanır, oturumlar süre aşımıyla kapanır, kurumsal müşteri için iki adımlı doğrulama sunulur. Bunlar "sonra ekleriz" maddeleri değildir; sonradan eklemek oturum mimarisini yeniden yazmak demektir.
Denetim izi (audit log). Kim, ne zaman, hangi kaydı değiştirdi? Bu kayıt hem güvenlik olayını çözmenin tek yoludur hem de kurumsal satışta doğrudan sorulan bir sorudur.
Sır yönetimi. Veritabanı parolası, API anahtarları ve benzeri sırlar kod deposunda durmaz. Ortam değişkeninde veya sağlayıcının sır kasasında durur. Kod deposuna bir kez giren sır, silinse bile geçmişte kalır.
KVKK tarafı teknik değil, hukuki başlar. Hangi kişisel veriyi neden topladığınız, ne kadar sakladığınız ve silme talebini nasıl işlediğiniz yazılı olmalıdır. Silme talebi geldiğinde veriyi gerçekten silebilen bir veri modeliniz yoksa, uyumluluk metni yazmakla çözülmez.
Güvenliği bir özellik listesi olarak görürseniz sonuna eklersiniz. Mimari kısıt olarak görürseniz baştan doğru kurarsınız. SaaS'ta ikincisinden başkası işe yaramaz.
4. Abonelik katmanı: yazılımın para kazanan yarısı
SaaS'ın en çok küçümsenen parçası budur. Ürün mükemmel çalışsa bile abonelik katmanı aksarsa gelir aksar. Baştan düşünülmesi gerekenler:
- Paket ve limit mantığı. Hangi özellik hangi pakette? Limit aşıldığında ne oluyor — engelleniyor mu, uyarılıyor mu, otomatik yükseltiliyor mu?
- Deneme süresi. Kartsız mı, kartlı mı? Bitince veri ne kadar süre saklanıyor?
- Yükseltme ve düşürme. Ay ortasında paket değiştiren müşterinin farkı nasıl hesaplanıyor?
- Başarısız tahsilat. Kart geçmediğinde kaç kez, hangi aralıkla denenecek ve hesap ne zaman donacak?
- İptal ve veri. Müşteri ayrıldığında verisini dışa aktarabiliyor mu? Bu, kurumsal satışta güven kuran maddedir.
Tahsilat tarafını yaygın ödeme kuruluşlarının abonelik altyapılarına devretmek çoğu projede doğru karardır — kart verisini kendi sisteminizde tutmamak hem yükümlülüğü hem riski ciddi biçimde azaltır.
5. MVP: asıl beceri, neyi yazmayacağınıza karar vermek
SaaS projelerinin çoğu teknik sebeplerden değil, kapsam sebebinden ölür. İlk sürüme her şeyi koymaya çalışan proje uzar, uzadıkça pahalılaşır, pahalılaştıkça yarım kalır.
Doğru yaklaşım tek soruyla özetlenir: Bu üründe, olmadığında müşterinin hiç kaydolmayacağı tek özellik hangisi? İlk sürüm odur. Yanına yalnızca kaydolma, yetkilendirme ve tahsilat eklenir.
Ertelenebilecekler genelde şunlardır: gelişmiş raporlama, özelleştirilebilir arayüz temaları, dış sistem entegrasyonları, mobil uygulama, çok dillilik. Ertelenemeyecekler ise az sayıdadır ve hepsi bu yazıda geçti: kiracı izolasyonu, yetki modeli, denetim izi, yedekleme.
Ayrımı yapan kural nettir: sonradan eklenebilen şey ertelenir, sonradan eklenmesi yeniden yazmak anlamına gelen şey ertelenmez.
Tekrar eden destek ve operasyon işlerini ürünün içine yapay zeka otomasyonuyla gömmek de artık ilk sürümde düşünülebilecek bir başlık — ama bu da ürünün çekirdeği hazır olduktan sonra sırasını almalı.
En sık yapılan beş hata
- Kiracı filtresini uygulama koduna bırakmak. Bir gün biri unutur. Filtreyi veri katmanında zorunlu kılın.
- Tek müşteriye göre yazıp sonra "çoğullaştırmaya" çalışmak. Bu bir refactor değil, yeniden yazımdır.
- Yedeği alıp geri dönüşü hiç denememek. Yedek, geri yüklenene kadar sadece bir dosyadır.
- Abonelik katmanını en sona bırakmak. Ürün hazır olur, tahsilat hazır olmaz; gelir gecikir.
- Ölçeklenmeyen işi kullanıcı isteğine bağlamak. Rapor üretimi, dışa aktarma, toplu e-posta gibi ağır işler kuyruğa alınmalıdır; kullanıcının beklediği ekranda çalıştırılmamalıdır.
Kısaca
SaaS, yazılımın en çok getirisi olan ama en az affeden türü. Getirisi yüksek, çünkü bir kere yazdığınız şeyi sınırsız satabiliyorsunuz. Affetmiyor, çünkü mimari kararların hepsi ilk günde veriliyor ve yanlış verilen karar müşteri sayısıyla birlikte büyüyor.
Bir SaaS projesine başlarken sorulacak soru "hangi teknolojiyle yazalım?" değildir. Şudur:
Yüzüncü müşteri geldiğinde bu sistemde ne değişmek zorunda kalacak?
Cevap "hiçbir şey" ise doğru yoldasınız. Cevap uzuyorsa, mimariyi koda başlamadan konuşmak gerekiyor demektir.
Bir SaaS fikriniz varsa ve nereden başlayacağınıza karar veremiyorsanız, özel web yazılım hizmetimizi inceleyebilir ya da doğrudan bize ulaşabilirsiniz. Sürecin hangi noktasında olduğunuza bakıp yol haritasını birlikte çıkaralım.
