What pushes a build toward database-per-tenant
The customer decides this, not taste. A hundred small accounts on a shared schema are cheap to run. Three hospitals that each demand their own database are a silo, and build and hosting costs rise with each one. Many products end up hybrid: shared infrastructure for the long tail, dedicated infrastructure for the few accounts that pay for it. AWS’s guidance describes the same split. The first release stays cheap if its code can make that move later without a rewrite.
The figure below sets the three patterns side by side.
Billing and subscriptions
Billing is where SaaS development cost most often catches a first-time founder out. It looks like a weekend of work, because taking a card is easy. The expensive part is everything around the charge. Think of plan changes mid-month, proration, failed payments and retries, cancellations, tax, invoices, and the page where customers update a card. Each of those is a state your database has to hold and reconcile with the payment provider.
Buying beats building for most of this. Stripe’s pricing page lists 0.7% of Billing volume for Stripe Billing on pay-as-you-go (checked 11 October 2026), with card processing priced separately. On $50,000 of monthly billing, that is $350 a month, far less than the engineering time to rebuild proration and dunning yourself. The build cost then moves to the integration. You need webhooks you can trust, an entitlements layer that turns “plan = Pro” into feature limits, and tests on every path where a bug costs you a customer or a refund.
Usage-based pricing costs more to build than flat tiers, because you have to measure, store and explain usage before the invoice goes out. Launch with two or three flat plans and add metering when customers ask for it, and the first release gets cheaper.
Sign-in, SSO and the admin panel
Email-and-password sign-in with roles and a password reset belongs in the first release, inside the ranges above. Enterprise sign-in is the part of SaaS development cost that founders forget to budget. A buyer’s IT team will ask for single sign-on through their identity provider, and often for automatic user provisioning too. Building SAML by hand is slow and fiddly, so most teams buy it. WorkOS, for example, lists $125 per connection for the first 15 Single Sign-On or Directory Sync connections and $100 each for connections 16 to 30 (checked 11 October 2026). The page gives no billing period, so confirm it before you model margins. Because the price is per customer connection, it grows with the enterprise deals you win. Write it into your own pricing as an enterprise feature instead of absorbing it.
The admin panel is the other quiet cost. Support uses it to search an account, change a plan, check usage and impersonate a user to reproduce a bug, with an audit trail of who did what. Teams that skip it spend the saved weeks answering tickets through a database console. We treat it as part of the first release.
Compliance: the SOC 2 line
Most SaaS products do not need SOC 2 on day one. They need it when the first larger customer sends a security questionnaire. A SOC 2 Type 1 report checks whether controls are designed properly at a single point in time. A Type 2 report checks whether they worked over a period, which Secureframe puts at typically three to twelve months (checked 11 October 2026). Because that window has to run its course, a Type 2 cannot be produced in a hurry.
The auditor’s fee is only part of the bill. Scrut, a compliance-automation vendor, puts US auditor fees at roughly $5,000 to $25,000 for Type 1 and $7,000 to $50,000 for Type 2 (page updated 5 August 2026). Its figures leave out tooling, penetration testing and your own staff time. Treat them as a vendor’s estimate, not a quote.
The engineering side is cheaper if you plan for it early. That means audit logs, role-based access, encrypted backups, a documented deploy process and a way to offboard a user in minutes. Build those in from the start and the audit mostly collects evidence. Add them after the questionnaire arrives and the work lands in the middle of a sales cycle.
What a SaaS costs to run after launch
The build is a one-time number; running the product is a monthly one. That monthly figure depends on the tenancy pattern more than on the framework. Shared infrastructure grows slowly with usage. A silo grows with every customer, because each one carries its own database, backups and monitoring.
The line items we see most often are hosting and the database, error tracking and logs, transactional email, the payment provider’s percentage, and the people on call when something breaks. We do not give a typical monthly figure, because traffic and data volume swing it too far to be useful. Instead, ask for a cost-per-tenant estimate at 10, 100 and 1,000 customers before you choose a tenancy model. If a vendor cannot produce one, the architecture has not been thought through. For the wider picture, what custom software costs on average covers what owning it adds to the build price in the first year.
Phasing the build to keep SaaS development cost down
The cheapest order buys information first and spends heavily later.
- Prototype and scope. A clickable prototype and a written scope, so the first estimate rests on screens rather than a description.
- One journey, tenancy done properly. Ship the single journey customers will pay for, with tenant isolation, roles, flat-rate billing and the admin panel. This is the Lean or Standard row of the table, depending on how much that journey has to carry.
- The paid features. Add integrations, reporting, usage limits and a second or third plan as real customers ask for them.
- Enterprise readiness. SSO, audit logs and the SOC 2 work, timed to when a signed deal needs them.
- Scale and cost control. Move the few demanding accounts to dedicated infrastructure and tune what the monitoring shows is expensive.
Two things inflate the number more than any feature. One is changing the tenancy model after launch. The other is adding scope without re-pricing it, which is why every change gets a written price before anyone builds it. If you are still before revenue, our fixed-price MVP build for startups fits better than a platform build, and your written scope will say so plainly.
SaaS development cost runs about $13,500 to $41,000 for a first release on our calculator, and $18,000 to $55,000 with billing, reports and integrations. Indicative ranges like these are a starting point. What moves a quote within them is mostly decisions, not screens: how tenants are kept apart, how billing works, who needs single sign-on, and which audit a buyer will ask for.
Below are those decisions in the order they usually arrive, from first release to a platform with paying enterprise accounts. For each one we say where the money goes, so you can check a quote line by line. It is the same order we follow when we scope multi-tenant SaaS product development for founders and product teams. If you only need a rough number for a smaller build, start with our 2026 breakdown of MVP pricing.
What SaaS development cost looks like by stage
The estimator on our public software development cost calculator has a SaaS product option. With a web application, a clean UI and no add-on features chosen, it prices three sizes as below. It labels every range indicative, and a written scope replaces the range with a real number.
The Standard row is the same $13,500 to $41,000 over 10 to 16 weeks that the calculator’s benchmark table and our pricing page list for a SaaS product’s first release. Tick the payments, dashboards and integrations options, the add-ons a full product usually needs, and the Standard range becomes $18,000 to $55,000 over 12 to 19 weeks. For comparison, the same estimator prices a Startup MVP, a plain web app with one core journey, at $6,500 to $16,500. The SaaS product sits at roughly two to two and a half times that. The difference is what multi-tenancy adds: every table scoped to an account, plans and limits the code enforces, and an admin tool so support can answer a ticket without a database console.
Our SaaS service page also has a smaller Launch band, aimed at founders still validating with real users. It is priced from mid four figures USD over 6 to 8 weeks, lower and sooner than the rows here, and your written scope will say which one your product fits.
The figure below draws those ranges to scale, with the plain web app as the reference.
How tenancy models change SaaS development cost
Tenancy is the decision with the longest tail. It decides how customers’ data is kept apart, and it is hard to change once real data is in. In our piece on choosing a SaaS stack by what it costs later we called it the closest thing to a one-way door in a build. Nothing since has changed our mind. Retrofitting it means rewriting queries, background jobs, exports and permission checks.
There are three common patterns. AWS’s guidance on multi-tenant architectures names them silo, bridge and pool, and treats each as a trade-off between tenant isolation and cost (page generated 9 October 2026, read 11 October 2026). The silo model gives the strongest isolation and costs the most. The pool model costs the least and isolates the least. At the database tier, they map to the three options below.
One naming trap: AWS’s older tenant isolation whitepaper, now marked historical, uses “bridge” for a mix of silo and pool. Check which meaning a vendor intends when they quote you. The cost logic is the same either way.
Why most first releases start with a shared schema
For most first releases, we would choose the shared schema and put the protection in the database. With PostgreSQL’s row security policies keyed to the current tenant, a query that forgets its tenant filter still sees only that tenant’s rows. A table with row security switched on and no policy at all returns nothing, because the default is to deny. One catch: superusers always bypass these policies, and table owners do too unless the table is set to force them. So the application should connect as an ordinary role. That small piece of design is cheap on day one and expensive to add after launch.