Build or buy: the four questions that actually decide it
Custom software is usually the wrong answer and occasionally the only one. These are the questions that tell you which case you are in.
We build software, and we still tell most people not to.
That is not modesty. It is that the total cost of a custom application is dominated by the years after it ships, and the business case is almost always written about the months before. A product you buy has that cost too — it is just somebody else’s, spread across their whole customer base.
So the question is not “can this be built”. It is “is this one of the cases where building is genuinely cheaper across five years”. Four questions settle it.
1. Is this process a differentiator or a commodity?
If the process is how your organisation is distinctive — the thing that makes your service different from the agency or company next door — then bending it to fit a product is a real cost, paid daily by the people doing the work.
If it is a commodity — leave requests, asset registers, ticketing, expenses — then it is a solved problem. Every hour spent building it is an hour spent rebuilding something that already exists, and every year afterwards is spent maintaining it.
The honest test: if a product forced you to change the process, would anything of value be lost? If the answer is “no, we would just have to change how we do it”, buy the product and change how you do it.
2. What is the integration surface?
This is where build-versus-buy decisions are most often wrong in the buy direction.
A product that does 80% of what you need, and needs six integrations to do the remaining 20%, is not cheaper than a custom application. Integration is the expensive part of any system, it is the part that breaks on the vendor’s release schedule rather than yours, and it never appears in the licence comparison.
Count the integrations honestly. Identity, directory, finance, records management, the two line-of-business systems nobody mentions, and the reporting layer. If the product’s answer to most of those is “via the API”, you are building software either way — you are just building it in the least maintainable place, between two systems you do not control.
3. Who carries the compliance obligation?
For government and regulated work this question frequently decides it on its own.
If the data is classified, if it has to stay in a specific environment, if records have to be retained to a schedule, or if an assessor will want evidence of specific controls — then the question is whether a product can satisfy those constraints, and whether the vendor will commit to them in writing.
Two things worth being clear-eyed about. A product that meets the constraint today has a roadmap you do not control, and a product that does not meet it will not be changed for one customer. Custom software here is not a preference; it is sometimes the only configuration that can exist.
That is most of what we end up building: applications that exist because the requirement could not be met by anything on the market — capturing operational imagery without it touching the camera roll, or putting a directory on a handset without exposing it. Not because building was appealing.
4. Who owns it in year three?
The question that sinks more custom software than any technical decision.
An application needs an owner with a budget after the project team has moved on. It needs OS compatibility updates every year — mobile platforms deprecate APIs on an annual cycle whether or not you have funding — plus dependency patching, certificate renewals, and someone to answer the phone when it breaks.
If you cannot name the team and the recurrent budget line, do not build it. An unmaintained internal application is worse than the manual process it replaced, because the manual process degraded gracefully and the application will simply stop working one morning after a platform update.
What “build” should actually look like
When the four answers do point to building, the failure mode is scope rather than technology.
- Build the smallest thing that removes the constraint. Not a platform. The specific capability that nothing on the market provides, integrated with products for everything around it.
- Buy the boring parts. Identity, storage, notifications, reporting. Every one of those you build is one you maintain.
- Design for handover from the first commit. Documented, conventional, and readable by whoever inherits it. Clever is a liability in software somebody else will own.
- Agree the lifecycle before the first release. Update cadence, support model, and the conditions under which it gets retired. Deciding in advance how it ends is how it avoids ending badly.
The short version
Buy the commodity. Build the constraint. And do not start either until you can name who owns it in three years, because that answer determines whether the thing you build is an asset or a liability with a login page.