The Five Decisions That Define Your SaaS Architecture

Architecture is destiny

The decisions you make in the first weeks of a SaaS project will follow you for years. We've seen products hit a wall at 1,000 users because of choices made at 10. We've also seen products scale smoothly past 100,000 because the foundations were right.

These are the five decisions that matter most — and what we think about for each one.

1. Multi-tenancy model

How do you separate your customers' data? There are three common approaches:

• Single database, shared schema — all tenants in the same tables, separated by a tenant_id column. Simple to start, but requires discipline to avoid data leaks.
• Single database, separate schemas — each tenant gets their own schema. Better isolation, more complex migrations.
• Separate databases per tenant — maximum isolation, ideal for enterprise clients with strict compliance needs. Higher operational cost.

For most early-stage SaaS products, we recommend starting with shared schema and building proper row-level security from day one. Migrating later is painful — building it right early is not.

2. Authentication strategy

Auth is one of the places where reinventing the wheel is almost never worth it. We use established solutions — Clerk, Auth.js, or Supabase Auth depending on the project — because they handle the hard parts: session management, MFA, social login, and security patches.

What we do build ourselves is the authorization layer: who can do what. Role-based access control (RBAC) needs to match your product's actual permission model, which is always unique to your business.

3. Subscription and billing

Stripe is the default choice, and for good reason. But how you integrate it matters enormously.

We always build billing as a separate service boundary — a dedicated module that owns the relationship between your users and Stripe. This makes it easier to:

• Switch pricing models without breaking your product
• Handle edge cases like failed payments and dunning gracefully
• Add new plans or features without touching core product code

4. Real-time vs. polling

Does your product need live updates? A collaborative document editor does. A monthly reporting dashboard probably doesn't.

Real-time infrastructure adds meaningful complexity — WebSockets, connection management, conflict resolution. We only add it where it creates genuine user value. For everything else, smart polling with short intervals is simpler, cheaper, and easier to debug.

5. Observability from day one

The biggest mistake we see early-stage SaaS teams make is treating logging and monitoring as something to add later. By the time you're debugging a production issue at scale, "later" is too late.

We instrument every new SaaS product with:

• Structured logging — machine-readable, queryable
• Error tracking — Sentry or similar, capturing full context
• Performance monitoring — p95 and p99 response times, not just averages
• Business metrics — MRR, churn, activation rate piped to a dashboard

You can't improve what you can't measure.

---

Building a SaaS product from scratch or scaling an existing one? Let's talk about what architecture makes sense for your stage.