Multi-tenant SaaS architecture decisions

Reorigin builds SaaS from Istanbul. A production SaaS MVP on our service page is planned at 10–16 weeks and $40,000–$120,000. Those are planning bands, not a quote. This note is the architecture conversation we have before that band becomes a proposal: isolation, identity, billing, and what is deliberately left out of version one.

What “tenant” has to mean

A tenant is the customer organization that pays, invites its own users, and must not see another customer’s rows. A user is a person inside that organization. Mixing the two is how admin screens leak. If a solo founder is the only user today, the data model should still have an organization, because the second seat is the moment the product becomes SaaS rather than a single-player tool.

We name the tenant key before we name the UI kit. Every table that holds customer data carries it, or it lives in a schema or database that already implies it. Reports, exports, background jobs, and search indexes use the same key. A filter applied only in the React view is not isolation.

Three isolation models, and when each is honest

Shared schema with a tenant column is the default for an MVP. One database, one migration path, the lowest operational cost. It is the right model when customers are similar, no contract yet demands a dedicated database, and the team can review every query. The failure mode is a missing predicate. We treat that as a review rule: a query against tenant data that does not constrain the tenant does not merge.

Schema-per-tenant is the middle step. It helps when a customer needs a restore of only their data, or when a migration must roll out to one organization first. It costs more to operate. We do not start here because a diagram looks more “enterprise.” We start here when a named customer’s contract or restore requirement cannot be met by a column.

Database-per-tenant is for a residency, a regulator, or a customer who will pay for the isolation. It is a hosting decision as much as a schema decision. EU-only processing, if the contract requires it, is a place the database runs, not a flag in a settings table. Most first releases do not need this, and pretending they do burns the 10–16 week band on infrastructure.

Identity and billing are part of the model

Sign-in should resolve to a user and a tenant, not to a global email that happens to belong to one company this week. Invitations, roles, and “which organization am I in” are product surface, not a later hardening task. If the first customer is a company with an identity provider, SSO is a slice we scope explicitly. It is not assumed free inside the MVP band.

Billing should record the plan and the usage event even when the first price is a flat subscription. Changing from “per organization” to “per seat” or “per API call” is a package change. It should not require a new database. We store the events you might invoice. We do not pick your price list.

What we leave out of the first release

A white-label domain for every tenant, a marketplace of integrations, and a custom workflow builder are the usual items that make an MVP miss production. The first release needs one tenant to sign up, invite a colleague, do the core job, and be billed or marked for billing. Admin tools for your own team — impersonation with an audit line, a way to see a failed job — matter more than a second theme.

Isolation is a query rule and a restore story. It is not a paragraph in the pitch deck.

Onboarding is the other half. A tenant who cannot reach the first value without a founder on a call will not survive the second tenant. We write the empty states and the invitation email as part of the slice, because they are how the data model meets a person.

How we use this on a project

Discovery writes down who the tenant is, what they must not see, and whether any contract already names a region or a dedicated store. Architecture then picks one isolation model and the identity provider. The build ships a vertical slice: sign-up, invite, the core record, and a billing or plan marker. That is the same shape described on the SaaS platform development page. If the product is learning software sold to many schools, the EdTech page is the sector view of the same decision. Data products that expose an API to outside callers are closer to DaaS than to a classic seat-based SaaS, and the tenant boundary is drawn around the caller instead of the seat.

We will say in discovery if a single-tenant deployment is the honest first step — one design partner, no self-serve, a contract that wants a private environment. Multi-tenancy is a cost you take when the second customer should not require a second deployment. It is not a badge.

Related reading: KVKK and GDPR for SaaS built in Turkey, and how we work if you want the delivery sequence rather than the data model.