When Does a Business Actually Need a Custom App?
There are recognisable signals that a process has outgrown its tools - and recognisable signals that it hasn't. Here are both, so you can tell which situation you are in.
Custom software is expensive, ongoing, and frequently the wrong answer. It is also occasionally the only answer, and delaying it costs more than building it would have.
The difficulty is that both situations feel similar from the inside. Something is not working, someone suggests software, and the discussion moves straight to features without establishing whether software is the problem.
Here are the signals that reliably distinguish them.
Signals that you probably do need one
The spreadsheet has become the system of record
The most common origin story. A spreadsheet started as a convenience. Now four people edit it, there are formulas nobody understands, someone keeps a local copy, and the whole business depends on it.
Spreadsheets are excellent tools that fail predictably when used as multi-user databases. No validation, no audit trail, no permissions, no referential integrity. When a spreadsheet becomes critical infrastructure, you have already specified the application - you just have not built it.
The same data is entered more than once
If someone types a customer’s details into a form, then into a CRM, then into an invoicing system, you are paying for the same data three times and creating three chances for it to diverge.
Note: this often needs integration or automation rather than a new application. Fix the connection before replacing the systems.
The exceptions have taken over
Every business has exceptions - the customer billed differently, the order that skips a step. Products handle the common path well and exceptions badly.
When most of your work is exceptions, or when handling them requires knowledge that lives in one person’s head, you have a case. Custom software can encode the actual rules instead of the idealised ones.
You have hit a hard ceiling in an existing tool
Not “we would prefer it worked differently” - an actual structural limit. The tool cannot store the field you need, cannot express the relationship, cannot support the workflow. You have checked with support and the answer is no.
The workaround costs more than the software
Quantify it. Time per occurrence, times frequency, times a year, times the people involved. A task taking six extra minutes fifty times a day is not a small problem.
If the annual cost of the workaround approaches the build cost, the decision is straightforward.
You need something customers touch
Client portals, booking systems, customer dashboards. These are visible parts of your service, and generic tools often make that visible in ways you would rather they did not.
Signals that you probably do not
Nobody has evaluated existing products properly
A demo call is not an evaluation. A trial with your real data, run by the people who would use it, for long enough to hit the edge cases - that is an evaluation.
We have been asked to build systems that turned out to be available off the shelf for a fraction of the cost. Nobody had checked properly. See custom software vs off-the-shelf.
The process itself is the problem
If a workflow has eleven steps because it accumulated them rather than because it needs them, building software encodes the mess permanently. You get a faster bad process and it is now expensive to change.
Fix the process on paper first. Sometimes that is the entire project.
Requirements change every week
Software is expensive to change. If nobody can agree what the process should be, building it means rebuilding it repeatedly. Stabilise first.
Nobody will own it
Custom software needs an owner - someone who fields questions, decides on changes, and makes sure it keeps working. Without one it degrades within a year or two.
If nobody has the capacity, buying something maintained by a vendor is more realistic.
It is a standard function
Accounting, payroll, email, calendars, basic CRM. Solved by mature products. Building your own is a distraction.
The intermediate step people skip
Between “spreadsheet” and “custom application” there is a wide middle ground worth exploring first.
Better use of what you have. Many businesses use a fraction of the capability of the tools they already pay for.
Integration. Frequently the pain is not any single tool but the gaps between them. Connecting existing systems is far cheaper than replacing them.
Automation of the worst step. Rather than rebuilding a whole workflow, automate the one part consuming the most time. See what business processes you should automate.
A very small first version. If you do build, build the narrowest useful thing. The instinct is to specify everything the system might eventually do; the discipline is to ship the core workflow, put it in front of real users, and expand from there.
What to do before committing
- Map the current process. Every step, including the exceptions and the manual bits people do without thinking.
- Quantify the pain. Hours, error rates, delays. Real numbers.
- Evaluate two or three products with real data.
- Identify the specific gap. What exactly does no product do?
- Ask whether the gap needs an application or an integration.
- Define the smallest version that removes the bottleneck.
- Name the owner.
If you complete that and the case still holds, you have a real project - and you have most of the specification, which is the part that usually derails builds.
If it does not hold, you have saved yourself a significant amount of money and found out what the actual problem was.
We would rather talk you out of a build that will not pay for itself than sell you one. Describe your process and we will tell you which of these situations you are in. More on app development.