Custom business apps vs spreadsheets: a Toowoomba decision guide

Spreadsheets are useful. They’re flexible, familiar and fast, and plenty of businesses wouldn’t have survived their early years without one. The trouble starts when a spreadsheet quietly becomes a production system without any of the protections a production system needs.

At some point the question stops being “Can the spreadsheet do it?” and becomes “Should the business still be trusting it?”

The word “quietly” is doing the work in that first paragraph, because nobody ever decides to run their business on a spreadsheet. It happens by increments. Someone knocks up a sheet to track a dozen jobs during a busy patch. It works, so it stays. Columns get added, then a second tab, then a lookup formula, then colour-coding that means something to three people. Two years later it has 40 columns, macros nobody will touch, and the entire operation checks it before doing anything. Each step was sensible. The sum is a system of record that can be broken by a sort, edited by anyone, and understood by almost no one, holding up a business that has long since outgrown it.

Keep the spreadsheet when the risk is low

A spreadsheet is fine for rough planning, one-off analysis, small lists, early prototypes, and any work where a mistake is easy to spot. It’s also a good way to test a process before you build anything. If staff are still changing the workflow every week, a custom app can freeze the wrong assumptions in place too early.

That last point deserves emphasis because it cuts against our own interest: a spreadsheet is the cheapest prototype there is. A sheet that a team has iterated on for six months is a requirements document that wrote itself, every column earned its place, every workaround marks a real rule. Building software before the process has settled just pays developer rates to encode guesses. Let the spreadsheet do the discovering. Build when the process stops moving and the risk starts climbing.

A spreadsheet becomes risky when it starts controlling work, money, compliance, customer promises or staff allocation.

Warning signs

You know the signs. Shared files called final, final 2 and use this version. Hidden formulas that only one person understands. Staff copying data out of email into a sheet, then out of the sheet into another system. Decisions made off a stale export from last Tuesday.

A common Toowoomba pattern is the operations spreadsheet that started as a sensible workaround and slowly became the centre of the business. It now tracks jobs, staff, suppliers, equipment, notes and status. Everyone depends on it, and nobody wants to touch the formula columns.

The sharpest test is to ask what happens on the bad day, because spreadsheets fail in ways that don’t announce themselves. A row sorted without its neighbours, and every job is now matched to the wrong customer. A formula pasted over with a value, and the totals have been wrong for a month. The file locked open on the laptop of someone at Bunnings. No history, so nobody can say who changed the delivery date or when. If reading that paragraph made you think of a specific file in your business, that’s the one we’re talking about. The other warning sign is human: there’s one person who “owns the spreadsheet”, and the business quietly panics when they book leave. That’s not a tooling problem anymore. That’s key-person risk with a filename.

Automate or replace?

You don’t always need a full replacement. Sometimes the right move is to keep the spreadsheet as a temporary interface and automate the boring parts around it: importing form responses, validating fields, sending reminders, pushing clean data into another system. A modest automation around a sheet can buy a year of breathing room for a fraction of an app build, and sometimes that’s exactly the right spend while the business decides what it actually needs.

A custom business app makes more sense when the workflow needs permissions, audit history, mobile access, attachments, status changes, approvals, reporting, or integration with other systems. Those are exactly the points where spreadsheets turn awkward and fragile, and the tell is scaffolding: when you’re using cell protection as a permissions system, a “DO NOT EDIT” tab as documentation, and a weekly ritual of reconciling the sheet against Xero, you’re paying app-level effort to keep spreadsheet-level safety. The awkwardness is the requirement list. Everything the team does to protect the sheet is a feature the replacement needs to do properly.

What a custom app should improve

The first version should kill the obvious pain. Staff should know where to enter information. Leaders should know which numbers to trust. The system should prevent the common mistakes instead of relying on people to remember every rule.

A job tracking app might replace a scheduling sheet with a live queue, role-based access, mobile updates and automatic customer messages. A compliance app might replace a checklist spreadsheet with evidence capture and audit records. A stock app might connect orders, suppliers and usage without anyone copying and pasting.

Notice what each example does that the sheet couldn’t: it enforces. The spreadsheet relied on everyone remembering that jobs need a PO number before scheduling; the app just won’t schedule without one. The sheet hoped people would update status; the app updates it as a side effect of doing the work, a photo uploaded from the ute, a signature captured on site. That shift, from rules people must remember to rules the system carries, is the actual product. The screens are just where it lives.

Cost the comparison honestly while you’re at it, because “the spreadsheet is free” is doing a lot of dishonest work in these decisions. Price the hours spent maintaining, reconciling and repairing it, the errors it lets through, and the one bad incident, the misquoted job, the double-booked crew, the compliance record that wasn’t there, and the free tool usually turns out to be costing a mid five-figure sum a year. Against that, a focused app build starting around $20,000 stops being extravagant and starts being the cheaper option with a warranty. Not always, and the maths deserves doing per case. But do the maths; don’t let the zero on the software line decide it.

Make the change gradual

A spreadsheet replacement fails when it ignores how people actually work. Start by mapping the current file: columns, formulas, manual checks, workarounds and reports. Then decide which parts become database fields, which become business rules, and which can disappear entirely because they only existed to compensate for the spreadsheet in the first place.

Then run the two side by side for a few weeks. It feels like double work and it’s worth it: the sheet is your regression test, and every discrepancy is either a bug to fix or a hidden rule the mapping missed. Staff get to build trust in the new system against a reference they already believe, instead of being asked to jump cold. The day you retire the sheet, and archive it, don’t delete it, everyone has already seen the app get the answers right.

And keep one habit from the old world: the export. A good business app should hand your data back as a spreadsheet any time you ask, for the one-off analysis, the accountant’s question, the board paper. The tools swap roles, the app becomes the system of record and the spreadsheet goes back to being the scratchpad, which is the arrangement both were always best at.

For Toowoomba businesses, the point isn’t to be anti-spreadsheet. It’s to put the right work in the right place. Keep the spreadsheet for thinking and rough work. Move the processes the business actually relies on into something built to hold them. If there’s a file in your business that everyone depends on and nobody dares touch, tell us what it tracks and we’ll tell you honestly whether it needs an app, an automation around it, or just a cleanup and another year of service.