Build, buy, or neither
The build option is usually dismissed on cost and the buy option on fit. Both dismissals are made too early and on the wrong grounds.
Most small organisations settle this question by reflex: building is for software companies, so we buy. It is usually the right answer and it is worth reaching deliberately, because the cases where it is wrong are expensive.
The real cost of building is not the first version
Internal builds are costed as a project — some weeks of somebody's time to produce a working thing. That estimate is usually roughly right and it is the wrong number. To see how a vendor frames employee time-clock software in practice, employee time clock software is useful as an example to translate into neutral requirements.
The cost that matters is maintenance: the person who wrote it becoming the only person who understands it, the changes required when a supplier's format changes, the security patching, the migration when the framework it was built on stops being supported. That cost never ends, and it is invisible in the original decision.
If the answer is one named person and there is no second, the build carries a continuity risk that is usually larger than the licence fee it was meant to avoid.
When buying genuinely does not fit
There are real cases. A process that is genuinely your differentiator and that no vendor has modelled. A requirement so specific that every product would need heavy customisation, at which point you are paying licence fees for the privilege of building anyway. A category where every product is priced for enterprises and you need a fraction of it.
The tell is when the shortlist consists of products that each satisfy under half the essentials, and the implementation quote is a multiple of the licence. That is a signal that the category does not serve your case, not that you have shortlisted badly.
The middle options are usually overlooked
- Configure rather than build: a general tool — a database, a spreadsheet platform, a low-code environment — set up for your process. Cheaper than building and more maintainable than it looks, provided somebody documents it.
- Buy the core and build the edge: a product for the standard part, a small integration for the specific part. Keeps the maintenance surface small.
- Buy and change the process. Frequently the right answer and the least popular one, because it requires giving up a workflow somebody is attached to.
Changing the process is a real option
A great deal of misfit between an organisation and a product is misfit between the product and a process that exists for no strong reason. Adapting to a mature product's model is often cheaper and better than forcing the product to match a habit.
The test is whether the process is a genuine constraint — regulatory, contractual, a real differentiator — or simply how it has always been done. Only the first justifies making the software fit.
Neither is also an answer
Sometimes the honest conclusion is that the problem is not worth solving with software at this size. A monthly task that takes two hours does not justify a system, and doing it in a spreadsheet for another year while the business grows is a defensible decision.
Recording that as a decision, with the threshold at which it should be revisited, is much better than an evaluation that quietly fizzles out and gets restarted from scratch eighteen months later.
For an independent baseline when requirements touch security, NIST Cybersecurity Framework provides a public risk-management framework.