What Sheets is genuinely good at
It is the fastest way to model something you do not yet understand. Building a capacity tracker, a health score prototype, or a weekly scoreboard in a proper system means deciding the schema before you know what you need — and in operations you almost never know until you have run it for a month.
It is also the only tool most teams will actually open. That sounds like a soft point and it is the decisive one for telemetry: a beautifully modelled instrument nobody looks at is worth less than a rough one everybody does. Familiarity is a real property of an operations tool.
And it is genuinely capable. Formulas cover most of the transformation you need, its query and lookup functions handle joins well enough for operational purposes, and Apps Script turns it into something that can be scheduled and integrated when you need that.
We build in it deliberately, most often as the reporting layer of a system whose data lives elsewhere, and as the first version of any instrument where the requirements are still being discovered.
Where it structurally breaks
The first break is concurrent writes, and it is the one that matters. A spreadsheet has no record boundary — a row is a visual convention, not an object — so two writers arriving at once produce silent corruption rather than a conflict. No error is raised. You find out weeks later when a number is wrong and nobody can reconstruct why.
The second is that formulas are invisible dependencies. Insert a column and a reference three sheets away breaks or, worse, quietly points somewhere else. Nothing tells you. A spreadsheet that has been in production for two years and edited by four people has a dependency graph nobody can see and nobody can test.
The third is that there is no state machine. Operations work is about things moving between states with rules about who can move them and what has to be true first. A spreadsheet can record that a cell says approved; it cannot enforce that only certain people set it, or that something else had to be true first.
The fourth is history. Version history exists and is not the same as an audit trail — you can see that a cell changed and it is genuinely difficult to answer what this record looked like on the fifteenth of last month, which is the question that actually gets asked.
The fifth is that it has no notion of required. A record can be created with half its fields empty and nothing objects, so a sheet that has been the operational store for a year contains rows in states that no downstream process anticipated — and the failures show up in the process rather than in the sheet.
How to use it well while you are using it
Separate raw data from presentation. One tab that only receives data, in a flat structure with one record per row and no formulas. Every calculation lives on other tabs referencing it. This single discipline eliminates most of the corruption failures, because the tab that gets written to has no logic to break.
Never insert or delete columns in the raw tab. Append only. Deletion is what breaks references, and appending costs nothing.
Use named ranges rather than cell references anywhere a formula crosses tabs. It is slightly more effort at the start and it means a structural change fails visibly rather than silently.
If an automation writes to a sheet, give it its own tab that no human edits, and reconcile from there. Mixing a human-edited tab and a machine-written tab is the specific configuration that produces the corruption, and separating them buys you a long way.
And put the definition next to the number. A metric on a sheet with no written statement of what is included, what is excluded, and when it counts will be argued about in a meeting within the quarter.
And decide, in writing, whether this sheet is a prototype or a system of record. Most operational spreadsheets became load-bearing without anybody deciding they should be, and the decision is worth making explicitly because it determines whether the disciplines above are optional.
The migration signal, and where to go
Four signals mean you have passed the boundary. An automation writes to it. More than one person edits the same tab. Something downstream depends on the numbers being right in a way that would cost real money. Or somebody has started manually reconciling it against another system, which is the clearest tell of all — manual reconciliation is a person doing a database's job.
Where you go depends on which property you needed. If you needed a record boundary and a state machine, the answer is the operational system that already owns that data — the CRM for anything about deals and clients, the project tool for anything about work.
If you needed an interface over data that lives elsewhere, that is what Retool is for: a real application layer with permissions and enforced writes, built in days rather than months.
If what you actually needed was a durable structured record with a decent editing experience, Notion carries that well — properly typed properties and real relations, at the cost of the calculation power you had in Sheets.
What is almost never right is moving to a bigger spreadsheet or a more sophisticated one. The constraint you hit was structural, and every spreadsheet has it.
The honest position
Sheets gets dismissed by people selling platforms and defended past the point of sense by people who like it. Both readings miss the actual line.
It is an excellent modelling tool, an excellent reporting surface, and an acceptable single-writer store. In those roles it beats more sophisticated alternatives on the only axis that matters operationally, which is whether people use it.
It is not a database, and the failure when you treat it as one is silent rather than loud, which is what makes it expensive. You do not get an outage; you get numbers that are subtly wrong for a quarter and a team that gradually stops trusting them.
The practical position we take on builds: prototype every new instrument in Sheets, run it manually for a month, and only then decide what it should be built in — because a month of running it tells you which of the four boundaries you are actually going to hit, and most instruments never hit any of them.
The boundary is writers, not rows. One human writer and Sheets is a legitimate operations tool; a second writer of any kind and you need a real record boundary.