B2B SaaS App Architecture: The Founder's Technical Guide

The Architecture Decisions That Matter Early

Architecture is one of those topics where getting it wrong early costs a lot to fix later. The good news: B2B SaaS architecture has become far more standardised in the 2020s. The decisions you need to make are fewer and more obvious than they were five years ago.

Here are the decisions that matter for early-stage B2B SaaS, in order.

Multi-Tenancy Model

Multi-tenancy means that multiple customers (tenants) share the same infrastructure. This is almost always the right model for early-stage SaaS. The alternative (siloed infrastructure per customer) is expensive to maintain and premature for most startups.

The two main approaches:

1. Shared database, row-level isolation All tenants' data lives in the same database. Each row has an organization_id foreign key. Row-level security (RLS) policies enforce that each tenant only sees their own data.

This is the default choice for most early-stage B2B SaaS. It's simple, cheap, and works well at startup scale. Supabase makes implementing RLS straightforward.

2. Schema-per-tenant Each tenant gets its own database schema. More complex to manage but provides stronger data isolation. Useful when customers have compliance requirements (healthcare, finance) or when tenant data sizes vary enormously.

For most startups: start with row-level isolation. Migrate to schema-per-tenant if you win a customer who requires it.

Authentication and Authorisation

Authentication (who are you?) is now a solved problem. Use an auth provider: Clerk, Auth0, Supabase Auth, or WorkOS for enterprise SSO. Don't build authentication from scratch.

Authorisation (what can you do?) is where the real design work lives in B2B apps. The common patterns:

• Role-based access control (RBAC): Users have roles (admin, member, viewer). Roles map to permissions. Simple to implement; sufficient for most apps.
• Attribute-based access control (ABAC): Permissions based on attributes of the user, the resource, and the context. More flexible; much more complex. Only build this if RBAC is demonstrably insufficient.

For early-stage B2B: implement RBAC with 3–4 roles. You can always add granularity later.

Data Model Fundamentals

Every B2B SaaS needs these tables at minimum:

• organisations (or teams, workspaces, accounts): the tenant entity
• users: individual users
• memberships: the many-to-many join between users and organisations (includes role)
• invitations: pending member invitations

Everything else is domain-specific. Build the tenant/user/membership model correctly before adding any domain tables.

API Architecture

REST vs GraphQL: For early-stage B2B SaaS, REST is almost always the better choice. It's simpler to implement, easier to secure, and easier to document. GraphQL pays off at scale when you have many different clients with different data needs. Start with REST.

API structure: Version your API from day one (/api/v1/...). You will break things; versioning gives you a clean migration path.

Infrastructure

The modern B2B SaaS stack has become remarkably simple:

• Frontend: Next.js on Vercel
• Database: Supabase (Postgres with RLS, auth, storage)
• Background jobs: Inngest, Trigger.dev, or Supabase Edge Functions
• Email: Resend or Postmark
• Payments: Stripe

This stack handles most B2B SaaS requirements to $5M ARR without significant changes. Don't over-engineer the infrastructure before you have product-market fit.

---

FAQ

Q: Should I use a monorepo or separate repos?

Monorepo for early-stage. The overhead of managing separate repos for frontend/backend/shared is not worth it until you have a large team.

Q: When should I consider microservices?

Not at the early stage. A well-structured monolith is easier to build, easier to reason about, and easier to deploy. Consider service extraction when a specific component has dramatically different scaling requirements from the rest of the app.

Q: How do I handle database migrations?

Use a migration tool (Prisma Migrate, Drizzle Kit, or Flyway) from day one. Never alter a production database directly. Migrations should be version-controlled, tested, and rolled back if they fail.

Q: What are the security essentials for B2B SaaS?

HTTPS everywhere, row-level security on the database, no secrets in client-side code, input validation and parameterised queries, rate limiting on APIs, and regular dependency updates. This is table stakes, not advanced security.