"Should we build this or buy it?" is one of the most expensive questions a company asks, and most people answer it with gut feel. They build things they should have bought, and buy things they should have built. Both mistakes cost six figures and a year you don't get back.
Here's the framework we actually use when a client asks. It's not "build if you're technical, buy if you're not." It's a cost model and a small number of rules that catch most of the bad decisions.
The total-cost math nobody does
When people compare build vs buy, they compare the SaaS subscription against the cost of writing the code. That's the wrong comparison, and it's why so many build decisions go bad.
Buying isn't just the subscription. Building isn't just the initial build.
The single number people forget on the build side is maintenance: budget 15 to 25 percent of the original build cost, every year, forever, just to keep custom software alive and current. A $120K build is really a $120K build plus roughly $24K a year. Over five years that's a $216K decision, not a $120K one. Run that math before you commit.
When SaaS wins
Buy when the thing you need is not what makes you money.
- It's a solved, commodity problem. Email, payroll, CRM, helpdesk, accounting. Thousands of companies need the exact same thing you do. Someone has already built it better than you will, and they amortize the cost across thousands of customers.
- You'd be reinventing a category. If a mature category with five credible vendors exists, the build will almost always lose on total cost.
- Speed matters more than fit. You need it next week, not next quarter.
- The requirements are stable and standard. You don't have weird workflows that no vendor supports.
The test: if a competitor uses the same tool and it gives neither of you an edge, buy it. Spending engineering budget to rebuild a CRM is spending your scarcest resource on a problem your customers will never see.
When custom wins
Build when the software is the edge, or when buying forces you into a shape that costs you more than building would.
- It's your differentiator. The workflow is the reason customers choose you. The moment you templatize it into someone else's tool, you look like everyone else.
- No tool fits without painful workarounds. You're paying for three SaaS tools plus a small army of Zapier zaps and a spreadsheet that someone updates by hand. That duct tape has a salary cost, and it breaks.
- The data is the asset. You want full ownership and control of the data model because it compounds in value over time.
- Per-seat pricing punishes your growth. At 12 users the SaaS bill is fine. At 400 users it's a tax on every hire, and the build pays for itself.
Buy the core, build the edge
This is the rule that resolves most "but it's not really either" situations, and it's how most good systems actually get built.
You almost never need to build the whole stack. You build the thin layer that's differentiated and buy everything underneath it.
- Buy auth, billing, email, payments, error tracking, the database itself. These are solved. Rolling your own auth in 2026 is a security liability, not a feature.
- Build the workflow, data model, and interface that make your product yours.
A modern custom build is mostly integration: Stripe for billing, Clerk or WorkOS for auth, Postgres for data, and your differentiated logic stitched on top. That's why "custom" no longer means "from scratch," and why the build side of the math is cheaper than it was five years ago. The leverage is in being precise about which 20 percent is actually yours.
Five scenarios, with verdicts
Notice the pattern: build when the software is the product or when the workaround tax already exceeds the build cost; buy when it's a commodity or compliance-heavy; and split when only part of it is yours.
How to actually decide in an afternoon
Score the decision on four questions before you ever write a line of code or sign a contract:
- Is this our differentiator, or plumbing? Plumbing leans buy.
- What's the five-year total cost of each path, including 20 percent annual maintenance on the build and per-seat scaling on the SaaS? Run the real number.
- What's the cost of the workaround we're doing today? If it's high, the build's payback is faster than it looks.
- Can we buy the core and build only the edge? Usually yes, and that's usually the answer.
If you want help running that math on a specific decision, our Custom Software Development practice does build-vs-buy assessments before any build, and a fair number of them end with us telling clients to buy. Browse the cost guides for ballpark ranges, or send us the decision you're stuck on.
Read next: