Buy when the process is standard and the product fits it. Build when the process is the thing that makes your business work, or when the workarounds around a product have started costing more than the product saves. Most companies decide this once and never revisit it, which is why so many end up paying for both.
The comparison
| Off-the-shelf | Custom | |
|---|---|---|
| Time to first use | Days to weeks | Weeks to months |
| Upfront cost | Low | High |
| Ongoing cost | Per-seat, rises with headcount | Hosting and maintenance |
| Fit to your process | You adapt to it | It adapts to you |
| Competitive advantage | None — competitors buy the same thing | Possible |
| Vendor risk | Pricing, roadmap and end-of-life sit with them | You control it |
| Who fixes problems | Their support queue | Your team or your partner |
| Integration | Whatever the API allows | Whatever you need |
The cost that gets left out
Build-versus-buy comparisons usually put licence cost against development cost and stop there. The number missing is the cost of the workarounds.
When a product does not fit the process, the gap gets filled by people. A spreadsheet maintained alongside the system. Someone re-keying data between two tools. A weekly report assembled by hand because the built-in reporting cannot express the question. None of it appears on a budget line, and all of it is real spend.
We ask clients to count it: how many hours a week, at what cost, across how many people. The answer is frequently larger than the licence fee, and occasionally larger than the cost of building a replacement.
When to buy
- The process is genuinely standard — payroll, accounting, email, helpdesk
- No competitor would care how you do it
- The product's own roadmap will keep pace with your needs
- You need it working next week
Buying is the right answer more often than a software firm might be expected to say. We turn down work on this basis regularly, because a client who builds something they should have bought does not come back.
When to build
- The process is what differentiates you from competitors
- No product fits without workarounds that cost real money
- You are paying per seat for something whose cost rises faster than the value it delivers
- Integration between existing systems is where the actual problem sits
- Regulatory or data residency requirements rule out available products
The third option most comparisons ignore
Build around the product rather than replacing it.
A great deal of our work is this: the core system stays, and we build the layer that makes it fit — integration, automation, an interface shaped around the actual workflow, reporting the product cannot produce. It costs a fraction of a replacement and carries a fraction of the risk.
Replacing a working core system is a multi-year programme. Most of the value can usually be delivered around it, considerably sooner.
How to test the decision
Write down what the software must do, then find the three closest products and check each requirement honestly. If every requirement is met, buy. If one or two are missing and can be handled at the edges, buy and build the edges.
If the misses are in the parts that make your business work the way it does, build. And be honest at that point about what the workarounds have already been costing.
- custom-software
- procurement
- comparison
- build-vs-buy