Multi-tenant SaaS architecture: the decisions that avoid a rewrite

Retrofitting multi-tenancy, billing or role-based access into a single-tenant app is the most expensive rewrite in software, and most startups do it twice. The reason is not ignorance; it is that these concerns feel premature when there is one customer. They are not. They are cheap to decide early and ruinous to change later. This guide sets out the decisions, the options for each, the ones we make by default after building and running our own SaaS suite, and how AI features change the picture.

Decision 1: how tenants are isolated

Default for most products: shared database with a tenant key enforced by row-level security in Postgres or an equivalent guard in MongoDB, plus a hybrid path for enterprise tenants later. The choice you cannot easily reverse is skipping the tenant key entirely.

Decision 2: billing and metering from day one

Plans, trials, upgrades, dunning and invoices are a product in themselves. Use Stripe for USD and Razorpay for INR with GST invoicing, and write usage events per tenant into a metering table from the first release even if you only bill flat plans today. Usage metering is what lets you price AI features and API calls later without a migration. SaaS billing in India has its own quirks: GST-compliant invoices, INR and USD, and TDS on some B2B payments.

Decision 3: identity, roles and audit

Enterprise buyers require SSO, granular roles and audit logs, and they ask about them in the security questionnaire before the demo. Design roles as permissions on resources, not as a single admin flag; log who did what, when, to which tenant. Adding SSO later is manageable; redesigning permissions later touches every screen.

Decision 4: environments and deployment

Separate development, staging and production from the start, infrastructure defined as code, CI/CD that deploys on merge, feature flags for progressive rollout, and backups you have actually restored. None of this is optional once you have paying tenants, and all of it is cheaper on day one.

Decision 5: API-first

Build the UI as a client of the same API partners and integrations will use. It keeps behaviour consistent, enables webhooks and a public API when demand arrives, and, importantly now, gives AI copilots a permissioned surface to act through. Products with an API-first backend add a copilot in weeks; products without one need a refactor first.

Decision 6: the AI layer

AI features introduce their own tenancy questions: prompts, retrieval indexes and logs must be isolated per tenant; usage must be metered per tenant; and the answer to "does our data train your models?" must be a documented no. Design the AI service as a separate component beside the backend, calling the same API with the user's token, so isolation is inherited rather than reinvented. See LLM Application Development.

The stack we use and why

React or Next.js on the front, Node.js on the back, MongoDB Atlas or Postgres, Redis for queues and caching, Stripe or Razorpay for billing, AWS or Vercel for hosting. It is the same stack that runs our own TheEazy suite in production, which means the tenancy, billing and role patterns have been tested by real customers, not by a template. Full-stack conventions are on the Full Stack Web page.

Migrating single-tenant to multi-tenant

If you already have a single-tenant app, the migration is: introduce a tenant key, isolate data by row or schema, centralise configuration and billing, put a façade in front, and move customers in waves with reconciliation. It is a modernization project with the same discipline as any other; see Application modernization vs rewrite.

What it costs

A production multi-tenant SaaS at Eazyware starts at $31,500 (₹20.8 lakh) for a focused product and scales with modules, integrations and design; a six-week Launch 6 MVP is fixed-price at $26,500–45,500 and includes the tenancy, billing and roles foundation so nothing has to be retrofitted. Ranges are on the pricing page.

A checklist for week one

• Tenant key on every table and enforced at the data layer
• Roles as permissions on resources; audit log table
• Billing provider integrated with a metering table, even for flat plans
• Dev, staging, production; infra as code; CI/CD; feature flags
• API-first backend with the UI as a client
• AI service separate, calling the API with the user's token
• Backups restored once, on purpose

A worked example: a field-service SaaS

A scheduling and job-management product for field-service businesses started with a shared database and tenant keys enforced in the ORM, roles as permissions on resources, Stripe billing with a metering table, and an API-first backend with the React UI as a client. When enterprise buyers arrived, SSO was added in a sprint and the permission model needed no change. When AI arrived, a copilot was built as a service beside the backend calling the same API with the user's token, so tenant isolation was inherited and metering was already there to price it as a tier. None of that was foresight about AI; it was the ordinary discipline of deciding tenancy, billing and roles in week one.

Operational habits that keep a multi-tenant system healthy

• A tenant-scoped test suite that runs negative cases: tenant A must never read tenant B
• Migrations rehearsed on a production copy with tenant sampling
• Per-tenant dashboards for usage, errors and cost, especially AI cost
• Feature flags per tenant so betas and enterprise-only features are configuration, not code branches
• Backups restored on a schedule, not only when something breaks
• A published sub-processor list and data-processing terms for enterprise questionnaires

When to talk to us

Before the first line of code if you are starting; before the first enterprise deal if you are single-tenant; and before the first AI feature if your backend is not API-first. Each of those is a point where a week of design saves a quarter of rework. The SaaS development page covers the build, Product & Platform Development the platform concerns, and the SaaS industry page the AI features that pay for themselves.

Team and timeline

A SaaS foundation is an architect for the tenancy and billing model, two full-stack engineers, a designer and a delivery lead; an AI engineer joins when the product includes AI features. The foundation itself, tenancy, roles, billing, environments and the API, is two to three weeks inside a longer build, and it is the part that should never be rushed. Everything after it is faster because nothing has to be retrofitted.

Before you start: a checklist

• Decide the tenant isolation model and enforce it at the data layer
• Design roles as permissions on resources with an audit log
• Integrate billing with a metering table from the first release
• Set up dev, staging and production with infrastructure as code
• Make the UI a client of the same API partners will use
• Keep the AI service separate, calling the API with the user's token
• Restore a backup once, deliberately, before launch

Enterprise questionnaires: what they will ask

Tenant isolation model and how it is enforced; encryption in transit and at rest; SSO and role granularity; audit log retention; backup and restore testing; data residency options; sub-processor list; incident notification times; and, increasingly, whether AI features isolate prompts and retrieval per tenant and whether customer data trains models. A SaaS built on the decisions above answers every one of those in a paragraph. A SaaS that deferred them answers with a roadmap, which is how enterprise deals stall. Writing the answers down before the first questionnaire arrives is a good discipline; publishing them, as our own Security page does, is better.

Related reading

Related reading: What a six-week AI MVP contains for how this foundation fits a fixed-price launch, Why AI copilots inside SaaS beat chatbots for the AI layer, and Application modernization vs rewrite for migrating an existing product.