Most vendor blog answers give a single low-ball number for an "MVP" and ignore ongoing run costs; that creates bad decisions. A defensible board number starts with the tenancy model: pooled (row-level), schema-per-tenant, or siloed (separate DB/cluster), because each multiplies operating and compliance costs by different factors.
If you accept one data point: a production-grade multi-tenant platform that supports growth to thousands of accounts typically costs between $300k and $3.5M of 3-year TCO depending on tenancy model and compliance. Engineer economics matter: a senior US-based engineer is roughly $200k loaded/year; a single extra full-time engineer therefore costs you $600k across three years.
Direct answer: a practical 3-year TCO. Expect $250k–$450k for a founder MVP on pooled tenancy, $1.2M–$1.8M for a Series A growth platform on schema-per-tenant or hybrid isolation, and $2.5M–$5.0M for an enterprise-grade siloed architecture with SOC 2 and per-tenant clusters. These ranges include initial engineering, infra and SaaS licenses, and run-rate engineering.
Two accounting frames anchor every estimate: (1) project cost to deliver the platform (the build phase), and (2) annual operating cost (hosting, SaaS, backups, and ongoing engineering). Use 3-year TCO = project cost + 3 × annual run rate when you present to investors; it’s simple and captures carry cost.
Engineer-line-item math: a senior engineer loaded at $200k/yr is $16.7k/month. A 6-month, 3-engineer project is therefore ~24 engineer-months = $400k in labor alone. Add an architect/lead for 3–6 months ($60k–$120k), QA/DevOps ($30k–$90k), and you’re at $600k–$720k before vendors and infra.
Vendor and infra deltas change the totals quickly: a Neon or PlanetScale managed Postgres tier for small scale runs $200–$1,000/month; enterprise tiers and per-tenant clusters are $5k–$25k/month. Auth and SSO via Clerk/Auth0/WorkOS will add $0–$3k/month in early stages and $5k–$20k/month at enterprise scale. SOC 2 readiness costs $40k–$120k one-time plus $15k–$40k/year audit costs.
Tenancy models and where costs hit
Pooled (row-level) tenancy minimizes engineering and infra cost up front because you run one schema and one set of services. It’s the cheapest to build and operate: initial projects often land $120k–$220k and annual ops under $60k, yielding a 3-year TCO in the $250k–$450k range. Downside: noisy neighbors, harder per-tenant performance guarantees, and higher blast-radius for data incidents.
Schema-per-tenant or hybrid isolation moves cost to the middle: development grows because migration tooling, tenant provisioning, and schema evolution logic are non-trivial. Expect a 30–70% uplift in initial engineering compared to pooled tenancy. Annual infra cost is higher because you may need more disk and connections; plan $60k–$200k/yr at scale.
Siloed (DB-per-tenant or cluster-per-tenant) is the most expensive. Build complexity rises with orchestration: per-tenant backups, per-tenant scaling, and network isolation add engineering months. Initial projects commonly range $1.2M–$2.0M and annual ops $200k+, which produces 3-year TCOs north of $2.5M when you factor in SOC 2 and dedicated-host premiums.
- Cost driver — engineers: $200k loaded/year per senior engineer
- Vendor delta — managed Postgres: $200–$25,000/month depending on plan and tenancy model (Neon, PlanetScale)
- Compliance delta — SOC 2 readiness: $40k–$120k one-time; audit $15k–$40k/year
- SaaS delta — SSO/Auth: $0–$20k/year (Clerk, Auth0, WorkOS)
- Operational delta — maintenance FTEs: 0.2–2.0 FTEs depending on tenancy and SLAs
Named example: a Series A SaaS wanting per-customer performance SLAs and SAML/SCIM must budget dev work to integrate Stripe Billing, implement per-tenant rate limiting, and support SCIM provisioning. The integration and testing across billing, SSO, and metering typically add $60k–$150k to an initial project.
Operational hidden costs are real: egress and backups scale with tenant data. If your platform stores large user files, S3 egress and storage can exceed compute costs. A mid-sized app with 1TB of customer data will add $1,200–$3,600/year in storage and $3,000–$20,000/year in egress depending on access patterns and region.
The tenancy model is the architecture decision that turns one developer-year into $400k of run cost or $1.5M — pick it with the business case in front of you, not by imitation.
Three board-ready budget scenarios (3‑year TCO)
Scenario A — Founder MVP (pooled tenancy): Project build $120k; annual ops $64k (infra $12k, SaaS $6k, 0.2 FTE ops $40k); 3-year TCO = $312k. Use case: market validation, <1k accounts, no enterprise SLAs, Stripe billing, Clerk SSO.
Scenario B — Series A growth platform (schema-per-tenant/hybrid): Project build $600k; annual ops $284k (infra $60k, SaaS $24k, 1.0 FTE maintenance $200k); 3-year TCO = $1.45M. Use case: >10k accounts, per-tenant performance needs, team-run migrations, basic SOC 2 controls.
Scenario C — Enterprise-grade platform (siloed tenancy, SOC 2, multi-region): Project build $1.5M; annual ops $625k (per-tenant clusters and enterprise DB $200k, 2.0 FTE operations $400k, audits $25k); 3-year TCO = $3.375M. Use case: regulated customers, hard SLAs, dedicated tenant clusters, annual compliance audits.
What this means for a CTO or technical founder
You must translate technical choices into budget artifacts your CFO or board can understand: choose a tenancy model, then produce a three-row table with (a) project cost, (b) annual run rate, (c) 3-year TCO. That single artifact resolves most vendor vs. build debates because it surfaces the engineering multiplier.
If you need enterprise revenue — require SOC 2, SAML/SCIM, and tenant isolation — budget for the enterprise scenario from day one. Trying to retrofit siloing later almost always costs more than building it correctly: migration tooling, customer data exports, and downtime windows usually add 30–60% to your original engineering estimate.
If you’re proving product-market fit, start pooled, instrument telemetry, and set a clear migration budget and timeline. Measure tenant size: 80% of accounts are often low-usage, 20% are heavy; put those heavy accounts behind a paid isolation upgrade path rather than hard-coding siloed tenancy across the product.
Practical selection criteria and quick answers
- If customers demand dedicated performance or data residency, plan for schema-per-tenant or siloed tenancy and budget >$1.2M 3-year TCO.
- If you’re settling PMF, use pooled tenancy and aim for <$450k 3-year TCO to validate without over-committing engineering.
- Reserve 20% of your initial project budget for migration, observability, and incident remediation; these are the most common overruns.
Operational checklist before you sign a vendor or a contractor: estimate per-tenant storage and egress for 3 years, model peak RPS and provisioning latency targets, and decide your compliance floor (none, SOC 2, ISO 27001). Each answer changes the TCO materially.
If you want a short engagement to convert these ranges into a numbered roadmap and a fixed-scope estimate, consider hiring senior platform engineers to produce the plan and stub code. Our platform team can produce a 6–8 week architecture + BOM that turns these ranges into a line-item budget: see platform engineering.
- Produce a 3-year TCO that separates project cost and annual run rate and use it for board decisions.
- Choose pooled tenancy for PMF, schema-per-tenant or hybrid for scale, and siloed only when customers pay for it.
- Budget SOC 2 as a project line item: $40k–$120k to get ready and $15k–$40k/year to maintain.
- Model per-tenant storage and egress early; these are the most frequent unexpected run-rate drivers.
A final practical distinction: know whether you’re buying a capability or a calendar. An off-the-shelf SaaS product that covers 80% of your needs and costs $60k/year is often cheaper than hiring two senior engineers at $400k/year to replicate it. But if that missing 20% is revenue-critical — a compliance or isolation requirement — build with the appropriate tenancy model.
Deciding to build is also deciding to accept operational complexity. If you want help converting these numbers into a procurement-ready SOW and a migration plan, the fastest path is to bring in senior platform engineers who have shipped tenancy migrations and compliance programs before—start with a discovery that delivers clear line items and milestones.
Should you isolate tenants with row-level security or a schema per tenant?
Short answer: most early SaaS products should start with a shared schema and row-level isolation, and move only their largest or most regulated customers to a separate schema or database when a contract requires it. That keeps one migration path and one deploy for everyone while you find product-market fit.
Row-level isolation puts every tenant in the same tables with a tenant ID on each row. In PostgreSQL you can enforce it in the database with row security policies (CREATE POLICY plus ALTER TABLE ... ENABLE ROW LEVEL SECURITY), so a query that forgets its tenant filter returns nothing instead of another customer's data. Two details matter: superusers and roles with BYPASSRLS skip policies, and table owners do too unless you set FORCE ROW LEVEL SECURITY, so your application should not connect as the table owner (PostgreSQL documentation).
Schema or database per tenant gives stronger separation, per-tenant backups and restores, and a clean answer for customers who ask where their data lives. The cost shows up in operations: every migration runs once per tenant, connection pools and monitoring multiply, and onboarding a tenant becomes a provisioning job instead of an insert.
The budget effect is that a hybrid model (shared by default, dedicated on request) is usually the cheapest way to sell to both small teams and enterprise buyers. We compare the two approaches in more depth in schema-per-tenant vs. row-level multi-tenant architecture and multi-tenant data isolation tradeoffs.
