Replace Spreadsheets With a Web App: When and How (Australian SMB Edition)
AI-Extractable Summary
"When does it make sense to replace your business-critical spreadsheet with a custom web app? An honest framework for Australian SMBs, with realistic timelines and costs."
Almost every Australian SMB we work with has the same artefact buried somewhere: a spreadsheet that started as a quick fix and is now genuinely critical to the business. Maybe it's the master client list, the production schedule, the inventory tracker, or the "quote calculator" with 14 tabs and at least one VLOOKUP that nobody fully understands.
At some point this spreadsheet becomes a problem. The question is when, and what to do about it. This post is the framework we use to advise prospects.
Six signals you've outgrown the spreadsheet
You don't need all six. Two or three is usually enough to justify a conversation.
1. Concurrency pain
Multiple people need to edit at once and the spreadsheet keeps locking, reverting, or losing changes. Even SharePoint/OneDrive's "real-time co-editing" falls over with anything beyond simple data entry on tabular sheets.
2. The single point of failure
One team member is the only person who fully understands how the spreadsheet works. If they leave, win lottery, or go on holidays, the business stops. We've seen this case at virtually every consulting engagement above $50k.
3. Data integrity issues
You've had at least one incident where someone edited a formula they shouldn't have, deleted a row they shouldn't have, or pasted in a way that broke a calculated column. Worst case, you found out three weeks later when reports stopped agreeing.
4. Manual reconciliation between systems
Data lives in Xero, your CRM, the spreadsheet, and a couple of SaaS tools — and someone is exporting CSVs and copy-pasting between them. Quoting takes three days because the same data has to be looked up in four places.
5. Mobile or remote pain
Field staff need access from their phones. Remote workers need access from home. The spreadsheet on a shared drive over VPN is painful or impossible. Workarounds exist (Google Sheets, OneDrive web) but they degrade fast for any non-trivial workflow.
6. Reporting that takes hours
Generating a customer report or month-end summary requires a series of pivot tables, manual filtering, and data cleaning. Someone spends a half-day on this every Monday. The output is usually slightly different each time depending on who runs it.
If you're reading this list and recognising your situation, you're probably ready for the build-vs-buy conversation.
What replaces the spreadsheet?
Three options, in order of cost:
Option 1 — Off-the-shelf SaaS (cheapest, often right)
For roughly 60% of spreadsheet replacement cases we see, the right answer is "use the SaaS that already exists." If your spreadsheet is essentially a CRM, use HubSpot or Pipedrive. If it's a quoting calculator, look at Quoter or Proposify. If it's a project tracker, look at Asana, ClickUp, or Monday.
Cost: AU$50–$500/month per user. Effort: a few weeks of setup and migration. We'll tell prospects to go this route if the SaaS handles 80%+ of what their spreadsheet does — there's no point in custom for the last 20%.
Option 2 — No-code (cheaper, sometimes right)
Tools like Airtable, Glide, Softr, and the Microsoft Power Platform can replace surprisingly sophisticated spreadsheets without writing code. Cost: AU$50–$500/month plus AU$5k–$25k for someone to build it.
This is genuinely good for smaller-team workflows where the spreadsheet's logic is moderate complexity. The ceiling: no-code starts breaking around 20–50 users, complex business rules, or anything that needs deep integrations. We'll recommend no-code for the right cases.
Option 3 — Custom web application
When the SaaS doesn't fit and no-code hits its ceiling, a custom web app is the answer. Cost: AU$15k–$80k for most spreadsheet-replacement projects. Timeline: 6–14 weeks.
The win: you get exactly the workflow your business actually runs, with proper concurrency, integration, mobile support, audit trails, and reporting. The downside: it's the most expensive option and the longest timeline.
A realistic spreadsheet-to-web-app timeline
Calibrated against typical SMB scope:
| Phase | Duration | What happens |
|---|---|---|
| Paid discovery | 1–2 weeks | We sit with your team, understand the spreadsheet, design the web app. Output: wireframes, data model, fixed-quote. |
| Sprint 1–2 (foundation) | 4 weeks | Login, data model, basic CRUD on the main entities. By end of sprint 2, your data is migrated and you can log in and look at it. |
| Sprint 3–4 (core workflow) | 4 weeks | The main day-to-day workflow — what people actually do with the spreadsheet — is implemented. |
| Sprint 5 (reports & polish) | 2 weeks | Reports recreated as in-app dashboards or scheduled PDFs. Polish, testing, edge cases. |
| Beta with friendly users | 1–2 weeks | Real users, real edge cases, bug fixes. |
| Cutover | 1 day | Spreadsheet retires. App is now authoritative. |
| Stabilisation | 4 weeks | Bug fixes are on us. |
Total: 12–16 weeks for most internal spreadsheet replacements.
What can go wrong (and how to avoid it)
Wrong: The new system isn't flexible enough
Spreadsheets feel infinitely flexible. A web app is more rigid by design — that's the point. But if you build it too rigid, users hit walls and start working around the system in side spreadsheets, defeating the purpose.
Fix: Build escape hatches. CSV export and import. A "notes" field on every record. Custom fields users can add themselves. Discovery is where we identify which parts of the spreadsheet are genuine workflow vs ad-hoc flexibility, and structure the app accordingly.
Wrong: Data migration goes badly
You launch and discover that 200 rows didn't migrate correctly. Edge cases. Trailing whitespace. Date formats. Customer numbers that overlap.
Fix: Migration scripts run dozens of times into a test environment before production. Source-system row IDs preserved as foreign keys for verifiability. Parallel-run period of 2–4 weeks where both systems are live and reconciled daily. We've never lost data on a migration done this way.
Wrong: Users reject the new system
The team hates the new system because it has fewer fields, takes more clicks, or doesn't support a workflow nobody mentioned in discovery. Adoption stalls. The spreadsheet gets resurrected.
Fix: Involve real users in discovery — not just management. Beta with 3–5 friendly users for 2 weeks before broader rollout. The pilot finds 80% of the issues a full rollout would surface.
Wrong: Scope creep eats the budget
The discovery scope was clear. By sprint 4, you're building features that weren't mentioned in the original spec. Budget gets consumed.
Fix: Fixed-scope quotes after paid discovery. Variations tracked, costed, and approved in writing before they enter the work. The team that just absorbs new scope without raising it is the team you'll regret hiring.
Get an honest assessment
Half the prospects who come to us with a spreadsheet-replacement request leave with a recommendation to use SaaS or no-code instead. We'd rather get the answer right than win a deal we shouldn't take.
Book a free 30-minute call and tell us about your spreadsheet. We'll listen, ask the right questions, and tell you honestly whether SaaS, no-code, or custom is the right shape — and roughly what each would cost.