When a spreadsheet is the right MVP - and when it stops being one
The Apps Script back office that ran a company for years, and the signals that told us it was time to rebuild.
An admission that sits oddly in a software consultancy’s blog: some of the best-run back offices we have seen were spreadsheets. Orders in one tab, inventory in another, an Apps Script sending confirmation emails on a trigger, conditional formatting doing the job of a status dashboard. One of them ran a real company for years. It was not technical debt. For most of its life, it was the correct architecture.
That is worth saying plainly, because the industry’s default advice — build a proper system from day one — quietly assumes you already know what the system should do. Early on, you do not. The process is still being discovered: which fields matter, which states an order can be in, who needs to approve what. A spreadsheet is the only tool where the people who own the process can change the software themselves, mid-discovery, without a ticket. A new column is a schema migration that takes four seconds. A formula is a business rule the domain expert wrote, can read, and will fix. And with Apps Script attached, the ceiling is far higher than people assume: time-driven triggers, custom menus, generated documents, calls to external APIs, mail merges. For a five-person operation, that is a back office with a development velocity most product teams would envy.
So the interesting question is not whether a spreadsheet is a legitimate MVP — it is. The question is how to recognize the moment it stops being one. In our experience the signals arrive in a reliable order.
The integrity signal comes first. Two people edit at once and a sort breaks row alignment, silently divorcing every order from its customer. Someone filters, deletes what they can see, and takes invisible rows with it. A spreadsheet has no transactions, no foreign keys, and no concept of an invalid state — the grid will happily hold anything. Early on, one careful owner compensates. The signal is when compensation becomes a rule: “never sort sheet two,” “only Ana touches column Q.” The moment correctness depends on oral tradition, you are maintaining an unenforced schema, and the enforcement budget is human attention.
The scale signal is mechanical and merciless. Apps Script executions hit the six-minute wall. Recalculation across tens of thousands of VLOOKUPs turns every edit into a coffee break. The daily-report trigger starts failing on quota two mornings a week. Unlike the other signals, this one is not a judgment call — the platform publishes its limits, and a growing operation walks into them on a schedule you can roughly predict. When people start splitting the workbook into “2024 archive” files to keep it fast, the workaround itself is the signal.
The audience signal is subtler. The sheet was built by and for the people who run the process. Then the operation grows: new hires need onboarding into its folklore, a partner asks for access to “just their rows,” an accountant needs last quarter’s state — not the current cells, the state as it was. Spreadsheet permissions are tab-coarse at best; version history is a recovery tool, not an audit log; and “what did this order look like when we shipped it” has no answer at all. When the audience for the data outgrows the circle that maintains it, the spreadsheet’s greatest strength — everyone can change everything — inverts into its central liability.
The integration signal usually arrives last and forces the issue. Another system needs the data: the webshop must check stock, the accounting platform must receive invoices, a courier API must get addresses. Teams then build scripts that treat the sheet as a database, and the sheet becomes an accidental API with no contract — one renamed column away from breaking every consumer, most of which fail silently. When the spreadsheet is load-bearing for software rather than people, its schema is frozen by fear, which means the one property that justified it (frictionless change) is already gone.
Any one signal can be patched. Two or more, persisting, is the threshold — and the patches themselves are the tell, because each one (locked ranges, protected tabs, “the rules” document, archive files) removes a bit more of the flexibility that made the spreadsheet right in the first place. When the spreadsheet has been armored into a rigid, slow database with a grid UI, it holds neither advantage: not the flexibility of a sheet, not the guarantees of a system.
The rebuild, when it comes, should treat the spreadsheet with respect, because the spreadsheet is the specification. Years of formulas, validation rules, and column conventions encode the business logic no document ever captured — including the edge cases, which live in the weird nested IFs everyone is afraid of. Our approach: inventory the formulas before writing any code, and interview the sheet’s owner about the folklore rules, because “we never ship on Fridays to Cluj” is in someone’s head, not in any cell. Migrate one workflow at a time rather than big-bang, keeping the sheet as a read-only mirror during the transition so the team retains its familiar window into the data while trust in the new system builds. And prune deliberately: a long-lived sheet accretes columns and tabs that no longer serve anything, and a rebuild is the one natural moment to let them die instead of faithfully porting a fossil record.
One more thing the rebuild should preserve: the sheet’s editability was not an implementation detail — it was the feature. If the replacement system requires a developer for every new field or rule, the operation has traded silent data corruption for a change-request queue, and the domain experts who used to fix their own tools will feel the downgrade daily. Configuration surfaces, admin-editable rules, or even a deliberate, contract-bound export back into spreadsheets for analysis: some of that self-service must survive, or the new system will be quietly routed around — usually into a new spreadsheet.
The pattern behind all of it: a spreadsheet MVP is not a failure to build software. It is a decision to defer building until the process has revealed its shape — and deferring is free exactly as long as the signals stay quiet. Watch for them honestly, and the spreadsheet era ends the way it should: not in a crisis, but in a scheduled migration from the best specification document your team never knew it was writing.