When Spreadsheets Stop Working: Do You Need a Custom Web Application?
How to tell whether your business has outgrown spreadsheets and off-the-shelf tools, what a custom web application actually costs to start, and when building is the wrong answer.
Kumail Hassan
Web53Solutions
Almost every established business has one. A spreadsheet that started as a quick way to track something, grew a few extra tabs, and now quietly runs a core part of the operation. Nobody decided this would happen. It just did, one column at a time.
It usually works fine, right up until it does not. The question is how to tell the difference between a spreadsheet that is doing its job and one that is costing you more than it saves.
First, the part that loses us work
Most businesses asking about custom software should not build any.
If an off-the-shelf product does eighty per cent of what you need, buy it. You get a mature product, someone else's bug fixes, a support line, and no maintenance obligation. Xero, ServiceM8, Shopify, monday.com and their competitors exist because they solve common problems well and cheaply. Rebuilding one of those to save a subscription fee is close to the most expensive mistake we see.
Custom is worth considering when the eighty per cent is not there, or when the twenty per cent you are missing is the part your business actually competes on. Those are different situations, and only the second one reliably justifies a build.
The seven signs
1. One person understands the spreadsheet
There is a file that runs pricing, or scheduling, or stock. One person built it. When they are on leave, decisions wait.
That is not a spreadsheet problem, it is a continuity risk sitting on a single laptop. The business knowledge is real and valuable. The container for it is the problem.
2. Copy and paste has become someone's job
Data gets entered into one system, exported, reformatted, and entered again somewhere else. Someone does this every week, possibly every day.
Add it up honestly. Four hours a week is roughly five working weeks a year, and every one of those transfers is a chance to introduce an error nobody catches until a customer does. Sometimes the fix here is not an application at all, just connecting the systems you already run.
3. You cannot answer a simple question about your own business
"How many jobs did we run for that client last quarter, and what was the margin?" If answering that means someone spending an afternoon in three systems and a spreadsheet, your data exists but your information does not.
Businesses making decisions on stale numbers usually do not know they are doing it. They just feel like every decision is a judgement call.
4. You are paying to work around your software
Two versions of this, both common. You pay for seats on a product where your team uses one module. Or you pay for a product and then pay again in staff time to handle everything it does not do.
When the workarounds cost more annually than the licence, the tool has stopped being the cheap option.
5. Your process is your advantage, but your software fights it
This is the strongest reason to build, and the most commonly missed.
If you win work because you quote faster, schedule smarter, or handle a specialised compliance step better than competitors, that process is an asset. Off-the-shelf software encodes someone else's process. Every time you bend yours to fit the product, you sand down the thing that makes you worth choosing.
6. Files named final_v3_ACTUAL
Version conflicts, overwritten changes, and two people editing different copies of the truth. Cloud spreadsheets help, but they do not stop someone pasting over a formula, and they do not tell you who changed a number or why.
Once accuracy depends on everybody being careful, you have a system that fails at the worst possible moment.
7. You are hiring people to do what software should do
The clearest signal of all. If growth means hiring another coordinator purely to keep up with admin volume, you are buying capacity at the most expensive price available, and you will buy it again next year.
What a custom web application actually is
The phrase makes people imagine a two year project and a seven figure budget. Usually it is far smaller than that.
In practice it is most often one of these:
| Type | What it does |
|---|---|
| Internal tool | Replaces the spreadsheet that runs one specific process |
| Client portal | Gives customers a place to see their own jobs, documents or invoices |
| Dashboard | Pulls data from systems you already run and answers the question |
| Workflow app | Moves a job through defined stages with the right people notified |
| SaaS product | Software you sell to others, rather than run yourself |
The first three are the common starting points, and none of them need to replace your existing systems. A good custom web application usually sits alongside your accounting package and your CRM rather than trying to be them.
Starting without betting the business
The projects that fail are the ones that try to replace everything at once. The ones that work start narrow.
Pick the single worst workflow. The one that generates the most manual handling or the most errors. Build that, use it for a quarter, and see what actually changes. You will learn more from three months of real use than from six months of requirements documents, and you will have something working either way.
That first slice typically lands in the low tens of thousands rather than the hundreds, and it gives you a real answer to the question of whether the rest is worth building. If it is not, you have spent a contained amount to find out, and you still have the tool.
Be realistic about the ongoing side too. Custom software is an asset you own, which also means it is an asset you maintain. Budget for hosting, updates and small changes as the business shifts. Anyone who quotes a build without mentioning what happens afterwards has not finished the quote.
When not to build
- A well-served common problem. Accounting, payroll, email marketing. Buy these. Always.
- Nobody internally owns it. A custom tool needs someone in the business who cares whether it works. Without that, it decays.
- The process is still changing weekly. Build once it has settled, or you will pay to encode a process you abandon.
- The real problem is the process. Automating a broken workflow gets you a broken workflow that runs faster. Fix the process first, then decide whether it needs software.
- The business case is a feeling. "It would be good to have a dashboard" is not a business case. "Four people spend a day a week on this" is.
How this connects to everything else
Custom applications rarely arrive on their own. Most of the businesses we build for reach this point after outgrowing their website, or after realising leads are falling through the gap between systems.
Often the right answer is not a full application at all. It might be AI automation handling the document work, an integration closing a gap between two tools, or a mobile app for a team that works away from desks. The useful conversation is about the problem, not the format.
The short version
Most businesses should buy software rather than build it. Build when the process is the thing you compete on, when the workarounds cost more than the tool, or when growth means hiring people to do data entry.
Start with one workflow rather than the whole operation. Measure whether it actually changed anything. Then decide about the rest.
Not sure whether your problem needs software or just better wiring? Get in touch and we will map how work actually moves through your business, then tell you honestly which parts are worth building, which should be bought, and which just need two systems talking to each other. You keep the map either way. You can also read more about our custom web application development.
Have a project in mind?
We build custom websites, web apps and AI-powered systems for Australian businesses. Tell us what you need.