“Should we buy an existing tool or build our own?”
It is the right question — and the wrong frame. The honest answer is: buy what is commodity, build what differentiates you. The hard part is telling them apart.
When off-the-shelf is the right call
Buy when the capability is the same for everyone in your industry:
- Accounting and payroll follow legal formats — nobody gains an edge from custom payroll.
- Email, file storage, video calls — commodity. Buy.
- Standard CRM processes, when you adopt the vendor’s way of working happily.
Off-the-shelf is faster to start, maintained by someone else, and cheaper at the beginning.
When custom software wins
Build when your way of working is the advantage:
- Your process is genuinely different. If your workflow is what makes you competitive, forcing it into a generic tool bleeds the advantage away in workarounds.
- Integration is the real requirement. When data must flow cleanly between systems that vendors never intended to connect, custom middleware and APIs are often cheaper than perpetual manual reconciliation.
- The vendor’s roadmap owns your future. Pricing changes, discontinued features, forced migrations — with commodity tools you accept all of it.
- The maths of repetition. If twenty people each spend an hour a day working around a tool’s limitations, the “expensive” custom build often pays for itself faster than expected.
The questions that settle it
- Where does this capability sit relative to our competitive advantage? Core differentiator → build. Back office → buy.
- How much of the vendor’s workflow are we willing to adopt? Be honest — “we’ll customise it” usually means “we’ll pay twice.”
- What is the five-year total cost? Licences, per-seat fees, integration glue and manual workarounds — compared against build and maintenance.
- Who owns the data and the roadmap? If the answer is “the vendor,” make sure that is acceptable.
- Can we start smaller? Often the smartest route is a focused MVP for the differentiating part, integrated with bought tools for everything commodity.
What a good custom build looks like
Custom does not mean big-bang. The projects that succeed:
- Start with a proof of concept or MVP that validates the riskiest assumption
- Use modern, maintainable stacks with clean architecture, so the second developer can understand the first one’s work
- Plan integrations deliberately — APIs, data contracts and error handling designed, not improvised
- Include support and enhancement from the beginning, because software is a living system, not a delivery
The bottom line
Buy commodity. Build differentiation. And when you build, build small first, measure honestly, and grow what works.
If your team is drowning in workarounds between systems, that is usually the moment a focused custom application conversation is worth having.