Ask most business owners whether they run any critical infrastructure and they'll think of the phone system, the internet line, maybe the till. Almost nobody answers "the pricing spreadsheet" — even when the pricing spreadsheet is the thing that would actually stop the business first if it broke.
That's not a failure of self-awareness. It's that spreadsheets don't arrive as infrastructure. They arrive as a shortcut: somebody needed an answer on a Tuesday, built a workbook that gave it to them, and moved on. Nobody sits down and decides "this will now be the system the business depends on". It becomes that gradually, a tab and a formula at a time, and there is no launch day, no go-live, no moment anyone signs off. Software gets a decision made about it. A spreadsheet gets a habit that outgrows itself.
That matters because convenience and infrastructure need completely different levels of care, and most businesses are giving infrastructure-level care to something they still mentally file as a convenience. This isn't about spreadsheets being bad. It's about noticing the point at which yours stopped being one thing and became the other, ideally before it tells you itself.
What actually separates the two
A convenience is something a person uses to think. If it's wrong for an afternoon, one person notices and fixes it. Nobody downstream has already acted on the mistake.
Infrastructure is something other people build on without checking. Once a number from the workbook has been quoted to a customer, fed into payroll, used to reorder stock or relied on by someone who wasn't in the room when it was calculated, the workbook has stopped being a tool for the person who built it and started being a service the rest of the business consumes. That shift can happen without a single change to the spreadsheet itself — it happens because of who now depends on the output, not because of anything that changed inside the file.
The trouble is that a spreadsheet gives no outward sign of the shift. It looks exactly the same the day before it becomes load-bearing as the day after. There's no version number, no release notes, no moment where the file itself tells you its job has changed. The only way to know is to go looking.
Four signals you're past the point, not approaching it
1. The output leaves the room before anyone can check it
The test is simple: does a number from the workbook get acted on by someone who has no way to sanity-check it? A quote emailed to a customer, a pay figure that lands in someone's account, a reorder that gets placed on the strength of it. If yes, the workbook has an audience it was never built for, and the person maintaining it usually doesn't know that audience exists.
2. Maintenance time is growing faster than the business is
Take a scheduling workbook that took twenty minutes a week to keep straight when the business ran eight staff. At twenty-two staff it takes an hour. At thirty it takes half a day, because every added person is another set of exceptions the formulas were never built to hold, and each one gets patched rather than redesigned. The workbook isn't getting more useful as the business grows — it's getting more expensive to keep honest, and that cost is rising faster than headcount, which is the actual warning sign. A tool that scales with the business is fine at any size. One where upkeep is outgrowing growth is already behind, and losing ground every month.
3. Nobody can answer what happens if it's unavailable for 48 hours
Ask it plainly: laptop dies, file gets corrupted, the one person who edits it is off sick for a week — what happens for two working days? A convenience has an easy answer: someone rebuilds the missing bit from memory, or the business waits. Infrastructure has no clean answer at all, just a description of which parts of the business stop moving. If the honest response uses the word "improvise" more than once, that's the tell.
4. One plausible error would cost more than a week of profit
This is the one worth actually costing out, because "it would be bad" and "it would be a week's profit" are different conversations with an owner.
Take a job-pricing workbook used by a business quoting 20 jobs a month at an average value of £2,400, on a 30% margin. A single wrong constant — a discount left in from an old promotion, a material rate that was never updated — that quietly under-prices every job by 4% for a quarter goes unnoticed, because no single quote looks wrong in isolation.
4% of £2,400 is £96 a job. Across 20 jobs a month for three months, that's £5,760 of margin gone before anyone spots it. On a 30% margin, £5,760 of lost margin is roughly equivalent to £19,200 of extra sales the business would have to find elsewhere just to stand still.
That figure isn't a prediction for your business — the point is the method. Take your own average order value, an error you can plausibly imagine happening (a stale rate, a dragged formula, a wrong lookup), and your own volume, and run the same three lines. If the result is a rounding error, the spreadsheet is still a convenience. If it's a meaningful slice of a month's profit, it has already become infrastructure, whether or not anyone has decided to treat it that way.
Why the crossing goes unnoticed
Nobody budgets for it because nothing gets bought. Buying software triggers a decision — a price, an approval, a person who signs off and therefore has to think about what it needs. A spreadsheet crosses the same threshold with no purchase order attached, so there's no moment that forces anyone to ask the questions a purchase would have forced.
Growth compounds the problem, because growth is exactly what pushes a workbook across the line, and growth is also the period when everyone is busiest and least likely to stop and audit a tool that "already works". The workbook that was proportionate at ten customers is still running, unexamined, at a hundred, because it never announced that the ground had shifted under it.
What recognising it is actually for
Spotting the point isn't the same job as fixing it, and it's worth keeping the two apart. Deciding what to build instead, or whether to buy something, or whether custom software is warranted at all, is a separate decision with its own trade-offs — one worth making carefully rather than in a hurry, because the wrong replacement can leave you worse off than the risk you started with. If custom software specifically is on the table, this is the honest version of that question.
What recognition buys you is choice. A business that knows its pricing workbook crossed the line eight months ago can plan the fix on its own timetable, at its own pace. A business that finds out because a customer disputes a quote, or because the one person who understands the formulas hands in their notice, is making the same decision under pressure, with worse options and less time. The four signals above cost nothing to check and take an afternoon. What to actually do once you've confirmed you're past the line is worth reading next — but it's wasted effort on a workbook that's still a genuine convenience.
A five-minute test to run this week
Pick the workbook you'd least like to be without. Ask, out loud, in front of whoever relies on it: who acts on its output without checking it, how has the time spent maintaining it changed over the last year, what happens if it disappears for two days, and what one plausible error would cost at current volumes.
Four honest answers, not four defensive ones. If all four come back reassuring, you have a convenience and nothing to do. If even one doesn't, you already know something today that you didn't this morning — and knowing it before the error, the absence or the resignation is the entire value of asking.
Common questions
Isn't every spreadsheet risky by definition — how is this different from just avoiding them?
It isn't an argument against spreadsheets. A workbook someone uses to think through a decision once a quarter carries no risk worth managing, whatever it looks like. The distinction here is about what the output is used for, not what tool produced it: once other people or other systems act on a number without being able to check it themselves, that number is infrastructure, regardless of whether it lives in a spreadsheet, a database or a scrap of paper. Spreadsheets get singled out because they're where this shift happens invisibly — no version control, no audit trail, no moment anyone signs off on the change. The fix isn't avoiding spreadsheets. It's noticing when one of yours has quietly taken on a job nobody assigned it.
We've spotted a workbook that fails more than one of the four tests. Do we need to replace it immediately?
No — recognising the point you've crossed and deciding what to do about it are two different jobs, and rushing the second because the first was uncomfortable usually produces a worse outcome than either extreme. A workbook that fails these tests can often run safely for months longer once you know it needs a second person who understands it, a written note of what it assumes, and a plan for the week it breaks. What you shouldn't do is carry on treating it as a convenience once you know it isn't one. That's the actual risk: not the workbook itself, but continuing to give it casual-tool levels of care after you've established it's carrying more than that.
What if several critical workbooks in the business fail these tests at once?
That's common rather than rare — growing businesses tend to accumulate several load-bearing spreadsheets at roughly the same pace, because the same growth that strains one strains the others. Don't try to fix them together. Rank them by the fourth test: the cost of one plausible error at current volumes. The workbook where a mistake would cost the most, or where the business would notice fastest and most publicly, goes first. The rest are worth a written note of who understands them and what they assume, which buys real time cheaply, even if nothing else changes for months.
We use a shared Google Sheet rather than an emailed spreadsheet — doesn't that already solve most of this?
It solves one problem and leaves the other three exactly where they were. Shared, cloud-based sheets do fix version divergence — there's genuinely one copy rather than four emailed variants — which is a real improvement. But they do nothing about who can act on a number without checking it, whether maintenance time is outpacing growth, what happens if it's unavailable, or what a plausible error would cost. Those four tests are about how the workbook is used and what depends on it, not about which software it's built in. A beautifully shared, perfectly synced spreadsheet can still be exactly as load-bearing, and exactly as underprotected, as the messiest emailed one.