SaaS Mimarisi: Teknik Olmayan Kurucuların Geliştirmeye Başlamadan Önce Bilmesi Gerekenler

SaaS kurucularını yaklaşık on sekiz ay sonra bulan kendine özgü bir pişmanlık türü vardır. Ürün yayında, ilk müşteriler kullanıyor ve ardından biri şunu söylüyor: "X'i yapmadan önce kiracı yönetimini yeniden mimarlamalıyız." Ya da: "Faturalandırma sistemi kullanım tabanlı fiyatlandırma için tasarlanmamıştı — düzeltmek üç ay alacak." Ya da en kötüsü: "Bu uyumluluk gereksinimi müşteri başına veri izolasyonu anlamına geliyor, ancak tüm sistem tek bir veritabanını paylaşıyor."

Bunlar hata değil. Başlangıçta makul görünen ve şimdi geri döndürmesi çok pahalı olan mimari tercihler.

Bunun bu kadar sık yaşanmasının nedeni geliştiricilerin dikkatsiz olması değil. Sorun, kurucuların geliştirme başlamadan önce doğru soruları sormak için yeterli bağlamdan yoksun olmasıdır — bu yüzden geliştirme ekibi, ürünün gitmesi gereken yere en uygun olanı değil, en hızlı, en basit veya en aşina oldukları seçeneği tercih eder.

Bir yazılım mimarı olmanız gerekmiyor. Ancak bir SaaS ürünündeki temel mimari kararları anlayacak kadar bilgiye sahip olmanız, konuşmaya katılmanız, varsayımları sorgulamanız ve bilinçli değiş tokuşlar yapabilmeniz gerekiyor. Bu rehber tam olarak bunun içindir.

---

SaaS Mimarisi Nedir?

SaaS mimarisi, bir yazılım ürününün nasıl inşa edileceğini, barındırılacağını ve bakımının yapılacağını belirleyen tasarım kararlarını ifade eder; bu kararlar ürünün aynı anda birden fazla müşteriye hizmet verebilmesini, abonelikleri ve faturalandırmayı otomatik olarak yönetebilmesini, kullanıcıları manuel müdahale olmaksızın sisteme dahil edebilmesini ve tamamen yeniden inşa gerektirmeden ölçeklenebilmesini sağlar.

İyi mimariye sahip bir SaaS ürününün beş temel özelliği vardır:

• Çok kiracılık (Multi-tenancy) — birden fazla müşteri (kiracı) aynı uygulama altyapısını paylaşır; verileri uygun biçimde ayrı tutulur
• Abonelik faturalandırması — müşteriler dönemsel olarak ödeme yapar; faturalandırma sistemi planları, deneme sürelerini, yükseltmeleri, düşürmeleri ve yenilemeleri otomatik olarak yönetir
• Kendi kendine dahil olma (Self-service onboarding) — kullanıcılar sizin tarafınızda herhangi bir insan müdahalesi olmadan kaydolabilir, hesaplarını oluşturabilir ve ürünü kullanmaya başlayabilir
• API-öncelikli tasarım — ürünün özü, entegrasyonları, mobil uygulamaları ve gelecekteki genişletilebilirliği destekleyen iyi yapılandırılmış bir API aracılığıyla sunulur
• Bulut tabanlı altyapı — ürün, sabit sunucular yerine talebe göre ölçeklenebilen bulut altyapısında barınır

Bunlar sonradan eklenecek ayrı özellikler değil. Bunlar mimari özelliklerdir — ya başından tasarlanır ya da sonradan acı vererek eklenir. Ürününüzün bu özelliklere sahip olup olmayacağını belirleyen kararlar projenin ilk birkaç haftasında alınır.

---

Çok Kiracılık: En Önemli Karar

Çok kiracılık, SaaS'ın tanımlayıcı mimari özelliğidir. Aynı zamanda en geniş kapsamlı sonuçlara yol açan karardır; maliyet yapınızı, uyumluluk tutumunuzu, kurumsal müşterilere özelleştirme yapabilme kapasitenizi ve kod tabanınızın karmaşıklığını etkiler.

Üç temel model vardır:

Havuz Modeli (Her Şeyi Paylaşan)

Havuz modeli mimarisinde tüm müşteriler tek bir veritabanını (ve çoğunlukla tek bir uygulama örneğini) paylaşır. Verileri her veritabanı tablosundaki bir kiracı kimliği (tenant ID) sütunuyla ayrılır. Bir satır A Şirketi'ne, bir sonraki satır B Şirketi'ne aittir — hepsi aynı tablodadır.

Avantajlar: Çalıştırması en ucuz. Başlangıçta inşa etmesi en basit. Veritabanı altyapısı müşteri başına değil, bir kez ölçeklenir. Dağıtımlar ve güncellemeler tek bir yerde gerçekleşir.

Dezavantajlar: Yanlış yapılandırılmış bir sorgu, bir kiracının verilerini başkasına açık hale getirebilir. Veri izolasyonu gerektiren uyumluluk çerçevelerini (SOC 2, ISO 27001, belirli sağlık hizmetleri gereksinimleri) karşılamak daha zordur. Gürültülü komşu sorunları gerçektir — ağır bir sorgu çalıştıran bir kiracı diğer herkesi etkileyebilir. Kiracı başına özel yapılandırmalar karmaşık hale gelir.

Silo Modeli (Her Şeyi İzole Eden)

Silo modeli mimarisinde her müşteri kendi izole edilmiş altyapısını alır — kendi veritabanı örneği, bazen kendi uygulama ortamı. Verileri altyapı düzeyinde başka bir kiracının verilerine hiç dokunmaz.

Avantajlar: Tasarım gereği gerçek veri izolasyonu. Kurumsal uyumluluk gereksinimlerini karşılamak daha kolay. Bir kiracının ortamındaki sorun diğerlerini etkileyemez. Farklı kurumsal müşteriler için ürünün farklı sürümlerini çalıştırabilirsiniz.

Dezavantajlar: Ölçekte işletmek önemli ölçüde daha pahalı. Yüzlerce veritabanı örneğini yönetmek operasyonel açıdan karmaşık. Dağıtımlar ve güncellemeler tüm silo ortamlarında koordineli biçimde yapılmalıdır. Kendi kullanım verilerinizde kiracılar arası analiz yapmak zordur.

Köprü Modeli (Paylaşılan Uygulama, Ayrı Şemalar)

Köprü modeli ikisi arasında yer alır. Tüm kiracılar aynı uygulama katmanını kullanır, ancak her kiracı ayrı bir veritabanı şeması alır (ya da bazı uygulamalarda paylaşılan bir küme içinde ayrı bir veritabanı). Veriler, silo modelinin tam operasyonel yükü olmadan fiziksel olarak ayrılır.

Avantajlar: Havuz modelinden daha iyi veri izolasyonu. Tam silolardan daha basit işletme. Orta ölçekli pazar ve ılımlı uyumluluk gereksinimleri olan kurumsal müşteriler için uygundur.

Dezavantajlar: Saf havuzdan inşa etmesi daha karmaşık. Veritabanı migrasyon yönetimi zorlaşır — aynı migrasyonu birçok şema üzerinde çalıştırırsınız. Bazı araçlar çoklu şema kurulumlarını zarif biçimde yönetmiyor.

Model	Altyapı Maliyeti	Veri İzolasyonu	Uyumluluk Uygunluğu	Operasyonel Karmaşıklık
Havuz (Paylaşılan DB)	Düşük	Yalnızca mantıksal	Temel	Düşük
Köprü (Paylaşılan Uygulama, Ayrı Şemalar)	Orta	Kiracı başına fiziksel	Orta Pazar/Kurumsal	Orta
Silo (İzole)	Yüksek	Tam izolasyon	Kurumsal/Düzenlenmiş	Yüksek

Doğru cevap pazarınıza bağlıdır. KOBİ'lere satış yapıyorsanız ve düzenlenmiş sektörden kurumsal müşteriler beklemiyorsanız, iyi uygulanmış bir havuz modeli tamamen makuldür. Yol haritanız finansal hizmetler, sağlık hizmetleri veya güvenlik anketleri olan büyük kuruluşlara satış yapmayı içeriyorsa, cevap neredeyse kesinlikle bir köprü veya silo yaklaşımıdır — ve izolasyonu sonradan eklemek son derece maliyetlidir.

Bu, tek bir satır kod yazılmadan önce alınması gereken bir karardır.

---

Kimlik Doğrulama ve Kimlik Yönetimi

Kimlik doğrulama — bir kullanıcının kim olduğunu doğrulama — çözülmüş bir sorun gibi görünür. Bir giriş formu ekle, şifreleri hashle, bitti. Tüketici uygulamalarında bu doğru olabilir. Bir SaaS ürününde ise işin içi önemli ölçüde karmaşıktır.

Üretim aşamasındaki bir SaaS ürününün şunları yönetmesi gerekir:

• Kullanıcı adı ve şifre kimlik doğrulaması — güvenli depolama, şifre sıfırlama akışları ve kaba kuvvet koruması ile
• OAuth / sosyal giriş (Google, Microsoft, GitHub) — kullanıcıların giderek daha fazla beklediği bir özellik
• Çok faktörlü kimlik doğrulama (MFA) — her kurumsal alıcı tarafından beklenen ve birçok uyumluluk çerçevesi tarafından zorunlu kılınan
• SAML 2.0 veya OIDC üzerinden Tek Oturum Açma (SSO) — belirli bir büyüklüğün üzerindeki neredeyse her kurumsal müşteri tarafından, çoğunlukla pazarlık kabul etmez bir tedarik gereksinimi olarak talep edilen
• Ekip davetleri — bir kullanıcının diğerlerini hesabına davet etmesi; rol atamasıyla birlikte
• Rol tabanlı erişim kontrolü (RBAC) — yöneticilerin her şeyi görmesi, görüntüleyicilerin yalnızca görmeleri gerekenleri görmesi ve arasındaki her şey
• Oturum yönetimi — oturumları uygun biçimde aktif tutma, eş zamanlı oturumları yönetme, şifre değişikliğinde zorla çıkış
• Kimlik doğrulama olaylarının denetim kaydı — kimin, nereden, ne zaman oturum açtığı ve ne yaptığı

Tüm bunları sıfırdan inşa etmek pahalıdır ve gerçek güvenlik riskleri doğurur. Her özel kimlik doğrulama uygulaması, amaca yönelik tasarlanmış sistemlerin çoktan çözdüğü güvenlik açıkları barındırma potansiyeline sahiptir.

Varsayılan önerimiz yönetilen bir kimlik platformu kullanmaktır — Auth0, Clerk veya Supabase Auth en sık kullandığımız üç platformdur. Bu hizmetler, kimlik doğrulama protokolü uyumluluğu, MFA, SSO ve oturum yönetiminin ağır yükünü üstlenir; modern uygulama yığınlarına temiz biçimde entegre olan SDK'lar sunar. Ölçekte ücretsiz değildirler, ancak kimlik doğrulamada hata yapmanın maliyeti — geliştirme süresi, güvenlik olayları veya SAML SSO'yu destekleyemediğiniz için kaybedilen kurumsal anlaşmalar açısından — çok daha yüksektir.

İnşa etmeden önce cevaplamanız gereken temel mimari soru: Kurumsal alıcı profiliniz nedir? Bir IT departmanı olan herhangi bir kuruluşa satış yapmanızı bekliyorsanız, SSO desteği zorunludur ve bunu karşılayacak bir kimlik katmanına ihtiyacınız vardır.

---

Abonelik Faturalandırma Mimarisi

Faturalandırma, kurucuların karmaşıklığı dramatik biçimde küçümsediğini gördüğümüz ikinci alandır. Mutlu yol — müşteri kaydoluyor, kart bilgilerini giriyor, aylık ödeme yapıyor — anlaşılırdır. Geri kalan her şey değil.

Ölçekte bir SaaS faturalandırma sisteminin şunları yönetmesi gerekir:

• Ücretsiz denemeler (kredi kartı gerekli ya da kart gerektirmeyen; deneme-ücretli dönüşümü)
• Farklı özellikler ve sınırlarla birden fazla fiyatlandırma planı
• Dönem ortasında orantılı ücretler dahil yükseltmeler ve düşürmeler
• Ölçümlü faturalandırma — kullanıma dayalı ücretlendirme (API çağrıları, kullanıcı sayısı, depolama, işlemler)
• Uygun indirimlerle yıllık ve aylık faturalandırma
• Kartla değil, fatura ile ödeme yapan müşteriler için faturalama
• Başarısız ödeme işleme, borç tahsil akışları ve kullanım süreleri
• İadeler ve krediler
• Vergi hesaplama (özellikle yargı bölgeleri arası KDV/ÖTVK)
• Uygulama durumunuzu senkronize tutmak için ödeme sağlayıcınızdan gelen webhook'lar

Tüm bunları doğru şekilde işleyen bir faturalandırma sistemi inşa etmek önemli bir mühendislik projesidir. Hata türleri pahalıdır — hem finansal açıdan (yanlış uygulanan ücretler, başarısız yükseltmeler) hem de müşteri güveni açısından.

Temel faturalandırma altyapısı için standart önerimiz Stripe Billing'dir. Stripe finansal karmaşıklığı — faturalama, orantılama, borç tahsilatı, ödeme yöntemleri, desteklenen bölgelerde vergi — üstlenir ve bunu iyi tasarlanmış bir API aracılığıyla sunar. Uygulamanızın görevi, plan haklarını yönetmek (belirli bir plandaki müşterinin hangi özelliklere erişebileceği) ve veritabanınızı faturalandırma durumuyla senkronize tutmak için Stripe webhook'larına yanıt vermek olur.

Faturalandırmayı şirket içinde inşa etme cazibesi neredeyse her zaman bir hatadır. Stripe'ın fiyatlandırması erken gelirinize kıyasla yüksek görünse bile, tasarruf edilen mühendislik süresi — ve elde ettiğiniz doğruluk güvenceleri — neredeyse her SaaS ürünü için doğru değiş tokuşu yapar.

---

SaaS için Veri Mimarisi

Yukarıda çok kiracılık veri modellerine değindik, ancak veri mimarisi verilerin nerede depolandığının ötesine geçer. Ölçekte, verilerinizin yapılandırılma biçimi ürününüzün ne kadar hızlı ilerleyebileceğini, değişiklikleri ne kadar güvenli yapabileceğinizi ve müşterilere karşı yükümlülüklerinizi karşılayıp karşılayamayacağınızı belirler.

Baştan kasıtlı olarak tasarlanması gereken birkaç alan:

Ölçekte şema migrasyonları. Tek veritabanı uygulamasında bir veritabanı migrasyonu çalıştırmak tek bir işlemdir. Çoklu şema veya çoklu veritabanı mimarisinde ise aynı migrasyonu çalıştırmak, her kiracı ortamına doğru biçimde uygulamak anlamına gelir. Sağlam bir migrasyon stratejisi (ve bunu destekleyen araçlar) olmadan bu, büyüdükçe bir dağıtım darboğazına dönüşür.

Yumuşak silme ve kalıcı silme. Çoğu SaaS uygulamasında, bir kullanıcı bir şeyi "sildiğinde" veriler gerçekten kaybolmamalıdır. Yumuşak silme (bir kaydı kaldırmadan silinmiş olarak işaretleme) geri alma işlevi, denetim kayıtları ve veri kurtarma olanağı sağlar — ve baştan uygulamak, sonradan eklemekten çok daha basittir.

Yedekler ve felaket kurtarma. Veritabanı çökerse kurtarma süresi hedefiniz (RTO) nedir? Kurtarma noktası hedefiniz (RPO) nedir — ne kadar veri kaybını göze alabilirsiniz? Bunlar mimari sonuçları olan iş kararlarıdır. Otomatik günlük yedeklemeler asgari düzeydir; veri kaybının ciddi sonuçlar doğuracağı her ürün için belirli bir noktaya geri yükleme doğru hedeftir.

GDPR için veri dışa aktarma ve silme. Birleşik Krallık veya AB'deki müşterilere satış yapan her SaaS ürünü, belirli bir müşterinin verilerini makine tarafından okunabilir bir formatta dışa aktarabilmeli ve talep üzerine kalıcı olarak silebilmelidir. Veri modeliniz bunu göz önünde bulundurarak tasarlanmadıysa, bu talepleri ölçekte manuel olarak yerine getirmek zahmetlidir.

---

API Tasarımı

API-öncelikli bir SaaS ürünü, API'sini birinci sınıf bir ürün olarak değerlendirir — entegrasyonlar için sonradan düşünülen bir şey değil, hem ön yüzün hem de üçüncü taraf tüketicilerin üzerine inşa edildiği temel. Bu önemlidir çünkü:

• Müşterileriniz ürününüzün üzerine otomasyonlar inşa etmek isteyecektir
• Kurumsal alıcılar tedarik görüşmelerinde API'niz hakkında soru soracaktır
• Mobil uygulamalar, tarayıcı uzantıları ve ortak entegrasyonların tümü API kalitesine bağlıdır
• Aynı API üzerine inşa edilmiş kendi iç araçlarınız (gösterge panelleri, yönetici panelleri) tutarlılığı güçlendirir

İki dominant API paradigması REST ve GraphQL'dir. REST daha basit, daha yaygın biçimde anlaşılır ve önbelleğe almak daha kolaydır — çoğu SaaS ürünü için doğru varsayılan seçimdir. GraphQL, ön yüz veri gereksinimleri karmaşık ve son derece değişken olduğunda avantaj sağlar, ancak erken aşama ürünlerin çoğunun ihtiyaç duymadığı operasyonel karmaşıklık ekler.

API versiyonlama, ertelemesi kolay ancak sonradan eklenmesi sancılı bir mimari karardır. Başından itibaren API'niz sürümlendirilmiş olmalıdır (genellikle URL yolunda /v1/ veya başlık aracılığıyla); böylece kırıcı değişiklikler yaptığınızda tüm mevcut API tüketicilerini hemen güncellemeye zorlamadan bunu yapabilirsiniz. API yanıt biçimini değiştirdiğiniz için bir müşterinin entegrasyonunu kırmak ciddi bir güven sorunudur.

---

Ölçeklenebilirlik ve Altyapı

"Ölçeklenebilir olması gerekiyor" neredeyse her kurucunun keşif aşamasında söylediği bir şeydir. Bunun gerçekte ne anlama geldiği büyük farklılıklar gösterir ve yanlış ölçek için tasarlamak, hiç ölçek için tasarlamamak kadar sorun yaratır.

Dikey ölçekleme, sunucularınıza daha fazla kaynak vermek demektir — daha fazla CPU, daha fazla bellek, daha fazla depolama. Basit, kod değişikliği gerektirmez ve belirli bir noktaya kadar iyi çalışır.

Yatay ölçekleme, bir yük dengeleyici arkasında uygulamanızın birden fazla örneğini aynı anda çalıştırmak demektir. Çok daha yüksek trafik kapasitelerini karşılar, ancak uygulamanızın durumsuz olmasını gerektirir — yani belirli bir kullanıcı oturumuna ilişkin hiçbir bilginin uygulama sunucusunun belleğinde depolanmaması. Oturum verileri, tüm örneklerin erişebileceği paylaşılan bir depoda (Redis, veritabanı) bulunmalıdır.

Çoğu SaaS ürünü için ölçeklenebilirlik hakkındaki dürüst gerçek: İlk günden yatay ölçek için tasarlamanız gerekmez. Uygun boyutlandırılmış bulut altyapısında çalışan iyi yapılandırılmış bir monolitik uygulama, ölçek bir darboğaza dönüşmeden önce on binlerce kullanıcıyı karşılayabilir. Doğru yaklaşım, ölçeklenebilirliği akılda tutarak inşa etmektir — durumsuz oturumlar, dizinleri düzgün kullanan veritabanı sorguları, arka plan işlerinin asenkron olarak yürütülmesi — yıllarca ulaşamayabileceğiniz bir ölçek için aşırı mühendislik yapmadan.

İlk günden yatırım yapmanız gereken şey gözlemlenebilirliktir: uygulama izleme (hata oranları, yanıt süreleri, çökme raporlama), altyapı izleme (CPU, bellek, veritabanı bağlantı sayıları) ve müşteriler bir sorunu fark etmeden önce birini uyandıran uyarı mekanizmaları.

---

1. Günden Önce Alınacak Mimari Kararlar

Geliştirme ekibiniz bir satır uygulama kodu yazmadan önce bu kararlar alınmış ve belgelenmiş olmalıdır:

• Çok kiracılık modeli — havuz, köprü veya silo? (Hedef pazarınız ve uyumluluk gereksinimleriniz tarafından belirlenir)
• Kimlik doğrulama stratejisi — yönetilen kimlik platformu (Auth0, Clerk) mu yoksa özel mi? İlk günden SSO gerekli mi?
• Faturalandırma altyapısı — gerçeğin kaynağı olarak Stripe Billing; uygulamanız hakları mı yönetiyor?
• Hedef bulut sağlayıcısı — AWS, GCP veya Azure? Araçları, satıcı ilişkilerini ve yetenek havuzunu etkiler
• Ön yüz çerçevesi — Next.js, Nuxt, SvelteKit? Uzun vadeli ekip kompozisyonu için önemli
• Birincil veritabanı — PostgreSQL çoğu SaaS ürünü için doğru varsayılandır; NoSQL'in belirli kullanım senaryoları vardır
• API tasarım standardı — REST mi GraphQL mi? Versiyonlama stratejisi nedir?
• Veri bulunduğu yer gereksinimleri — herhangi bir müşteri, verilerinin belirli bir coğrafyada kalmasını zorunlu kılıyor mu?
• Dağıtım mimarisi — başlangıçta monolit; microservices sonradan gerekirse net sınırlarla

---

Gördüğümüz Yaygın SaaS Mimarisi Hataları

Fintech, sağlık hizmetleri, lojistik ve profesyonel hizmetler alanında SaaS ürünleri inşa ettikten sonra, neyin ne zaman yanlış gittiğini net biçimde görüyoruz.

Erken microservices. Alan sınırları iyi anlaşılmadan bir ürünü microservices'e bölmek, faydaları olmadan devasa operasyonel karmaşıklık yaratır. İyi yapılandırılmış bir monolitik uygulama ile başlayın. Hizmetleri açık bir nedene sahip olduğunuzda çıkarın — bir ekip sahipliği sınırı, dramatik biçimde farklı bir ölçekleme profili, bir uyumluluk sınırı. Bundan önce değil.

Denetim kaydı yok. Kurumsal müşteriler ürününüzde kimin ne yaptığını ve ne zaman yaptığını bilmek ister. Düzenleyiciler bazen bunu zorunlu kılar. Bunun için tasarlanmamış bir veri modeline denetim kaydını sonradan eklemek zahmetli ve çoğunlukla eksik olur. İlk günden inşa edin.

Kiracı varsayımlarının sabit kodlanması. tenant_id'nin bazı tablolara eklenip diğerlerine eklenmediği ya da bazı arka plan işlerinin kiracı başına değil global olarak veri işlediği ürünleri sıklıkla görüyoruz. Bu tutarsızlıklar bekleyen hatalardır ve sistemde ne kadar fazla veri olursa düzeltilmesi o kadar zorlaşır.

Veri dışa aktarımı için tasarım yapmamak (GDPR ve müşteri kaybı). Müşteriler gider. Birleşik Krallık/AB mevzuatı kapsamında, verilerini taşınabilir bir formatta sağlamakla yasal olarak yükümlü olabilirsiniz. Veri modelinizi ve API'lerinizi bunu baştan mümkün kılacak biçimde tasarlayın — ilk kurumsal müşterinizin hukuk ekibi bunu talep ettiğinde acil bir proje olarak değil.

Faturalandırma durumunu uygulama durumuyla yanlış eşleştirme. Stripe'ı faturalandırmanın gerçek kaynağı olarak kullanmak ancak kendi veritabanınızda da plan durumunu korumak sorun değil — iki kaynak webhook işlemeyle senkronize tutulduğu sürece. Bu iki gerçek kaynağının sessizce birbirinden uzaklaştığı ürünleri düzenli olarak görüyoruz; bu durum müşterilerin ödeme yapmadıkları özelliklere erişmesine ya da (daha kötüsü) ödedikleri özelliklerden mahrum kalmalarına yol açıyor.

---

Cyberbeak'te SaaS Mimarisini Nasıl Tasarlıyoruz

SaaS keşif sürecimiz tipik olarak herhangi bir geliştirme başlamadan iki ila üç hafta boyunca sürer. Bu süre zarfında şunları ele alırız:

Pazar ve uyumluluk haritalama. Hedef alıcılar kimler? Hangi sektörlerdeler? Tedarik görüşmelerinde hangi uyumluluk çerçeveleri gündeme gelebilir? Bu soruların yanıtları, başka herhangi bir karar alınmadan önce çok kiracılık modelini ve kimlik doğrulama gereksinimlerini belirler.

Veri modeli tasarımı. Çekirdek şemayı çok kiracılık, yumuşak silme, denetim kaydı ve GDPR dışa aktarma baştan dahil edecek biçimde tasarlıyoruz. Bu, veri ilişkilerini herkesin anlaması için kurucu ekiple işbirliği içinde yapılır.

Entegrasyon haritalama. Ürünün neye bağlanması gerekiyor? Diğer ürünlerin ürününüze bağlanması için ne gerekiyor? Bu, API tasarım önceliklerini ve en erken entegrasyon taahhütlerini belirler.

Altyapı tasarımı. Bir bulut sağlayıcısı seçiyor, ortam yapısını (geliştirme, hazırlık, üretim) tanımlıyor, CI/CD hattı kuruyoruz ve ilk uygulama özelliği inşa edilmeden önce izleme ile uyarıları devreye alıyoruz.

Bu aşamadaki yeni SaaS ürünleri için varsayılan yığınımız şunlardır: Next.js (ön yüz), ekip kompozisyonu ve ürün gereksinimlerine bağlı olarak arka yüzde Node.js veya Python, birincil veritabanı olarak PostgreSQL, ödemeler için Stripe Billing, kimlik için Auth0 veya Clerk ve altyapı için AWS. Bu katı bir şablon değil — gereksinimlere göre uyarlıyoruz — ancak üretimde SaaS ürünleri inşa etme ve bakımını yapma konusundaki yıllarca süren deneyimi yansıtıyor.

Keşfin amacı mükemmel bir plan üretmek değil. Geri döndürmesi pahalı kararları gün yüzüne çıkarmak, bunları açıkça ve kasıtlı olarak almak ve geliştirme ekibine güvenle üzerine inşa edebileceği bir temel vermektir.

---

SSS

SaaS mimari planlaması ne kadar sürer?

Çoğu erken aşama SaaS ürünü için, uygun bir keşif ve mimari aşaması iki ila üç hafta sürer. Daha karmaşık ürünler için — özellikle kurumsal uyumluluk gereksinimleri, karmaşık veri modelleri veya birden fazla entegrasyon bağımlılığı olanlar için — dört ila altı hafta sürebilir. Bu yatırım, sonraki sprintlerdeki pahalı yeniden çalışmaları önleyerek kendini defalarca amorti eder.

Daha basit bir mimariyle başlayıp sonradan yükseltebilir miyiz?

Bazı kararlar ertelenebilir — ilk günden otomatik ölçeklemeye ihtiyacınız yoktur ve ürün olgunlaştıkça birçok entegrasyon eklenebilir. Ancak temel kararlar — çok kiracılık modeli, kimlik doğrulama stratejisi, faturalandırma altyapısı — sistemde müşteri verisi olduğunda değiştirmesi çok pahalıdır. Başlangıç uygulaması basit olsa bile bu kararları baştan kasıtlı olarak almanızı her zaman öneririz.

SaaS ürünü için microservices'e ihtiyacımız var mı?

İlk günden neredeyse kesinlikle hayır; muhtemelen yıllarca da değil. Microservices gerçek sorunları çözer, ancak önemli operasyonel karmaşıklık ekler. İyi yapılandırılmış bir monolit, SaaS ürünlerinin büyük çoğunluğu için doğru başlangıç noktasıdır. Monolitleri net iç sınırlarla tasarlıyoruz; böylece sonradan hizmetleri çıkarmak — gerçekten gerekli hale gelirse — bir yeniden yazım değil, yönetilebilir bir proje haline gelir.

Kurucuların yaptığı en büyük mimari hata nedir?

En yaygın ve en pahalı hata, mimariyi paylaşılan bir karar değil de geliştirme ekibinin sorunu olarak ele almaktır. Kurucular mimari konuşmanın bir parçası olmadığında, seçilen varsayılanlar çoğunlukla ürünün gerçekte gitmesi gereken yer için değil, ürünün en basit yorumu için uygun olur. Hazır bulunmak, sorular sormak ve temel kararları kasıtlı olarak almak, teknik olmayan bir kurucunun geliştirme başlamadan önce yapabileceği en yüksek kaldıraçlı eylemlerden biridir.

---

Bir SaaS ürününün kapsamını belirleme sürecindeyseniz ve geliştirme başlamadan önce mimari kararların doğru olduğundan emin olmak istiyorsanız, konuşmaktan memnuniyet duyarız. Keşif sürecimiz özellikle bu kararları erken gün yüzüne çıkarmak, açıkça açıklamak ve ilk kurumsal müşteriniz doğru soruları sorduğunda yeniden inşa edilmesi gerekmeyen bir temel oluşturmak için tasarlanmıştır. Konuşmayı başlatmak için Cyberbeak ekibiyle iletişime geçin.