SaaS ve web platformu geliştirme

SaaS, yazılımın kurulum yerine tarayıcı üzerinden, aylık ya da yıllık abonelikle sunulduğu modeldir. Dışarıdan bakıldığında her SaaS bir web uygulamasıdır, ama her web uygulaması SaaS değildir. Farkı yaratan, ürünün kimse elle müdahale etmeden müşteri kazanabilmesi ve tutabilmesidir: ziyaretçi kendi başına kaydolur, deneme süresinde değeri görür, kartını girip plana geçer, ekibini davet eder ve faturasını panelden indirir. Bu zincirin her halkası tasarım ve geliştirme işidir.

Bu yüzden abonelik yazılımı geliştirirken ekranların yanında görünmeyen katmanları da kuruyoruz: plan bazlı özellik kısıtları, kullanım limitleri, ödeme başarısız olduğunda devreye giren hatırlatma akışı, iptal ve geri kazanım adımları, müşteri başarısı ekibinin hesapları izleyebileceği bir süper yönetici paneli. Bu parçalar ilk sürümde eksik kalırsa ürün çalışır görünür ama her yeni müşteri ekibe elle yapılacak bir iş olarak geri döner.

Çok kiracılı mimaride tüm müşteriler aynı uygulamayı ve çoğunlukla aynı veritabanını paylaşır, ama hiçbiri diğerinin verisini göremez. Bu ayrımı yalnızca uygulama kodunda yapmak risklidir; tek bir unutulmuş filtre, bir müşterinin kaydını başkasına gösterebilir. Biz PostgreSQL’de satır düzeyinde güvenlik kurallarıyla ayrımı veritabanının kendisine taşıyor, her sorguyu kiracı bağlamıyla çalıştırıyoruz. Supabase gibi altyapılar bu modeli doğal olarak destekler.

Kiracı yapısının üzerine organizasyon, ekip ve rol katmanını, denetim kayıtlarını, kiracı bazında ayarları ve özellik bayraklarını ekliyoruz. Kurumsal müşteriler geldiğinde tek oturum açma, özel alan adı ya da ayrı veri bölgesi gibi talepler sorunsuz karşılanabilsin diye bu kapıları baştan açık bırakıyoruz. Arayüzde Next.js ve TypeScript, barındırmada Vercel ya da Cloudflare, arka plan işlerinde kuyruk tabanlı bir yapı kullanıyoruz; böylece bir müşterinin yoğun işlemi diğerlerini yavaşlatmıyor.

MVP, ürünün küçük bir versiyonu değil, en riskli varsayımı en kısa yoldan sınayan versiyonudur. Çoğu SaaS fikrinde bu varsayım şudur: hedef müşteri bu problemi çözmek için para öder mi? Bu yüzden ilk sürümde tek bir ana iş akışını uçtan uca sağlam kuruyor, geri kalan her şeyi sonraya bırakıyoruz. Kimlik doğrulama, kiracı ayrımı ve ödeme ise MVP’de bile eksiksiz olmalı; bunlar sonradan eklenmesi en pahalı parçalardır.

Tipik akış şöyle ilerler: birkaç haftalık ürün tanımı ve temel katman, ardından çekirdek özelliklerin geliştirildiği ve kapalı betaya açıldığı bir dönem, sonra herkese açık lansman. Kapsamı iyi tutulmuş bir MVP genellikle birkaç ay içinde ilk kullanıcılarıyla buluşur. Lansmandan sonra ürün bitmiş olmaz; asıl iş, kullanım verisine bakarak hangi özelliğin geliştirileceğine karar verdiğiniz düzenli sürüm döngüsüyle başlar.

En pahalı hata, kiracı ayrımını ve abonelik mantığını sonraya bırakmaktır; ürün tutmaya başladığında bunları eklemek çoğu zaman temeli yeniden atmak anlamına gelir. İkincisi, her potansiyel müşterinin özel talebini ürüne eklemektir: SaaS bir danışmanlık projesine dönüşür ve kimseye tam uymaz. Üçüncüsü, fiyatlandırmayı mühendislikten ayrı düşünmektir; plan sınırları, kullanım ölçümü ve yükseltme akışı kodun içinde yaşar.

Sağlıklı bir SaaS’ın işaretleri ise ölçülebilir: yeni kullanıcı kimseyle konuşmadan ilk değerli sonucuna ulaşır, hangi adımda kaybedildiği panelde görünür, yeni bir özellik canlıdaki hesapları kesintiye uğratmadan çıkar ve destek talepleri büyüme hızından yavaş artar. Medya ve satış tarafındaki geçmişimiz sayesinde bu metrikleri yalnızca teknik değil, ticari bir gözle de okuyor ve yol haritasını onlara göre birlikte şekillendiriyoruz.