What happens when nobody maintains your business website?
A website can keep returning a 200 response long after parts of it have quietly stopped working. Maintenance is the work that notices.
3 min read
Technology decisions / Nov 2026
Build, buy, or wait?
The build-versus-buy question is usually framed too narrowly. The third option — waiting, or solving the problem manually — is often the most honest answer.
The build-versus-buy question is usually framed too narrowly. The third option — waiting, or solving the problem manually — is often the most honest answer.
Every software decision arrives with a familiar framing: should we build it or buy it? The question is useful, but it hides two assumptions. It assumes the capability is needed now, and it assumes software is the right form of the solution.
In practice, many requests to build are requests to remove friction that could be removed more cheaply. A better form, a clearer process or a decision not to collect the data at all may be sufficient. The build-or-buy debate can become a way of avoiding the harder operational question.
Four tests
When a genuine software decision is required, we use four tests to make the trade-off explicit. They are deliberately practical. The aim is not a definitive formula but a decision that the organisation can explain and revisit.
- Differentiation: does this capability create an advantage, or is it table stakes?
- Rate of change: will the requirements be stable enough for a build to age well?
- Operating burden: can we support the system, including its integrations and access model?
- Reversibility: how expensive is it to change our mind in two years?
A capability that is genuinely distinctive, changes slowly and can be supported is a reasonable build. A commodity capability that changes quickly is usually a buy, even when the licence feels expensive. The cost of ownership is rarely visible in the first proposal.
Waiting is a decision
Waiting is often treated as indecision. It can be a deliberate choice: postpone until the volume justifies automation, until the process has stabilised, or until a platform decision elsewhere has resolved the integration question. The important thing is to state the trigger that will cause the decision to be reopened.
The most expensive software is often the system built to solve a problem that was about to disappear.
We do not approach this question with a preference for building. We approach it with a preference for the smallest system that resolves the problem and can be maintained without heroics. Sometimes that system is ours. Sometimes it is someone else’s. Sometimes it is a better spreadsheet and a clearer owner.