SaaS architecture isn't an abstract technical decision. It's a series of choices that determine your development velocity, infrastructure costs, scalability — and future technical debt. These decisions are made at the start of a project. They're hard to undo later.
1. Multi-tenant or Single-tenant?
This is the foundational decision. In a multi-tenant model, all your customers share the same infrastructure: one database, one set of servers, one application instance. You isolate data logically (by customer identifier). In a single-tenant model, each customer has their own instance.
Multi-tenancy is the norm for B2C SaaS and most B2B SaaS: divided infrastructure costs, unified deployments, centralized maintenance. Single-tenancy is required when regulation demands it (healthcare data, defense) or when the customer has sufficient negotiating power to contractually require it.
Common mistake: starting single-tenant "to simplify" and then trying to migrate to multi-tenant at 10,000 customers. That's a 12–18 month project nobody wants to do.
2. Monolith or Microservices?
The honest answer: for most early-stage SaaS products, a monolith is the right choice. Microservices introduce operational complexity (orchestration, distributed observability, managing cascading failures) that teams of 2–5 developers cannot productively absorb.
Start with a modular monolith: well-organized code divided into functional domains with clear interfaces between modules. When a specific module becomes a bottleneck — in performance or team velocity — that's the moment to extract it into an independent service. Not before.
3. Multi-tenant Data Isolation Strategy
If you're going multi-tenant, three patterns exist:
- Schema isolation: one SQL schema per customer in the same database. Strong isolation, per-customer migration possible, but complex queries and migrations.
- Row-level isolation: all tables have a
tenant_idcolumn. Simpler, but fragile if a bug forgets the tenant filter. - Database isolation: one database per customer. Maximum isolation, high infrastructure costs.
For most cases, row-level isolation with Row Level Security (RLS) at the database level (natively supported by PostgreSQL) offers the best balance.
4. Authentication and Identity Management
Don't build your own authentication. Password management, tokens, sessions, SSO, MFA — this is a complex security domain where mistakes are costly. Use a proven identity service (Auth0, Clerk, Supabase Auth) and focus on your core business domain.
Think about enterprise needs from day one: SAML SSO, SCIM provisioning, granular role and permission management. Implementing RBAC (Role-Based Access Control) after the fact is a major refactoring effort.
5. Observability from Day 1
Observability isn't optional — it's what allows you to understand what's happening in your production system. Three pillars: structured logs (JSON, with context: tenant_id, user_id, request_id), metrics (response times, error rates, resource saturation), and distributed tracing.
Adding observability after the fact on a system with tens of thousands of lines of code is a project in itself. Wiring up a tool like Datadog, New Relic, or an open-source stack (Prometheus + Grafana + Loki) from the start costs a few days — and saves weeks during the first serious production incident.
These Decisions Aren't Easily Reversible
The Valtieri team has been building SaaS products for several years. These five decisions are part of the scoping process we systematically run with clients at the start of a project. If you're starting a product or inheriting an architecture worth questioning, let's talk.