Start with the third option
Before comparing buying and building, establish whether the thing needs to exist. Roughly a third of the evaluations we're brought into end here, and it's the cheapest outcome available.
- The process being automated shouldn't exist — some steps survive only because of a constraint that disappeared years ago
- A system you already pay for does this, unconfigured. Extremely common with ERPs and platforms like Microsoft 365
- The volume doesn't justify it. Some manual work is genuinely cheaper than the software that would replace it, and staying manual is a legitimate decision
- Nobody internally will own the result, in which case it decays within two years whatever you buy or build
If the answer is "do nothing", finding that out costs a conversation. Finding it out afterwards costs a project.
When buying wins
More often than most development firms will admit. The honest indicators:
- The process isn't a differentiator. Payroll, accounting, email, helpdesk. If doing it differently doesn't win you customers, buy it.
- A mature market exists. Several credible products, real competition, active development. You're buying the roadmap as much as the software.
- Compliance is involved. Vendors carry the burden of keeping current with tax, privacy and reporting rules. That's worth a great deal.
- You'd be the smallest user of what you built. A product with ten thousand customers has encountered edge cases you haven't imagined.
- Speed matters more than fit. Eighty percent fit next month frequently beats a hundred percent fit next year.
When building wins
- The process is genuinely yours. If how you do it is part of why customers choose you, forcing it into a product's model erodes the thing that works.
- You've already bought and it didn't fit. A second product rarely fixes what the first one couldn't, and the configuration effort is usually larger than people remember.
- The integration burden exceeds the build. Sometimes connecting a product to four systems costs more than building something that fits between them.
- Licensing scales badly against your shape. Per-seat pricing across a large field workforce is where this usually bites.
- The requirement is narrow and stable. Small, well-understood tools are cheap to build now and cheap to own.
The answer that's usually right
Buy the commodity, build the differentiator, and integrate the two. Most real answers are not one or the other.
In practice that means buying the ERP, the CRM, the accounting system and the helpdesk, then building the layer that makes them work the way your business actually does — the portal, the workflow, the reporting, the integration. That layer is small, specific and genuinely yours, and it's where custom development earns its keep.
The firms that get into difficulty are usually at the extremes: building an ERP from scratch, or trying to force a product to be something it isn't through configuration that nobody can maintain.
Four traps in the comparison
Comparing licence cost to build cost
Build cost is one-off and licence cost is annual, so a build looks expensive in year one and cheap by year four. Compare over the same period, and include implementation, which is frequently larger than the first year's licence.
Ignoring what a build costs to own
Budget 15 to 25 percent of build cost annually for hosting, updates, security and support. A comparison that omits this flatters building, and most do.
Believing the configuration estimate
"It does that out of the box" often means it does something adjacent, configurable by someone who knows the product well. Ask to see it doing your specific thing with your data before believing it.
Not counting the switching cost of being wrong
Buying wrong means migrating again in three years. Building wrong means owning something nobody wants to maintain. The recovery cost differs and belongs in the comparison.
The decision test
Five questions. Mostly yes means buy; mostly no means build; a mix usually means the hybrid.
- If a competitor did this exactly the same way, would it matter?
- Are there three or more credible products, actively developed?
- Does anyone outside your business regulate how this must work?
- Will the requirement be recognisably the same in five years?
- Could you describe what you need without referencing your own systems?
And one more, which overrides all of them: who owns it in two years? If there's no answer, neither buying nor building will end well.
