The part of SaaS
that is hardest to retrofit, built first
Billing and tenancy are the two parts of a SaaS product founders most often bolt on after the fact. They are also the two most expensive to retrofit once customer data already exists. We build both first. Proper isolation between tenants. A billing system that handles plan changes, seat counts and metered usage, without silently corrupting a subscription record.
Who actually needs this
A dedicated billing and tenant system fits a SaaS product past the earliest MVP stage. Real customers whose data must never leak into another customer’s view. A pricing model more complex than a single flat monthly fee. It also fits a team that tried to retrofit proper tenancy onto an MVP, and found out how expensive that rewrite actually is. It is overkill for a true single-tenant internal tool with one customer, where the isolation problem does not exist to solve.
What the system actually does
Tenant isolation is enforced at the database level, through row-level security or a per-tenant schema, depending on scale. A bug in application code cannot leak one customer’s data into another’s results, the way an easily-forgotten WHERE clause can. Plan tiers support seat-based pricing, metered usage, or both, since many real SaaS pricing models need more than one dimension. Correct proration applies on upgrades and downgrades mid-cycle, so a customer switching plans gets charged or credited the right amount, instead of a confusing partial bill. A dunning sequence gives a failed payment a real chance to recover, before the account is suspended.
How we design isolation and billing together
We design the tenant and billing model together. How isolation works affects how billing queries usage, and deciding both at once avoids a mismatch discovered later. Isolation gets built and tested with adversarial test cases. We actively try to make one tenant’s query touch another tenant’s data, rather than trusting that application-level checks will always be remembered. Billing logic is tested against real-world edge cases before any of it touches a real subscription. A customer upgrading mid-cycle. A payment that fails and later succeeds on retry. A seat count that changes mid-month.
Where this goes wrong
Tenant isolation is the area where a subtle bug does the most damage. A query that forgets to filter by tenant does not throw an obvious error. It just quietly returns the wrong customer’s data. That is why we test isolation adversarially. We actively try to make one tenant’s request touch another’s data, rather than trusting code review alone to catch every instance. Billing edge cases are the second risk. A seat count that changes mid-billing-cycle. A plan downgrade that should trigger a partial refund. A payment that fails and then succeeds on a later retry. Each needs explicit handling, or it quietly produces an incorrect invoice that erodes customer trust when they notice. The third trap is over-engineering isolation for a scale the product does not have yet. Nobody needs a complex sharded multi-region system for a handful of tenants. We match the isolation approach to the actual scale and growth trajectory: row-level security, separate schemas, or separate databases. We do not default to the most complex option available.
Timeline and price
| Option | Price | What it covers |
|---|---|---|
| MVP | from $6,000 | Basic tenant separation, single plan tier, manual billing review |
| Production | from $10,000 | Database-level isolation, multiple plan tiers, metered or seat billing, full dunning sequence |
| Full control (handover-ready) | from $11,000 | Everything in Production plus a security review of the isolation layer, architecture documentation, and 90 days of support |
Running cost after launch depends on hosting and, where relevant, model usage, typically $20 to $150 a month for a project at this scale.
What stays yours
You own the database, the isolation and billing logic, and your payment provider account, all under your own name. We document exactly how isolation is enforced and how billing calculates each charge. A security review or a new engineering hire can verify it, rather than take it on faith. This is the same handover standard on every product we build. No proprietary platform only we can operate. No API key or hosting account left in our name after launch. A written document covers the architecture and the decisions behind it. A future engineer, yours or ours on a continuing basis, should be able to extend the system. No one should have to guess why it was built the way it was.
Related
See the development service page for our full build process. This pairs with SaaS MVP, White-label SaaS for agencies. For the engineering detail, see Multi-tenant SaaS architecture, Subscription billing with dunning. For a real build, see Multi-vendor marketplace platform demo, Factory ERP recovery, self-hosted.
Want this built for your business? Get in touch and we will scope it with a fixed price.
FAQ
How much does a SaaS billing and tenant system cost?
From $6,000 for tenant isolation, plan tiers and billing with dunning, 5 to 9 weeks. A system with metered usage billing and several plan dimensions runs $10,000 to $15,000.
What does 'isolation at the database level' actually mean?
Every query is scoped to a tenant in a way an application bug cannot bypass. We use row-level security or a per-tenant schema, depending on scale. That beats trusting every single query in the codebase to remember to filter by tenant ID.
Seat-based or metered billing, which is right for us?
Seat-based fits a product priced per user. Metered fits a product priced by usage: API calls, storage, messages sent. Many SaaS products end up needing a mix, which we design for from the start rather than assuming one model forever.
What is the stack?
FastAPI and PostgreSQL with row-level security or schema-based isolation depending on your scale, integrated with your payment provider's subscription and metering APIs.
Who owns the billing system and tenant data?
You. The database, the tenant and billing logic, and your payment provider account are all under your own control, with documentation on exactly how isolation and billing are enforced.