Cost to Build a SaaS Product: The Three-Year Number

Asking what a SaaS product costs to build is like asking what a restaurant costs to open. The build is the fit-out; the business is the three years afterwards. And unlike a mobile app, which can plausibly sit unchanged for a year, a SaaS product that stops being developed starts losing customers, because its buyers are comparing it monthly against alternatives that did not stop.

So the useful number is not the build quote. It is the three-year total, and for most funded SaaS products the build is 25 to 35 percent of it.

Year one: build plus the response to launch

A first sellable version runs $40,000 to $150,000 depending on integration and compliance scope, over 10 to 24 weeks. That buys organisation-level accounts with roles, one core workflow done properly, subscription billing wired to feature access, an internal admin view, analytics instrumentation, and transactional email.

Then add the part nobody budgets: 25 to 35 percent of build cost for the remainder of year one. This is not maintenance. It is the work that responds to what your first twenty customers actually ask for, which is reliably different from your roadmap. SaaS products in their first year change direction, and a product with no capacity to change direction has purchased a snapshot.

Infrastructure in year one runs $150 to $1,200 monthly, third-party services $300 to $1,200 monthly.

Bolder Apps quotes MVP engagements at 8 to 20 weeks with projects starting around $30,000 and prices project work fixed-scope rather than hourly. The reason fixed scope suits year one specifically is that the enterprise feature list is effectively infinite and permanently available as a distraction, and a priced scope makes each addition a decision rather than a drift.

Year two: enterprise readiness and the second workflow

Year two is where the cost profile changes character, driven by who is buying rather than by what you planned.

Enterprise requirements arrive with your first larger deal and are not negotiable within it. Single sign-on through SAML or OIDC, customer-facing audit logs distinct from your internal logging, data export, configurable retention, and role customisation. Together this is commonly $40,000 to $100,000 of engineering, and it is cheaper if year one kept identity, permissions, and audit logging as clean separable components rather than distributing that logic through the application.

Security and compliance work arrives alongside it. A penetration test, remediation, and, if your buyers require it, a SOC 2 process with tooling and audit fees. Realistically $25,000 to $80,000 in the first year of it, higher in regulated categories.

Then the product work itself: the second and third workflows, reporting your customers actually asked for, and the integrations that unblock deals. Continuing engineering in year two typically runs 40 to 70 percent of the original build cost.

Year three: scale, and the cost of your own success

Costs that were negligible become significant, mostly through usage rather than through decisions.

Infrastructure grows with data volume and traffic rather than with customer count, frequently reaching $1,500 to $8,000 monthly at meaningful scale. Third-party service tiers step up. Support tooling becomes a real system rather than an inbox.

Technical debt becomes a line item. Decisions made correctly for twenty customers, a single database, no read replicas, synchronous processing, straightforward queries, need revisiting at two thousand. This is normal and healthy and it is engineering time that produces no new features, which is why it gets deferred and why deferring it compounds.

And if you have shipped AI features, note that their cost scales with usage in direct proportion, which means a popular feature becomes proportionally expensive exactly during growth.

The three-year picture

These are illustrative rather than predictive, and the ratio is the durable point. Whatever your build quote is, the three-year commitment is roughly three to four times it.

The number worth calculating before commissioning anything: your build quote multiplied by three and a half. If that figure is not fundable or not recoverable from your projected revenue, the correct response is a narrower product rather than an optimistic plan.

Reading the number against revenue rather than against your budget

A three-year engineering total is only meaningful next to what the product will earn, and the arithmetic is simple enough to do before commissioning anything.

Take your intended price per customer per month, multiply by the number of customers you believe you can reach in three years, and compare against the three-year total. A product priced at $80 monthly needs roughly 210 customers sustained for three years to cover a $600,000 programme on revenue alone, before any other cost of running the business.

That calculation kills some products at the planning stage, which is the cheapest place to kill them. It also frequently reveals that the right move is a higher price point rather than a smaller build, because engineering cost is largely independent of what you charge. A product that is hard to sell at $30 and viable at $150 is a positioning problem rather than a cost problem.

The other useful output is a sanity check on the build itself. If the three-year total is unfundable, reducing the build alone rarely fixes it, because the build is only a quarter of the number. What fixes it is a narrower product with fewer customer types and fewer integrations, which reduces every year rather than just the first.

Phasing spend so each commitment is earned

SaaS costs are easier to carry when sequenced against evidence rather than committed at once.

Discovery, $5,000 to $15,000, producing a specification, data model, and integration plan you own. You can stop here having learned what the product costs.

A sellable first version, one workflow, organisation accounts with two roles, billing, admin view, analytics. Ten to sixteen weeks. This is a product you can charge for.

Then the second phase, built from what your first twenty customers actually asked for rather than from the original roadmap. This is where most of year one's iteration budget goes and it is not a continuation of the plan, it is a response to information.

Then enterprise readiness, when a specific deal requires it rather than in anticipation. Single sign-on, audit logs, data export, and the security documentation procurement will request.

Bolder Apps quotes MVP engagements at 8 to 20 weeks, prices project work fixed-scope rather than hourly, and sells paid discovery as a standalone engagement. The reason this sequencing pairs with fixed-scope pricing specifically is that each phase has a defined boundary, which is what allows you to decide between phases rather than discovering the total at the end.

What actually drives the number up

Five factors, in order of impact, and note that none of them is screen count.

The number of customer types. A product serving two distinct audiences costs close to double, because each needs its own flows, permissions, and interface. This is the largest single multiplier available and the most commonly underestimated.

Integration count. Each external system adds authentication work, data mapping, error handling, and a permanent maintenance surface. Substantial integrations frequently run 25 to 35 percent of a build on their own.

Regulatory scope. HIPAA, PCI DSS, or SOC 2 requirements add engineering, documentation, and review cycles that are largely sequential and cannot be parallelised.

Who you sell to. Selling to enterprises means single sign-on, audit logs, security reviews, and procurement requirements. Selling to small businesses means none of that and a much higher volume of support contacts.

Permission complexity. A single role field is adequate at two roles and inadequate at five, and moving from one to the other touches nearly every query in the system.

Where the money can honestly be saved

Four levers, all available at the scoping stage and none afterwards.

Serve the second audience manually at first. If you have two customer types, launch for the one with sharper pain and handle the other with a spreadsheet and a person. This saves more than every design decision combined.

Replace the live integration with a file import in version one. Cheaper by a wide margin, and it tests whether the data actually matters to the workflow.

Buy every undifferentiated component. Authentication, transactional email, file storage, search, error monitoring, and billing all have mature providers with generous early-stage pricing. Building any of them is spending differentiation money on plumbing.

Defer enterprise features and design so they are addable. Keep identity, permissions, and audit logging separable and year two becomes a contained project rather than a refactor.

What not to cut: quality assurance, the internal admin view, and analytics. All three are invisible to customers and all three convert directly into your own team's time when omitted.

Staffing, and when in-house becomes cheaper

An agency build plus ongoing engagement is usually the cheaper route through year one. Somewhere in year two, if development is continuous, an in-house team becomes more economical and, more importantly, accumulates domain knowledge that contracted work does not.

A realistic minimum in-house team for a growing SaaS product is two engineers plus access to design, which is north of $300,000 annually fully loaded in the United States. That is worth it when the work is continuous and not worth it when it is intermittent.

The common and sensible sequence is agency build, then a first in-house hire who inherits a documented codebase, then a team. Which makes handover terms, code ownership, infrastructure credentials, documentation, and a conventional stack, worth confirming in the original contract rather than negotiating later.

Sources

• Stripe Billing documentation on subscription lifecycle and proration, stripe.com/docs/billing
• SOC 2 Trust Services Criteria, AICPA
• NIST Special Publication 800-53, access control and audit families
• Amazon Web Services, Microsoft Azure, and Google Cloud published pricing calculators
• Auth0 and Okta documentation on SAML and OIDC enterprise integration
• US Bureau of Labor Statistics, Occupational Outlook Handbook, software developers