The fun part of a SaaS is the product. The part that decides whether you scale or spend year two rewriting everything is the architecture underneath. Here's the reference setup I'd reach for today.
A modular monolith, not microservices
Start with one well-organised application. Microservices solve organisational problems you don't have yet, and they add operational complexity you can't afford early. A modular monolith — clear internal boundaries, one deployable — ships faster and is far easier to debug.
You can always extract a service later. You can rarely un-extract one cheaply.
Multi-tenancy: shared database, row-level security
Give every row a tenant_id and enforce isolation with PostgreSQL row-level security. This is simpler and cheaper than a database per tenant, and it scales to thousands of tenants without drama.
Database-per-tenant is the right call only when regulation or extreme isolation requirements force it — and even then, not on day one.
Auth and RBAC from the start
Authentication and authorization are nearly impossible to retrofit cleanly. Decide early:
- Identity — sessions or tokens, social login, and SSO for when you go upmarket.
- Org model — users belong to organisations; permissions hang off org membership.
- Roles — a small, explicit set of roles mapped to capabilities.
Get this right once and most "can this user do this?" questions answer themselves.
Billing is a first-class feature
Bolting on billing later always hurts. Model it properly: plans, subscriptions, trials, proration and — increasingly — usage-based metering. Use Stripe Billing and a self-serve customer portal so you're not building an invoicing system by hand.
The key insight: your entitlements (what a plan unlocks) should live in your domain, with Stripe as the source of truth for money. Keep those concerns separate.
The data layer
Type safety pays for itself. A typed ORM (we use Prisma) plus validated inputs (Zod) at every boundary eliminates a whole category of production incidents. Add a cache (Redis) for hot paths once you have them — not before.
Observability before scale
You can't operate what you can't see. From day one: structured logs, error tracking, and a couple of dashboards for the metrics that matter. The first time something breaks at 2am, you'll be glad it's there.
The boring conclusion
None of this is exotic. A modular monolith, shared-database multi-tenancy, real auth, first-class billing, a typed data layer and basic observability. It's boring on purpose — boring is what scales while you focus on the product that actually differentiates you.
