How to Build Multi-Tenant B2B SaaS: Isolation, RBAC, Billing and Audit

A multi-tenant B2B SaaS is built right when one customer can never see another customer's data, and tests prove it on every build. Put tenant isolation, role-based access, billing and an audit log into the first release, because they are the hardest parts to retrofit once real customer data exists. The examples below come from platforms RAITHub built on Next.js, TypeScript and Postgres.

This guide covers the decisions that are expensive to change later: how tenants are separated, how users and roles work, how billing connects to access, what makes an audit log trustworthy, and what enterprise buyers ask before they sign. Where RAITHub has built something similar, the platform is named next to the number. If you are looking for a team to build yours, the service page is SaaS development.

What foundations does a B2B SaaS platform need?

Features are the minimum. What makes a B2B SaaS platform is the foundation underneath: tenant isolation, access control, billing, audit, and tests that keep all four correct as the product changes.

Customers rarely praise these parts, but security questionnaires ask about every one of them, and they are the hardest to retrofit once real customer data exists.

Foundation	What "done right" means	How you can check it
Tenant isolation	The database itself refuses to return another tenant's rows	An isolation test suite that tries to cross the boundary on every build
Authentication	Organizations, memberships and single-use invites; rate-limited sign-in	Try repeated wrong passwords; try to reuse an invite
Access control (RBAC)	Roles built from named permissions, checked on the server	Log in as the lowest role and call an admin endpoint directly
Billing	Stripe handles payment; your database decides access	Replay a webhook and confirm nothing is granted twice
Audit log	Who did what, when, written in the same transaction as the change	Ask whether an admin could quietly edit an entry
Delivery safety	Branch previews, CI gates, an observability baseline	Ask what stops a failing test reaching production

Which multi-tenant SaaS architecture should you choose?

For most new B2B products, a shared schema with a tenant column and Postgres row-level security is the sensible default. Separate schemas or databases per tenant make sense when a contract or regulation demands physical separation.

Model	How it works	Strengths	Costs and risks
Shared schema + row-level security	All tenants share tables; each row carries a tenant ID and a database policy filters every query	One migration for everyone, lowest running cost, easy internal reporting, a new tenant is just a row	A missing policy is a data leak; one heavy tenant can slow others; restoring one tenant needs a filtered export
Schema per tenant	One database, a separate set of tables per tenant	Clearer separation; exporting or dropping a tenant is simpler	Every migration runs once per tenant and can leave tenants on different versions; thousands of schemas strain tooling and connection pooling
Database per tenant	Each tenant has its own database, possibly in its own region	Strongest separation; per-tenant backups, regions and keys; a heavy tenant only affects itself	Highest cost; migrations, monitoring and upgrades multiply by tenant count; cross-tenant reporting needs a pipeline

Many mature products become hybrids: most customers in the shared pool, a few large or regulated customers on dedicated databases. That move is far easier if every table carried a tenant ID from day one. For the database side, PostgreSQL vs MongoDB for SaaS explains why row-level security favours Postgres.

What row-level security does, and where it can fail

Row-level security (RLS) lets Postgres add a condition to every query on a table, whatever the application code forgets. A minimal policy:

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id', true)::uuid)
  WITH CHECK (tenant_id = current_setting('app.tenant_id', true)::uuid);

If no tenant is set, the query sees nothing, so it fails closed. The sharp edges:

• Superusers and BYPASSRLS roles ignore policies. The app must connect as a normal role.
• Table owners bypass policies unless the table uses FORCE ROW LEVEL SECURITY.
• Connection pools reuse connections. Scope the tenant setting to the transaction, or one request can inherit the previous request's tenant.
• Views run with their owner's rights by default. On Postgres 15+, use security_invoker.
• Policies need indexes that start with the tenant column.

How do you prove one tenant cannot see another tenant's data?

With tests that attack the boundary on every build, not a one-off review. The two that matter most are a CI check for tables missing a policy and an IDOR test suite.

IDOR ("insecure direct object reference") is the bug where a user changes an ID in a request, say invoice 1041 to 1042, and gets another customer's record. It is common because code often checks that you are logged in, not that the record is yours.

Sundor Skin, a B2B wholesale platform RAITHub built and deployed in September 2026, isolates every business customer the way a SaaS isolates tenants:

• Every buyer query runs under PostgreSQL row-level security scoped to that buyer (Sundor Skin).
• CI fails the build if a buyer-scoped table lacks a policy (Sundor Skin).
• A 21-case IDOR security test suite tries to read other buyers' data (Sundor Skin).
• 146 PostgreSQL tables, 77 route pages and 530+ automated tests (Sundor Skin).

Sundor Skin is not a SaaS product, but buyer isolation is the same engineering problem. See the Sundor Skin case study.

What should authentication, RBAC and SSO look like in B2B SaaS?

Users join organizations through memberships, each membership has a role, and each role is a set of named permissions checked on the server. SSO sits on top of that model when buyers ask for it.

In B2B, the customer is a company, and one person may belong to several organizations with a different role in each. Model users, organizations, memberships and invitations as separate records from the start.

Build roles from permissions, not hard-coded "is admin" checks. Sundor Skin has 12 staff roles built from 88 permission codes, and conflicting permissions are enforced in the database so no single role holds both sides of a sensitive pair (Sundor Skin). PropDesk, a property-management SaaS RAITHub built, serves 4 roles (landlord, tenant, contractor, admin) from one codebase (PropDesk).

Login is the most attacked endpoint. The RAITHub website rate-limits login with three buckets: email plus IP, per IP, and per email across IPs, which slows guessing without letting an attacker lock a real user out (RAITHub website). The limiter is database-backed and shared across serverless instances; an in-memory counter would reset per instance, multiplying the real limit.

Larger customers will ask for SSO through SAML or OpenID Connect, and sometimes SCIM to add and remove users automatically. Both fit cleanly on a proper membership model and badly on "one user, one account". More in SaaS security best practices.

How should subscription billing work in a SaaS product?

Stripe handles payments, invoices and retries; your own database decides what each tenant may use. Webhooks connect the two and must be safe to receive twice.

• Entitlements live in your database, updated from webhooks, not fetched from Stripe on every page load.
• Webhooks are idempotent. Record each event ID and ignore repeats, so a retry never grants access twice.
• Dunning is designed. Decide the retries, emails, when access turns read-only, and when data is deleted.
• Usage is counted where it happens, in your tables, so you can show a customer exactly what they paid for.

RAITHub's SaaS & MVP service includes Stripe subscriptions, metering, invoices and dunning. PropDesk uses Stripe for rent collection (PropDesk): money moving through the product rather than charging for it, but with the same webhook discipline. Step by step: how to add Stripe billing to your SaaS.

What makes a SaaS audit log trustworthy?

It records who did what, to which record and when, is written in the same transaction as the change, and cannot be quietly edited, even by an admin.

Written separately, a crash can leave a gap; editable, it proves nothing. Sundor Skin uses an append-only, hash-chained audit log written in the same transaction as each change (Sundor Skin). Each entry includes a fingerprint of the one before, so altering or deleting history breaks the chain on verification.

Not every product needs a hash chain on day one; the RAITHub website's admin area keeps a plain audit log of admin actions (RAITHub website). A B2B SaaS handling money or customer records should at least be append-only, with each tenant's admins able to view and export their own history.

What do enterprise buyers ask for before they sign?

A security questionnaire on isolation, SSO, access control, audit logs, backups and incident response. If these were designed in, the answer is a filled-in form rather than weeks of rework.

What they ask	What it means in the product	When to build it
"How is our data separated?"	Database-enforced isolation, with tests	Day one; very hard to retrofit
"Can we use our own login?"	SAML or OpenID Connect SSO; sometimes SCIM	When larger buyers ask, on a model ready for it
"Who can see and change what?"	Permission-based RBAC	Day one; customer-defined roles later
"Can we see who did what?"	A tenant-visible, exportable audit log	Write it from day one; the viewer can follow
"What if you lose data?"	Tested backups, restore procedure, runbooks	Before the first paying customer
"Do you have SOC 2 or ISO 27001?"	A formal audit of your company's controls	When your sales motion needs it

A SOC 2 report covers the company running the service, which is you, not your development partner. What your partner can do is build the controls the auditor will test. RAITHub's own status is on the security page.

What has RAITHub built that proves this?

Multi-role and multi-tenant platforms with published case studies, plus its own website held to the same bar. The numbers come from those codebases.

Platform we built	Tenancy or role problem	Measured facts
PropDesk	Property-management SaaS for landlords with 1–50 units; four user types in one codebase	130+ API endpoints, 60+ pages, 4 roles, 1,024 automated tests, 5 daily jobs, built from a 122-page SRS
Sundor Skin	B2B platform isolating every business customer with row-level security	146 tables, 21-case IDOR suite, 12 staff roles, 88 permission codes, hash-chained audit log, 530+ tests
BlockEstate	Multi-tenant listing and inquiry pipeline for agents and brokerages	Agent dashboards, lead routing, document workflow; MVP in 6 weeks
RAITHub website	Admin area, audit log and login protection on serverless hosting	400+ automated tests, three-bucket login rate limiting, pre-launch security and code review (September 2026)

The testing method is in how RAITHub tests software.

What should be decided in writing before code?

The tenancy model, the permission list and the billing states. Each one shapes the schema, and changing any of them after launch means migrating live customer data.

• Tenancy model. Shared schema with row-level security, schema per tenant or database per tenant, and which tables carry a tenant ID.
• Permissions. The named permissions, the starting roles, and any pairs no single role may hold.
• Billing states. Trial, active, past due, read-only and cancelled, and what each state allows.

At RAITHub these go into the architecture spec that you sign before production code; the phases are in how RAITHub delivers software.

What it costs to build a multi-tenant SaaS in 2026

Published agency guides put a multi-tenant SaaS MVP at roughly $40,000–$90,000 and a growth-stage platform at $120,000–$300,000. Those are market figures, not RAITHub quotes. RAITHub publishes no rates; it gives a written fixed-scope estimate after a free 15-minute technical audit.

In B2B SaaS, most of the cost sits in the foundations this guide describes, and each one is priced by how far you take it:

• Tenancy model. A shared schema with row-level security is the least expensive to build and run; a database per tenant costs several times more to build and multiplies migrations and monitoring afterwards.
• RBAC depth. A few fixed roles are a small job. Named permissions, conflicting-permission rules and customer-defined roles are a larger one, and every role needs tests that try to exceed it.
• SSO and provisioning. SAML or OpenID Connect per identity provider, and SCIM if buyers want users added and removed automatically.
• Billing model. Flat plans are simple. Seats, usage metering, proration and dunning each add states, webhooks and tests.
• Audit and isolation tests. An append-only or hash-chained audit log, a CI check for tables missing a policy and an IDOR suite are line items, not extras hidden in "QA".

Component or scope	Typical market range (2026)	What drives it
Multi-tenant SaaS MVP	$40,000–$90,000	One core workflow, organizations and memberships, simple billing
Growth-stage platform	$120,000–$300,000	Integrations, admin tooling, reporting, SSO, usage billing
Tenancy: shared schema	$8,000–$20,000	Tenant IDs, policies, transaction-scoped context, isolation tests
Tenancy: database per tenant	$30,000–$80,000	Provisioning, per-tenant migrations, monitoring and backups
Role-based access control	$8,000–$30,000	Fixed roles versus named permissions and customer-defined roles
SSO, basic integration	$8,000–$20,000	Protocols and identity providers supported; SCIM on top
Subscription billing	$3,000–$25,000	Flat plans at the low end; seats, metering and proration at the high end

Tier, tenancy, RBAC and SSO figures are from Kanopy Labs' May 2026 multi-tenant SaaS cost guide. The billing range spans that guide and MarsDevs' 2026 SaaS cost breakdown, which puts simple Stripe plans at $3,000–$5,000 and complex metered billing at $8,000–$15,000. The two guides differ on several lines, partly because they assume different scopes, so treat the table as a checklist of what to ask about rather than a budget.

A tight first release that does one job for one kind of customer is the least expensive way to learn what the rest should be. RAITHub's estimate lists the tenancy model, permissions, billing states and SSO as separate lines with written assumptions, so you can decide what waits for release two. More market detail is in the SaaS MVP cost breakdown for 2026, and how quotes work is on the pricing page.

Why RAITHub for multi-tenant SaaS

Because the tenancy and permission problems in this guide are ones RAITHub has already solved on live platforms, with tests that attack the boundary on every build. RAITHub is a founder-led software studio, founded in 2024 in Dhaka, Bangladesh, working with clients worldwide.

• Isolation proven in CI. Sundor Skin runs buyer data under row-level security, fails the build when a buyer-scoped table lacks a policy, and runs a 21-case IDOR suite among 530+ automated tests.
• Several roles, one codebase. PropDesk serves landlords, tenants, contractors and admins with 1,024 automated tests; BlockEstate isolates each brokerage as a tenant and reached MVP in 6 weeks.
• The expensive decisions are signed first. Tenancy model, permission list and billing states go into the architecture spec you approve before production code.
• Two ways to engage. A fixed-scope build for the first release, then a dedicated team as the product grows. You own the code through a present-assignment IP clause, and an NDA is signed before any detailed discussion.

When RAITHub isn't the right fit

Some SaaS projects do not need an agency yet, and some need a different one.

• You have not tested demand. A landing page or no-code tool may answer your first question faster and cheaper.
• You are single-tenant by nature. An internal tool for one company does not need multi-tenancy.
• You want developers placed inside your team under your own management. RAITHub offers fixed-scope builds and dedicated teams, not staff augmentation.
• You need a certified vendor today. RAITHub is not SOC 2 or ISO 27001 certified.
• You are building regulated fintech or health without a compliance partner. RAITHub has not shipped one and will say so.
• You want code before anything is agreed. The spec is signed first.

If your SaaS exists and is struggling, start with the code rescue playbook. If you want RAITHub to build it, the SaaS service page sets out what is included, or book the audit on the contact page.

Last reviewed: 28 September 2026.

For how RAITHub scopes and delivers multi-tenant products, see the SaaS development service.

Frequently asked questions

What does a B2B SaaS need in its first release?

Tenant isolation enforced in the database, organization-based authentication, permission-based roles, billing connected to access, and an append-only audit log, all covered by tests. Features sit on top of these, and these are the hardest parts to add later.

What is multi-tenant SaaS architecture?

A design where many customers share one running application while their data stays separate. The common models are a shared schema with row-level security, a schema per tenant, or a database per tenant, each trading cost against isolation.

Is row-level security enough to isolate tenants?

It is a strong foundation when set up correctly: a non-owner database role, forced policies, transaction-scoped tenant context and tenant-first indexes. Back it with tests, such as a CI check for missing policies and an IDOR suite.

How long does SaaS MVP development take with RAITHub?

The SaaS & MVP service has a typical timeline of 4–6 weeks at fixed scope. The exact scope is agreed in the architecture spec you sign before production code starts.

How much does a multi-tenant SaaS cost to build in 2026?

Kanopy Labs' May 2026 guide puts a multi-tenant SaaS MVP at $40,000–$90,000 and a growth-stage platform at $120,000–$300,000, with the tenancy model alone ranging from $8,000 to $80,000. These are market figures; RAITHub gives a written fixed-scope estimate after a free 15-minute audit.

Does RAITHub build SSO for SaaS products?

SAML or OpenID Connect SSO is part of what RAITHub scopes for SaaS platforms, on an organization and membership model. Whether it belongs in your first release depends on your buyers and is decided in the spec.

How does RAITHub handle subscription billing?

Stripe for subscriptions, metering, invoices and dunning, with entitlements stored in your own database and webhooks processed idempotently, so a repeated event never charges or grants access twice.

Is RAITHub SOC 2 certified, and who owns the code?

RAITHub is not SOC 2 or ISO 27001 certified; it follows aligned practices. You own the code: full IP is assigned to you through a present-assignment clause, and an NDA is signed before any detailed discussion.