Short answer
Buy off-the-shelf when your process is standard and a product covers 80% or more of what you need. Build custom when the process is genuinely specific to your business, is a source of competitive advantage, or when licence costs at your scale exceed the cost of building. Most businesses should buy first and build only around the edges.
Start by assuming you should buy
Building software is expensive, slow and permanent — once it exists, you own it forever, including the maintenance, the security patching and the cost of every future change. Off-the-shelf products spread those costs across thousands of customers.
So the honest default is to buy. The question is not "could we build something better?" — you almost always could — but "is the difference worth owning software forever?"
The eighty per cent test
Take your actual process, not the idealised version, and test candidate products against it. If a product covers eighty per cent or more of what you genuinely need, buy it and change your process to fit the remaining twenty. If nothing gets above sixty, building starts to make sense.
The trap in the middle is heavy customisation of an off-the-shelf product. You end up paying licence fees and carrying bespoke development cost at once, and every vendor upgrade risks breaking your customisations. That is frequently the worst of both worlds.
When building is genuinely right
Build when the process is the business. If how you quote, schedule, price or fulfil is a genuine source of advantage, forcing it into a product designed around someone else's process throws that advantage away.
Build when the licence maths turns. Per-seat pricing that is trivial at ten users becomes significant at two hundred, and at some point the annual licence exceeds what a purpose-built system would have cost outright.
Build when no product exists, which is rarer than people assume but does happen in specialised industries. And build when integration is the whole point — sometimes the useful software is the layer joining the products you already run, not another product.
The costs people forget on both sides
On the buy side, people forget implementation, data migration, training, integration work and the annual price rises that arrive once you are dependent. They also forget the switching cost: once your data and processes live in a product, leaving is expensive, and vendors price accordingly.
On the build side, people forget that the build is a fraction of lifetime cost. Maintenance, hosting, security patching and the changes the business will inevitably want typically run fifteen to twenty per cent of the original build cost every year, indefinitely. A $40,000 system is a $6,000–$8,000 annual commitment thereafter.
The hybrid approach that usually wins
Most businesses land somewhere in the middle and are right to. Buy the commodity — accounting, email, CRM, payroll — because your version would not be better. Build only the part that is genuinely yours, and connect it to the products you bought.
That keeps the custom codebase small, which keeps maintenance affordable, while still capturing the advantage that made building attractive.
Key points
- Default to buying. Building is only justified when the difference is worth owning software forever.
- If a product covers 80% of your real process, buy it and adapt. Below 60%, consider building.
- Heavy customisation of an off-the-shelf product is often the worst of both worlds.
- Budget 15–20% of build cost annually, indefinitely, for maintaining custom software.
- Buy the commodity, build only what is genuinely specific to your business.
Frequently asked
Is custom software always more expensive?
Upfront, almost always. Over five to ten years at scale, per-seat licence costs can overtake it. Run the maths on your actual user numbers rather than assuming either way.
What is the real ongoing cost of custom software?
Budget 15–20% of the original build cost per year for maintenance, hosting, security patching and changes — indefinitely, not for a fixed period.
Can we start with off-the-shelf and build later?
Yes, and it is often the sensible route. Buy to get running, learn what your process genuinely needs, then build the specific part once you know rather than guessing at the start.
Written by the Softech Team team. Last reviewed September 2026. This guide is general information, not advice for your specific circumstances.