The spreadsheet that became the business
Almost every small business we meet has one. It started as a quick way to track jobs, or stock, or bookings, or who owes what. Someone set it up in an afternoon and it worked, so people kept adding to it. A second tab, then a lookup, then a formula nobody wants to touch. Five years on the whole operation leans on it, and nobody remembers deciding that.
There's nothing wrong with this. Spreadsheets are good tools and starting with one is usually the right call. The trouble is they don't tell you when they've stopped being a spreadsheet and started being a system. The signs turn up one at a time, and each one on its own feels manageable.
Signs the spreadsheet has outgrown itself
You don't need all of these. Two or three is enough to take seriously.
- More than one person edits it at once. Changes get overwritten, cells get locked, and someone is always working from a copy that's slightly out of date.
- Only one person understands the formulas. When they're on leave the business is running blind. When they resign it's running on something nobody can maintain.
- Data moves by copy and paste. Between tabs, into emails, into invoices, into the accounting package. Every paste is a chance to be wrong, and nobody notices until a customer does.
- There are files called FINAL, FINAL_v2 and FINAL_v3. There's no single source of truth, and somebody is looking at the wrong one.
- There's no audit trail. A number changed last week and nobody knows who changed it, what it was before, or why.
- Customer data lives in it. Names, phone numbers, addresses. Emailed around, saved to laptops, left on a USB stick. The Privacy Act reforms have made this a liability, and we've written about what the changes mean for Australian businesses.
- It drives something that matters. Invoicing, scheduling, stock levels, payroll inputs. If the spreadsheet decides whether the right person turns up to the right job, a broken formula is a business problem.
What these have in common is that the spreadsheet has stopped being a record of what happened and become the thing that makes things happen. Spreadsheets were never designed for that job.
Try the packaged options first
We build custom software for a living, so you might expect us to say call a developer the moment you spot these signs. We'd rather you didn't yet.
Look at what already exists. Most common workflows have a well-made off-the-shelf product behind them: job management for trades, booking systems for clinics, inventory for retailers, a CRM for anyone with a sales pipeline. These are cheap compared with a build, they come with support, and they've absorbed years of other businesses having your exact problem.
No-code tools have come a long way too. For a straightforward database with forms and a few views, something like Airtable can replace a creaking spreadsheet in a week, with permissions and change history built in. If your workflow is simple and standard, that may be all you need.
Where these stop being enough is fairly predictable. Your workflow is unusual in a way that makes packaged products fight you, and you find yourself building elaborate workarounds inside them. Or you need the thing to talk to other systems, like your accounting package, your website, a supplier portal, or a piece of hardware on a factory floor, and the product only integrates with the popular tools. Or the volume gets in the way: per-user pricing on a no-code platform is fine for five people and painful for fifty, and some platforms hit hard limits well before a spreadsheet would.
There's one more case. If how you do the work is why customers choose you, renting a generic version of it from a vendor is an odd decision. That's when owning the software starts to make sense.
If you've given the packaged options a fair go and they're getting in the way, you've earned the conversation about building something.
What the first version should be
The most common mistake at this point is trying to replace everything at once. The spreadsheet has fifteen tabs, so the brief has fifteen modules. That project is expensive, slow, and usually stalls before anyone gets to use it.
A better first version is narrow. Pick the one workflow that hurts most: the process where the spreadsheet causes the most errors, the most double handling, or the most stress. Quoting, or scheduling, or stock, whichever it is. Get that working and the rest of the spreadsheet can keep going for a while.
Bring the existing data across. The spreadsheet holds years of real records and they need to migrate cleanly. This is less glamorous than it sounds and more important. Migration is also where you find the duplicates, the inconsistent spellings, and the column that half the team used differently from the other half. Better to find that now than after launch.
Give people roles and permissions: who can see what, who can change what, who can approve what. This is the biggest thing a spreadsheet can't give you, and it's usually what stops the overwriting and the accidental deletions on day one. And record every change, with who made it and when. It sounds like bureaucracy. In practice it turns "someone changed the price" into a two-minute check instead of a two-hour argument.
What the first version shouldn't be is a replacement for every tool the business uses, a dashboard for every question anyone has asked, or a mobile app, a customer portal and an integration platform all at once. Those may be right later. Software that ships and gets used beats software that's comprehensive and late.
We run a discovery phase before any build to work out which workflow to target. What discovery should hand over applies to internal software as much as it does to a website.
What it costs
Custom software costs more up front than a spreadsheet, which costs nothing. That's the comparison most owners make, and it's the wrong one.
The spreadsheet isn't free. It costs the hours someone spends each week reconciling tabs and chasing the right version. It costs the mistakes that reach customers, like the wrong invoice or the double-booked job. It costs the risk sitting in a file full of customer details on someone's laptop. And it costs something harder to price: the business can't grow past the point where one person can hold the whole spreadsheet in their head.
Against that, a focused first version is a defined one-off spend plus a modest ongoing cost for hosting and support. We have a separate guide to what custom web applications cost with indicative ranges. A well-scoped first version is a serious investment for a small business, but a bounded one. The spreadsheet's costs grow with the business until something breaks in a way that's expensive to fix.
So the question isn't whether you can afford to build it. It's what the spreadsheet is already costing you, and for how much longer.
Where to start
If you recognised your own business in the signs above, the next step is smaller than you might think. It's not a brief or a budget approval. It's a conversation about which workflow hurts most, what you've already tried, and whether custom software is the right answer at all.
We build custom web applications for Melbourne businesses at exactly this point, and some of those conversations end with us recommending something we don't build. When the answer is a build, we scope it narrow, migrate the data properly, and get the first version into use quickly so it starts paying for itself.
If your spreadsheet has become the business and you'd like a straight view on what to do about it, get in touch.
