Blog · Operations
Every operations spreadsheet is a system in the same way that a Jenga tower is a building. Here's how to tell when yours is one wrong pull away from collapsing — and what to do before it does.
Most SMBs run on a spreadsheet for far longer than they should. The transition from 'this spreadsheet works' to 'this spreadsheet is the single biggest risk in our operation' happens gradually, then all at once. The three signs that you crossed the line: (1) more than one person edits it daily and you've had at least one merge conflict / overwrite this quarter; (2) more than 30% of your team's time on the workflow is spent fixing the spreadsheet rather than doing the actual work; (3) you can't answer 'who changed what and when' without forensics. If two of these are true, you stopped having a spreadsheet — you have an undocumented application without a backup.
A spreadsheet that runs your operation is almost always the cheapest tool you'll ever regret keeping. The monthly cost is $0. The switching cost feels enormous. So nobody switches until something breaks, and by then the break is expensive: a payroll error, a lost deal, a missed regulatory deadline, a customer charged twice, an inventory miscount.
The hidden cost has four buckets that almost never show up in the SaaS budget line:
Below are the three diagnostic signs we use with clients. If any two are true, the "do nothing" option is no longer cheaper — it's just costing you in a different line.
Multiple people edit the spreadsheet on the same day, and at least once in the last quarter someone overwrote someone else's changes. Maybe you have a Slack message that reads something like: "who deleted the totals row??".
Why this matters: Google Sheets and Excel handle concurrent edits with last-write-wins. That's fine for documents. It's a quiet disaster for systems of record. The longer this continues, the more your team builds informal protocols around the tool ("nobody touch the sheet between 9 and 10am while Maria reconciles") that act like compatibility shims for software that was never meant to be a system.
More than 2 daily editors + any "yes" on rows 2–3 = sign #1 confirmed.
More than 30% of the time your team spends on this workflow is spent on the spreadsheet itself, not on the actual work the spreadsheet is supposed to support. The spreadsheet has become its own job.
What "maintenance" looks like in practice:
Ask the team that owns the workflow: "if you didn't have to touch the spreadsheet at all, how many hours/week would this workflow take?" Then ask: "how many hours/week do you actually spend on it now?" The delta divided by the second number is your maintenance ratio. If it's >30%, sign #2 is confirmed.
Real numbers we've seen at SMBs: a 6-person sales ops team spent 14 hours/week combined just keeping a lead-tracking spreadsheet consistent. At a loaded $45/hour, that's $32,760/year of payroll going into spreadsheet plumbing.
You can't answer "who changed what and when" without forensics. Version history shows edits at the cell level but doesn't tell you which business event triggered them. "Cell B14 changed from 12,500 to 14,300 at 2:47pm on Tuesday" is not the same as "James updated the deal value after the rep negotiated a price increase".
This becomes a real problem the moment you have to:
Google Sheets keeps version history for 30 days by default. Excel's depends on OneDrive settings. Neither tells you why something changed — only that it did. The moment "why" matters, the spreadsheet is the wrong system.
One sign in isolation? Probably manageable. Two signs simultaneously? You've crossed the line. The compounding interactions are what kill operations:
If you want a guided self-assessment, the Spreadsheet or Software decision tree walks through six questions and gives you a verdict in 2 minutes.
The most expensive mistake here is jumping straight from spreadsheet to custom software when a lighter tool would do. The right replacement depends on how stable the workflow is. Stable workflows can go straight to custom; still-evolving workflows should land in low-code first.
If you want to ballpark the build cost specifically for your workflow, the budget calculator will give you a range. Or read what an automation project actually costs in 2026 for the underlying math.
Most failed spreadsheet-to-system migrations fail for the same four reasons. None of them are about technology.
When (a) one person owns it day-to-day, (b) the maintenance ratio is below 15%, (c) you don't need an audit trail beyond version history, and (d) the workflow rarely changes. Plenty of operations live in spreadsheets forever and that's fine. The problem isn't the spreadsheet — it's running an operation on one that's already cracked under multi-person, high-volume, audit-required usage.
Three quick tests. (1) Can you describe your workflow in Airtable's view + record + automation primitives? If yes, Airtable is enough. (2) Do you need workflow logic Airtable can't express cleanly (multi-step approvals with branching, complex calculations, integrations with non-standard tools)? If yes, you'll outgrow it. (3) Are you over 30 users or 50K records? You're hitting Airtable's comfort zone — custom or Retool is more cost-effective past that scale.
To Airtable or Notion: 1–3 days for the migration itself, plus 2–4 weeks of parallel running before you fully cut over. To a Retool/Bubble internal tool: 2–4 weeks build + 2–4 weeks parallel. To a custom internal application: 5–8 weeks build + 4–6 weeks parallel. The parallel period is non-negotiable — it's where you catch the edge cases the spreadsheet was silently handling.
It helps but doesn't eliminate the problem. Microsoft 365's co-authoring reduces accidental overwrites and gives you better version history. But it still doesn't give you record-level audit trails tied to business events, role-based access at the row level, validation rules enforced server-side, or the ability to expose only a subset of data to specific users. If you only have sign #1 (concurrency) and not signs #2 or #3, modern Excel/Sheets is often enough.
Math the hidden cost honestly first. A dedicated 'spreadsheet maintainer' at $45/hour loaded × 20 hours/week = $46,800/year — every year, forever. An Airtable migration costs $1,000–$3,000 one-time and ~$2,500/year in licenses. A custom replacement costs $14,000–$30,000 one-time and ~$3,000/year in hosting. Even the most expensive path pays back in year 2. The 'just hire someone' answer almost never wins the math if you do it honestly.
We don't — but the two-of-three rule is engineered to be self-administered. If you can answer the diagnostic questions honestly (multi-person daily edits + an overwrite in the last 90 days + >30% maintenance ratio + audit blindness), you have your answer. If you want a second opinion, the Spreadsheet or Software decision tree on /resources walks through six questions and gives you a verdict in 2 minutes.
Blog
Tell us what the workflow does and how many people touch it. We'll come back with a path — Airtable, Retool, or custom — and a number. No hard sell if low-code is the right answer.
Tell us the problem →
