Judgment · 5 min read
When not to build custom software
Faster building makes it easier to build the wrong thing. The discipline that matters most is knowing which problems should not become an application.
When the cost of building falls, the cost of building the wrong thing does not fall with it. Custom software carries a permanent obligation: it has to be operated, secured, patched, understood, and eventually replaced. That obligation is unchanged by how quickly the first version arrived.
The clearest case against building is a commercial product that already solves the problem well. Not adequately — well. Organizations often talk themselves out of good products over a small number of workflow differences that could be absorbed by changing the process instead. The relevant question is not whether the product fits perfectly, but whether the difference is worth owning software forever.
The second case is value. If the realistic benefit is modest, a small custom system can still consume attention, review cycles, and operational ownership disproportionate to what it returns. Small applications are rarely small commitments.
The third is participation. Rapid iteration only works when someone on the client side can make decisions at the pace the work moves. Where that availability genuinely does not exist, a fast delivery model will produce fast output and slow agreement, which is a worse outcome than a conventional schedule honestly planned.
The fourth is shape. Some problems are integration problems, some are process problems, and some are staffing problems presented as software problems. Each has a better answer than a new application, and each is regularly mistaken for one.
Finally, there is the case for stopping. Evidence exists to change decisions, and a first stage that shows the initiative should not continue has done its job. Proof of judgment includes knowing when not to build — and a delivery firm that never reaches that conclusion is not exercising judgment, it is selling.