Multi-Tenant SaaS with Next.js and Prisma: Architecture Lessons from Production

I built Captime, a multi-tenant SaaS for Hong Kong company-secretarial firms — client onboarding, KYC/AML, document generation, e-signatures, payments, and annual filings — multi-tenant from day one. Here's the architecture that held up in production, using Next.js 15, Prisma, and NextAuth.

Pick your tenancy model deliberately

• Shared database, tenantId column on every table: cheapest to run, easiest to migrate, right answer for 95% of B2B SaaS — this is what Captime uses
• Schema-per-tenant: stronger isolation, but migrations across hundreds of schemas become an operations project
• Database-per-tenant: only when contracts or regulators demand it; cost and tooling overhead are real

Enforce isolation in one place, not everywhere

The classic multi-tenant bug is one forgotten where-clause leaking another tenant's data. Don't rely on developers remembering: resolve the tenant once per request (from the session or subdomain), then run every query through a tenant-scoped data layer — a Prisma client extension that injects tenantId into every read and write. Code review then only has to catch raw-client usage, not every query.

Add a second line of defense in tests: a suite that creates two tenants, writes data as one, and asserts the other can never read it through any endpoint.

The details that make it feel enterprise-ready

• Per-tenant branding: logo, colors, and email templates stored per tenant and applied at render time
• Encrypted integration credentials: each tenant's third-party API keys encrypted at rest (AES-GCM), never in environment variables
• Event-driven background workflows (Inngest) keyed by tenant, so one tenant's heavy job can't starve others
• A 40+ field onboarding wizard that saves progress per step — enterprise clients never finish onboarding in one sitting

Mistakes I'd avoid next time

• Don't put tenant resolution in every page — do it in one layout/middleware layer
• Don't use auto-increment IDs across tenants; they leak volume information
• Don't defer the billing-per-tenant model; retrofitting seat or usage billing hurts
• Don't let uploads share one bucket without tenant prefixes and signed URLs

Building a multi-tenant product?

I've made these decisions before, in production. See my work or describe your product and I'll tell you honestly which tenancy model fits.