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, and the two most expensive to retrofit once customer data already exists. We build both first: proper isolation between tenants and a billing system that handles plan changes, seat counts and metered usage without silently corrupting a subscription record.
What it is and who needs it
A dedicated billing and tenant system fits a SaaS product past the earliest MVP stage, with real customers whose data must never leak into another customer’s view, and a pricing model more complex than a single flat monthly fee. It 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 is inside
Tenant isolation enforced at the database level, through row-level security or a per-tenant schema depending on scale, so 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 that support seat-based pricing, metered usage, or both, since many real SaaS pricing models need more than one dimension. Correct proration 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 that gives a failed payment a real chance to recover before the account is suspended.
How we build it
We design the tenant and billing model together, since how isolation works affects how billing queries usage, and deciding both at once avoids a mismatch discovered later. Isolation is built and tested with adversarial test cases, actively trying 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: a customer upgrading mid-cycle, a payment that fails and later succeeds on retry, a seat count that changes mid-month, before any of it touches a real subscription.
What to watch
Tenant isolation is the area where a subtle bug does the most damage, since a query that forgets to filter by tenant does not throw an obvious error, it just quietly returns the wrong customer’s data, which is why we test isolation adversarially, actively trying 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, building a complex sharded multi-region system for a product with a handful of tenants; we match the isolation approach, row-level security versus separate schemas versus separate databases, to the actual scale and growth trajectory rather than defaulting 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 $17,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 you own at the end
You own the database, the isolation and billing logic, and your payment provider account under your own name. We document exactly how isolation is enforced and how billing calculates each charge, so 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, and a written document covering the architecture and the decisions behind it. A future engineer, yours or ours on a continuing basis, should be able to extend the system without having 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 that cannot be bypassed by an application bug, using row-level security or a per-tenant schema depending on scale, rather than 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.