Build vs buy: when to commission a custom SaaS instead of subscribing to one

Every company hits this decision multiple times. There’s a workflow your team needs. There’s an off-the-shelf SaaS that almost fits. There’s an option to build something custom. Which one?

The cliché answer is “buy unless it’s a competitive differentiator.” The cliché is mostly right and consistently misapplied. This is the longer version, for founders and product leaders who want to make the call confidently.

The hidden cost of buying

When people compare build versus buy, they usually compare the agency’s quote to the SaaS’s monthly fee. That comparison is incomplete.

The real cost of buying includes:

The monthly subscription, today. Easy to see.
The monthly subscription as the vendor raises prices, which they will. Two to three years in, your bill is often 40-100% higher than launch pricing.
The work to integrate the SaaS with the rest of your systems. Almost never zero.
The work to migrate off the SaaS if it goes away, gets acquired by a competitor, or pivots its product away from your use case. This bill can be enormous and lands at the worst time.
The cost of every workaround your team builds around the SaaS’s limitations. These accumulate quietly until someone runs a process audit.

The real cost of building includes:

The agency or in-house build cost. Easy to see.
The ongoing maintenance cost, typically 10-20% of build per year.
The cost of every feature you’d have gotten for free with the SaaS but now have to build yourself.
The risk that the build will overshoot scope or budget.

When you add the hidden columns, the comparison usually shifts by a factor of two or three in either direction depending on the specifics.

When to buy

You should almost always buy when:

The workflow is well-understood and standardized across companies in your industry. Payroll. Accounting. CRM (for most companies). Email marketing. Help desk ticketing. There is no reason to reinvent these. The SaaS vendors have spent thousands of person-years getting them right.

The cost of switching is reasonable. If the SaaS exports your data cleanly and there are credible alternatives, vendor lock-in risk is contained.

Your differentiation is not in this part of the workflow. A B2B agency uses Notion or Linear like every other agency. That’s fine. Their differentiation is in the work they do, not how they manage internal tasks.

You need it next week. Building takes months. If the deadline is shorter than the build, buying is the only option that ships on time.

Your usage will stay below the vendor’s expensive tier. Most SaaS pricing curves up steeply. If you’ll stay on the $50/seat tier, buying is cheap. If you’ll hit the $400/seat tier in two years, building becomes a serious option.

When to build

You should build when:

Off-the-shelf tools force you to compromise your core workflow. The single most reliable signal that you should build. If using the SaaS means doing the work in a way you don’t think is right, the cost of compromise will exceed the cost of the build over time.

The workflow is your competitive moat. Whatever your business is genuinely better at than competitors — the part customers buy you for — should be your own software. Renting it from a vendor means the vendor sets the ceiling on how good you can get at it.

You operate at scale where SaaS pricing breaks down. When the per-seat or per-record pricing on the SaaS exceeds the build cost over two or three years, the math reverses. We’ve seen companies paying high six figures annually for a SaaS they could have built for a year’s subscription.

Compliance or data residency requires it. Some industries, some jurisdictions, some enterprise customers will not let your data sit on third-party SaaS. Build is the only path.

You already tried the SaaS and it’s holding you back. Past tense build-vs-buy decisions deserve revisiting when you have actual usage data. If you’ve outgrown what you bought, you have more information now than you had at the original decision.

The two-axis framework

If you remember nothing else from this post, remember this. Plot the decision on two axes:

How standardized is this workflow? From “every company does it the same way” (left) to “we have an unusual way of doing this that gives us an edge” (right).
How much will we use it over five years? From “small team, occasional use” (bottom) to “core of our operations, used constantly” (top).

Off-the-shelf is the answer in the bottom-left quadrant. Build is the answer in the top-right. The other two quadrants are judgment calls where the hidden costs matter most.

Most companies get this backward in one of two ways. They buy custom in the bottom-left (vanity build, wasted budget) or buy off-the-shelf in the top-right (constant friction, ceiling on their own business).

The intermediate option: custom on top of off-the-shelf

A lot of build-vs-buy decisions don’t have to be binary. The third option is to buy the foundation and build the differentiation on top.

Common patterns:

Buy a SaaS for the boring parts (auth, billing, basic CRUD), build the unique workflow that differentiates you on top via their API.
Use a hosted platform (Shopify, WordPress, Webflow) for the basics and build custom features as plugins or extensions.
Subscribe to a SaaS for general use but build a custom dashboard, integration, or workflow layer on top of its data.

This often gets you 80% of the benefit of building at 30% of the cost. The right partner can usually steer you here when it’s the right move.

The conversation to have with yourself

Before you commission a build, ask:

What problem with the off-the-shelf option triggered this conversation? Is the build solving that, or are we using the trigger as an excuse to build something we wanted to build anyway?
If we build, who maintains it in year three when the people who built it have moved on?
Are we sure this workflow really is unusual to us, or have we just been doing it idiosyncratically by accident?
What happens if we wait six months and revisit?

Before you accept the SaaS quote, ask:

What’s our exit cost if this vendor doubles their prices or pivots away from our use case?
How much of our process is going to bend around the SaaS’s assumptions?
Are we comparing the right alternatives, or did we just pick the most-recommended option?

Most bad build decisions and most bad buy decisions are recoverable in retrospect — but recovery costs are very different. Build decisions are usually recoverable by writing off the build and switching to a SaaS. Buy decisions are usually recoverable by writing off the SaaS and committing to a build. The first costs less. That asymmetry is one of the reasons “buy unless it’s a moat” is mostly the right starting point.

If you’re stuck on the decision

We do scoping calls for build-vs-buy questions, including for companies who end up not building with us. If you want a one-hour outside read on whether your specific decision is build, buy, or hybrid, see our SaaS development page or email [email protected]. Sometimes the most useful thing we tell someone is “buy the SaaS.”