Build vs Buy: How to Know When Custom Software Is the Right Call

Most businesses default to buying off-the-shelf software. Sometimes that's right. Here's how to tell when it isn't, and what to do instead.

Every business eventually hits the same crossroads: you need software to solve a problem, and the question is whether to buy something off the shelf or build something purpose-made.

The default answer is almost always “buy.” Software-as-a-service is fast to deploy, relatively cheap to start, and someone else handles the infrastructure. For a huge range of problems, that’s the right call.

But for some problems, usually the ones that matter most, it isn’t.

When Bought Software Works Well

Off-the-shelf software earns its place when your problem is standard. If you need payroll processed, expenses tracked, or email campaigns sent, there are mature products built exactly for that. The category is well-understood, the edge cases are already handled, and you’d be solving a solved problem from scratch.

The same logic applies to anything that’s genuinely peripheral to your business. You’re not in the business of building HR software, so use HR software. You’re not building a general-purpose CRM, so use one. Keep your engineering effort for the problems only you have.

When It Becomes a Problem

The trouble comes when your business has developed real operational complexity, processes, rules, and workflows specific to how you actually work, and you’re trying to force that into software built for the generic version of your industry.

What happens next is predictable:

You adapt your process to fit the software. This is the most common outcome and the most damaging. The software was built for a generic customer, not for your specific operations. You end up working around limitations, accepting constraints, and building workarounds that accumulate into a maintenance burden.

You buy multiple tools and stitch them together. Each tool does part of the job, and now you have data spread across five systems that don’t quite talk to each other. Someone spends their days manually reconciling spreadsheets. This is infrastructure debt disguised as a software solution.

You pay for features you’ll never use while missing the ones you need. Enterprise software vendors build for the broadest possible market. You end up with a configuration panel 200 options deep, and the specific thing your team actually needs isn’t in there.

The Signal Worth Watching

The clearest sign that off-the-shelf software isn’t working isn’t always obvious in the software itself, it shows up in the spreadsheets your team keeps alongside it.

If there’s a shared spreadsheet acting as the “real” source of truth while the purchased system sits at the edge of your workflow, that spreadsheet is telling you something. It means your process has outgrown the tool, and people have quietly built the actual system they need in the most available technology they had: Excel.

The question worth asking is how much it costs your business to maintain that workaround, in staff time, in errors, in decisions made on incomplete data, versus what it would cost to solve the problem properly.

What Custom Actually Means

“Custom software” can sound expensive and uncertain, because badly scoped custom software often is. But the right framing isn’t “custom vs off-the-shelf”, it’s “does this tool fit the problem, or are we fitting the problem to the tool?”

Custom doesn’t mean starting from nothing. It means building exactly what the problem requires, no more and no less. A well-scoped custom system replaces three overlapping SaaS tools, removes a spreadsheet workaround, and gives your team interfaces built for how they actually work, not for how a product manager in another country imagined they might work.

How to Evaluate the Decision

When you’re sitting at the crossroads, these questions tend to cut through the noise:

Is your process genuinely different from the industry norm? If your answer to “how do you do X?” is longer than a sentence and includes exceptions your competitors don’t deal with, that’s a signal.

What does the workaround cost? Quantify the manual effort, the error rate, the decision-making lag. The real cost of a bad-fit tool is usually buried in staff time and quality.

Is this a core business function or peripheral? Spend engineering effort where the competitive advantage lives. Buy for everything else.

What’s the total cost of ownership? Per-seat SaaS licensing compounds. A custom system has upfront cost and ongoing maintenance, but no licence fees and no vendor lock-in. The five-year number often surprises people.

The Honest Answer

There’s no universal right answer, and anyone who tells you “always build” or “always buy” is selling something.

The honest answer is that most businesses have a mix: bought tools for standard problems, and purpose-built software for the places where the process is genuinely their own. Getting that boundary right, knowing which category each problem falls into, is where most of the value is.

If you’re unsure which side of the line a problem falls on, it’s usually worth a conversation before you sign another SaaS contract.


We build software for businesses that have found the edge of what bought tools can do. If that sounds familiar, talk to us.

← All posts