Custom software or off-the-shelf?

Written by the Incognito Labs engineering team 16 September 2026 9 min read

Nobody wakes up wanting custom software. The question arrives disguised as something else: a subscription renewal that has crept past what it is worth, a member of staff who spends every Monday morning rebuilding the same report, an order that went out wrong because it was typed into three systems and one of them was missed.

So the real question is not “custom or off-the-shelf”. It is: is the gap between how this software works and how we work now costing us more than closing it would? That is an arithmetic question, and it is answerable.

The trap is that the costs on one side are visible and the costs on the other are not. A quote for a build is a number on a page. Ninety minutes a week of somebody re-keying data is invisible, because it is already being paid, in wages, by someone who has stopped noticing they are doing it.

We build custom systems for a living and we still tell people to buy off-the-shelf for most of what they do. Anyone who tells you otherwise is quoting, not advising.

Buy, without hesitation, where the problem is one every business has in the same shape:

• Accounting and payroll. The rules are set by legislation, not by you. Someone else keeping pace with those changes is worth every penny.
• Email, files and calendars. Solved. Competing here is setting money on fire.
• Card payments. Regulated, audited, and carrying a compliance burden you do not want to own.
• Generic CRM, if your sales process is generic. The emphasis is on the condition.

What you are buying in each case is not the software. It is the maintenance: the security patches, the regulatory updates, the support desk at eleven at night. That is a real product and it is priced sensibly.

Image placeholder Suggested: a simple two-column comparison graphic — “buy” against “build” — in the site’s black, white and lime palette.

Off-the-shelf software stops being cheap quietly. Not through the invoice, which stays roughly the same, but through the accumulating cost of the gap between what it does and what you need.

That cost shows up as four separate bills, and businesses usually only notice the first:

• The per-seat bill. Rises with headcount whether or not each new person uses the thing. Three tools at a modest monthly price per user is a serious annual number by the time you have fifteen staff.
• The re-keying bill. Every place your systems do not talk, a person is the integration. That person is being paid to be an API.
• The error bill. Data typed twice is data that disagrees with itself eventually. The cost is not the typo; it is the hour spent working out which of two numbers is true, and the customer who saw the wrong one.
• The ceiling bill. The hardest to see. It is the process you did not change, the report you stopped asking for, the service you did not offer, because the software could not do it and everyone had quietly accepted that.

Add those four up honestly for a year and compare them with what closing the gap costs. Frequently the answer is obvious in one direction, and it is not always ours.

In our experience the decision tips when at least two of these are true at once. One on its own is usually a configuration problem, not a build.

1. The same information is entered more than once. If an enquiry is typed into a form, then a spreadsheet, then an invoice, you are paying for that work three times and buying a disagreement between three records. This is the most common trigger and the easiest to measure: count the keystrokes for one job, multiply by jobs per week.

2. The way you work is the reason customers choose you. If your scheduling, your quoting or your turnaround is genuinely better than the competition, generic software will drag it back towards average, because it was designed for the average. Buying the same tool as your competitors guarantees you cannot out-operate them with it.

3. Different people need genuinely different views. Most off-the-shelf tools have blunt permissions: admin, or not. Real businesses are finer than that — a subcontractor should see the job but not the margin, an employee should see their own shift but not payroll. When the tool cannot express that, the workaround is a separate spreadsheet, which is the problem you were solving.

4. Reporting is a monthly assembly job. If someone exports from three systems and reconciles them in a spreadsheet to answer “how did we do”, you do not have a reporting problem. You have a data problem wearing a reporting costume. We wrote about what to do instead in what a business dashboard should actually show.

Presented as a binary, this question produces bad decisions. In practice almost every business we work with ends up with the same architecture, and it is a mix.

Keep the commodity systems. Your accounts stay in the accounting package. Payments stay with the payment provider. Email stays where it is. Then build the thin layer that is genuinely yours: the part that knows your jobs, your pricing, your stages, your people — and connect it to the rest so information is entered once and appears everywhere it is needed.

That layer is usually far smaller than people fear. It is not “replace everything”. It is one screen that answers the questions you currently open four tabs to answer, plus the plumbing that keeps it true. The four kinds of system we build are all versions of that idea.

Image placeholder Suggested: a simple architecture diagram — accounting, payments and email as bought boxes, with a custom layer in the middle connecting them.

The reason businesses hesitate is rarely the money. It is the fear of the half-finished project — the one that goes quiet at eighty per cent and leaves them worse off than the spreadsheet they started with.

That risk is real and it is manageable. Three things make the difference:

• Scope in writing before anyone builds. What gets built, and the date it goes live, agreed on paper first. If a supplier will not do this, that tells you something.
• One system at a time. A single working thing beats a platform that is nearly ready. Ship the piece that removes the worst job, then look again.
• Somebody owns it afterwards. Software is not a delivery, it is a dependency. Whoever builds it should still be there when your VAT rate changes or a supplier alters their export format.

That last point is why we work on a retainer rather than a one-off invoice: the incentive to build something maintainable only exists if you are the one maintaining it. Our three-phase process sets out how a build runs, and the FAQ covers the commercial terms — minimum term, notice, and what happens to your data if you leave.

Pick the process that annoys you most. For one week, write down every time a person moves information from one place to another by hand, and how long it took. Do not change anything, just count.

At the end of the week you will have a number. If it is small, buy better software and configure it properly. If it is a day a week, you have found something worth fixing — and you now have the evidence to size it rather than guess.