SaaS vs Custom Build: The Real Cost Curve Nobody Shows You

The build-vs-buy conversation is one of the worst in software because both sides are right and both sides are misleading at the same time.

The SaaS vendor tells you: "Don't reinvent the wheel. We're $50 per user per month. You'll never build cheaper than that."

The internal team tells you: "We're paying $240K a year for a tool we use 30% of. We could build this in three months."

Both numbers are true. They're also incomplete. The actual cost of each path is not a single number — it's a curve, and the curve bends in a different direction for SaaS than for custom. This post is the curve, drawn honestly, and the four questions that tell you which side of the crossover you're on.

The honest SaaS cost curve

SaaS costs start low and grow with usage. That much is obvious. What gets glossed over is how steeply they grow, and what drives the slope.

In year one, your SaaS bill for a team of 50 at $50/user/month is $30K. Sounds cheap. Now add the real costs:

• Seat creep. 50 becomes 150 as adoption spreads. Your $30K is now $90K.
• Tier creep. The features you actually need are on the enterprise tier. $50/user becomes $120/user. $90K is now $216K.
• Add-on creep. SSO. Audit logs. Sandbox environments. Each a separate line item. Add 20-40%.
• Integration tax. The SaaS integrates with two of your other tools. The third integration you build yourself. Every year.
• Exit cost. Your data is hostage. Switching vendors means a migration project you're not budgeting for.

Year three, the team of 50 has become a team of 150, the $50 has become $180, and the $30K has become $324K plus another $40K in integration maintenance. That's the real SaaS curve: linear in seat count, steep in feature creep, with a non-zero floor you can't renegotiate down.

The honest custom-build cost curve

Custom software costs start high and flatten. That much is obvious. What gets glossed over is how expensive year one really is, and how much you save in later years only if you get year one right.

In year one, a focused custom build of a mid-complexity SaaS-replacement tool lands between $150K and $400K for the initial release. Add:

• Year-one operations. Hosting, monitoring, incident response. $20K-$60K/year depending on footprint.
• Year-one maintenance. Bug fixes, small features, the stuff that never makes the roadmap but always needs doing. $40K-$80K/year.
• Year-two features. The thing you thought was in scope but wasn't. Another $60K-$150K.
• Technical debt interest. If you built it fast in year one, you pay in year two. If you built it right, you pay less.

Year three, your team of 50 that became 150 is running on the same build, maybe with one feature expansion. Your total year-three spend is $80K-$140K — hosting, maintenance, one developer's part-time attention. The curve flattens because the cost stops scaling with users. It scales with features instead, and you control the feature pace.

Where the curves cross

Plot the two and they cross somewhere between month 24 and month 36 for most business software. Before the crossover, SaaS wins on total cost. After the crossover, custom wins, usually by a widening margin.

Three factors move the crossover point:

• User count. More users = faster SaaS cost growth = earlier crossover. A 10-person team might never reach crossover. A 500-person team reaches it in month 12.
• Feature specificity. The more niche your needs, the faster custom wins, because SaaS forces you up the pricing tiers for features you half-need.
• Data leverage. If your data inside the SaaS has value beyond the SaaS itself — if you want to run analytics, AI, or integrations on it — custom wins faster, because SaaS data is always one API deprecation away from locked.

When SaaS is obviously right

Don't build if any of these are true:

• The capability is not your edge. Nobody wins a market on how good their HR software is. Buy it.
• The problem is widely solved. If there are twenty credible SaaS vendors, you are not going to build a better one for less. Pick one and move on.
• Your team can't operate what they build. If you don't have the in-house capacity to run the thing 24/7, don't build the thing 24/7 runs.
• Short time horizon. If you'll change the business in two years anyway, don't sink 18 months into a custom build.

These are the honest cases for buying. They are also most business-tooling decisions. The default should be SaaS; the question is when the default stops applying.

When custom is obviously right

Build when any of these are true:

• The capability is your edge. If your product differentiation depends on the behavior of this tool, you cannot outsource the behavior.
• Compliance forces your hand. Some regulated domains (clinical, defense, some financial) simply don't have credible SaaS options. You build or you don't ship.
• The SaaS vendor is squeezing you. If you're three years in, your bill is a moving target, and your leverage is zero, build the replacement while you still have budget.
• You need the data. When the value is in the dataset — not the features — custom wins, because you own the data model end to end.

The four-question test

If it's not obvious after reading the above, these four questions usually resolve it.

1. How many users in three years? If the answer is under 30, SaaS almost always wins. If the answer is over 300, custom usually wins. Between those, do the math.

2. Is the workflow 80% of what the SaaS does, or 40%? SaaS is priced for the 80% case. If you're using 40% and forcing the rest through customization, you're paying full price for half the product.

3. Will your data leave this tool? If yes — for analytics, AI, integrations — custom wins earlier because the SaaS becomes an expensive middleman.

4. Can you operate custom software competently? If you don't have the team to run it or a partner who will, stop. The cost of a custom build you can't operate is worse than any SaaS bill.

The hidden third option

There's a third path most conversations miss: buy the commodity, build the differentiator.

You don't have to pick one. You can — and usually should — buy off-the-shelf for the 80% of workflows that are commodity, and build only the 10-20% that's your actual edge. Interop between the two costs something, but much less than either extreme.

Most of our custom work sits in this pattern. The client keeps Salesforce, keeps Slack, keeps Notion. We build the thing that makes their business theirs and connect it cleanly to the commodity layer via APIs and MCP servers. Best of both curves.

The bottom line

SaaS is cheap now and expensive later. Custom is expensive now and cheap later. The curves cross somewhere between year two and year three for most business software at scale, and the four-question test tells you which side of the crossover you're on.

The wrong question is "build or buy?" The right question is "which of these problems are worth owning, and which aren't?" Answer that honestly and the decision makes itself. Answer it based on who the last vendor rep talked to and you'll be signing renewals forever.