What building a SaaS platform costs: budget, timeline and the parts people forget
The budget for a SaaS platform: an MVP with payments in 8–12 weeks, a full multi-tenant product with an admin panel and white-label in 4–6 months. What makes up the price and why billing is more expensive than it looks.
In short. An MVP of a SaaS platform with payments and basic analytics takes 8–12 weeks. A full multi-tenant product with an admin panel, integrations and white-label takes 4–6 months to production, with releases every two weeks, and costs roughly twice as much. What makes SaaS different from an ordinary B2B system in money terms: you pay for what the user never sees, the isolation of data between tenants and the billing.
We quote in roubles, so the figures below are given as proportions and timelines rather than converted amounts — convert at the rate of the day if you need an absolute number, or ask us for a quote.
What the budget is made of
| Line | Share of budget | What is inside |
|---|---|---|
| The product itself | 35–45% | What the customer pays for: the main working scenario |
| Multi-tenancy and isolation | 15–20% | Data separation, roles, per-tenant settings |
| Billing and payments | 15–20% | Plans, subscriptions, trial period, the payment provider, invoices |
| Admin panel and support | 10–15% | Managing tenants, handling tickets, manual operations |
| Launch and stabilisation | 10–15% | Load, monitoring, the first weeks of operation |
The third line surprises most clients. Payments feel like “connect the acquirer in a week”. In reality it is a plan matrix, moves between plans mid-period, a trial, an overdue payment, refunds, invoices for corporate customers, and a separate scenario for each of those cases.
Three scenarios
MVP with payments, 8–12 weeks. One main scenario, one or two plans, sign-up, payment, basic analytics for the owner. The goal is not to show the product but to get the first paying customer and check that they pay a second time.
A working SaaS, 4–6 months. Several plans, roles inside a tenant, company-level settings, an admin panel, integrations, exports. This is where most products that reached revenue live.
SaaS with white-label and partners. The customer sells the product under their own brand, which needs their own domains, their own styling, partner permissions and settlements with them. That is a separate product on top of a product and has to be estimated separately.
What moves the estimate most
The data isolation model. A shared database with a tenant column is cheaper to build but limits you on non-standard requirements. A separate schema or a separate database per tenant costs more at the start and less where tenants demand their own settings and exports. The decision is made once and is hard to undo. The options are compared in multi-tenant architecture.
How complicated the plan model is. Two plans, monthly and yearly, are cheap. Plans with user-count limits, operation bundles, overage charges and bespoke terms for large accounts cost several times more, because every rule has to be calculated, shown to the user, and recalculated on a plan change.
The number of integrations on the customer side. In B2B SaaS the customer almost always wants an exchange with their own accounting system. One such exchange is a project in itself — see what an accounting integration costs — and in SaaS it is multiplied by the variety of configurations across customers.
What inflates a project quietly
An admin panel treated as an afterthought. Investors are not shown it, so nothing is budgeted for it. Later it turns out that support cannot extend a subscription by hand, cannot see what the customer sees, and cannot fix an error in the data. Every ticket becomes a developer’s task.
No scenario for “the customer stopped paying”. What happens to the data when a subscription ends: access blocked, read-only kept, data deleted after N days. That is a product decision, but it has to be made mid-development and it rewrites part of the logic.
Load calculated from the first customer. An architecture designed for ten companies rarely survives a hundred without rework. There is no point budgeting for a thousand either, but the difference between ten and a hundred has to be thought through in advance.
What brings the cost down
Hand the commodity parts to ready services. Payment provider, mailing, file storage, analytics, monitoring. Custom development is justified only in the product part.
One plan at the start. The plan matrix is the thing most certain to change after the first sales. Designing it in detail before there are customers means paying for the work twice.
An MVP covering one scenario. The point of an MVP in SaaS is not a set of features but the check that someone pays for the product repeatedly. Anything that does not lead to that check can be postponed at no cost.
What ownership costs
This matters more for SaaS than for an internal system, because the product lives continuously. The benchmarks:
- development and support: 20–30% of the build cost per year. Higher than for internal systems: the product competes and has to keep moving;
- infrastructure: a modest monthly figure at the start that grows with the number of tenants;
- the payment provider’s fee is a separate line, and it belongs in the unit economics from the beginning rather than after the first receipts.
How to compare proposals
- Which isolation model is planned, and why that one.
- What billing covers: only taking payment, or plans, plan changes, trials and invoices.
- Whether there is an admin panel, and what it can do without a developer.
- Whose time is needed on the customer side, and how much.
- What support costs per year and what it includes.
An estimate that does not answer points two and three usually means they were not counted, and they will surface mid-project.
Common questions
Can SaaS be built on a small budget? A prototype can. A SaaS with real payments and several tenants cannot: billing and data isolation alone take about a third of the budget.
What counts as an MVP? The version the first customer paid for and is using in their second month. Everything else is a demo.
Build on a no-code platform or from scratch? If the product fits a builder, build it on the builder and test demand. Custom development is justified when the product part is genuinely unique and the builder would need more than a third of it reworked.
Why is the range so wide? Because “SaaS” describes both a single-scenario service and a platform with a partner network. Before the product has been examined, a range is honesty rather than an evasion.
The one piece of budget advice
Inside the range, the price is set by the isolation model, the complexity of the plans and the number of customer-side integrations.
Do not economise on billing and on the admin panel. Those are the parts nobody sees from outside and without which the product can neither be sold nor supported.
How we do it: SaaS platform development.
Facing a similar problem?
Tell us what you are building. We will walk through the architecture and give you a budget range in one call.