Signs you need custom software, and signs you do not yet

There is a version of this article that lists ten reasons you need custom software and concludes that you do. It is written by people who sell custom software. This one is written by people who sell custom software and would rather not build the wrong thing, because the wrong thing comes back as a maintenance bill for years.

So here are the signs that genuinely indicate it, the signs that look like it and are not, and a way to decide without a vendor in the room.

The question is not whether your tools are annoying

Every business has annoying tools. Annoyance is not a signal, because the alternative also has annoyances and you cannot see those yet. The signal you are looking for is different: it is work that exists only because the tools cannot do something, and that scales with the business rather than staying flat.

A weekly export that takes twenty minutes is annoying. A weekly export that takes twenty minutes per branch, and you are opening branches, is a cost curve. The first is a preference and the second is arithmetic, and only the second justifies a build.

Six signs, and what each one actually indicates

The middle column is the one that matters. Most of these signs point at something smaller than custom software, and a business that fixes the smaller thing often finds the original complaint disappears. That is a good outcome and not a failed enquiry.

What the research says about the spreadsheet you are defending

The most common thing custom software replaces is a spreadsheet that has quietly become infrastructure, so it is worth knowing what the research on spreadsheet reliability actually found, rather than trading anecdotes about it.

Raymond Panko of the University of Hawaii reviewed the field audit literature for the European Spreadsheet Risks Interest Group in Spreadsheet Errors: What We Know. What We Think We Can Do. Across seven field audits covering 367 real organisational spreadsheets, errors were found in 24 percent of them. The paper notes that most of the older audits used techniques unlikely to catch a majority of errors, and that the more recent audits, using better methods, found errors in at least 86 percent of the spreadsheets they examined. Restricted to the audits from 1997 onwards, 54 spreadsheets, the figure was 91 percent.

The per cell numbers are the part that explains it. Cell error rates in the carefully audited spreadsheets came out at roughly 1 to 2.5 percent, which sounds small until you notice that an error almost anywhere in a spreadsheet produces an incorrect bottom line. Panko makes exactly that point: spreadsheet modelling is unforgiving, so a low per cell rate still means most large spreadsheets contain a wrong number somewhere.

Two honest caveats before anyone quotes that at their finance team. This is a review of studies rather than a survey of your business, and the audits it draws on are old, the most recent in the table dating from 2000. What it supports is a modest claim: a large spreadsheet probably contains an error, and confidence that yours does not is not evidence. It does not on its own tell you to commission software.

The signs that mean you do not need custom software yet

• The process is still changing every few weeks. A schema will fight you, and the flexibility of a sheet is doing real work while the shape is still being invented.
• One person owns the file and nobody else edits it. Most of the concurrency argument evaporates, and better validation inside the sheet is a genuine fix rather than a stopgap.
• The complaint is about reporting rather than record keeping. Those get conflated because both surface as complaints about the spreadsheet, and they have different, much cheaper answers.
• You have not yet tried the obvious product. If something off the shelf fits, the cheapest system is the one you never commission.

That third one is worth dwelling on. A business that wants reliable numbers needs to choose the numbers, not build a system, and we made the case for the smaller intervention in when a stock spreadsheet starts costing more than it saves. On the sales side the same discipline applies, and BDG Labs set out the operational version of it in their rules for CRM hygiene on small teams, which is frequently the fix when the complaint is that the pipeline cannot be trusted.

Where off the shelf usually stops

There is a real boundary, and it is narrower than vendors on either side suggest. Off the shelf products stop being viable when your core process is genuinely unusual and the product cannot be configured to hold it, when integration between two systems you must keep is impossible rather than merely fiddly, or when per seat pricing crosses the cost of building at the headcount you are actually going to reach.

The middle ground is larger than most people expect, and it is where we send most enquiries. We mapped where it ends in no code versus custom development, and the migration path out of a sheet, when it is justified, is in Excel to web app migration.

How to decide without a vendor in the room

Three questions, answered with numbers rather than feelings. How many hours a month does the workaround consume, and is that number flat or growing with the business. What breaks if the person who understands the file leaves. And what does the off the shelf option cost over three years at the headcount you expect, against a build plus its maintenance over the same period.

If the workaround is flat and small, keep it. If it is growing and the process has settled, you have a case. And if you get to that point, the two things worth reading before you talk to anyone are honest ranges for how long a build takes and how to choose a software development company, because the second decision costs more than the first.

Honest limits

The six signs are a diagnostic, not a score. Meeting four of them does not mean you should build, because one strong reason usually carries the case and four weak ones usually do not.

And the most common correct answer to this question is still no, or not yet. We would rather write that here than discover it four months into a build that a configuration change could have avoided.