The spreadsheet is the spec
Before we replace a client's spreadsheet with a real internal tool, we read every column, every macro, and every dead tab. The spreadsheet already is the system — the rebuild is a transcription with permissions and a query layer.
by John P.
A client emails: "we want a system to replace our spreadsheet." Our first question isn't "what do you want from the system." It's "send us the spreadsheet — all of it, with the hidden tabs, the macros, and the cell comments left over from 2022." Because the spreadsheet already is the system. The rebuild isn't design work — it's transcription.
In a real working sheet there's almost always more noise than you'd guess. Live business logic crammed into formulas. Dead rows nobody remembers why they exist. Macros written years ago by somebody who isn't at the company anymore, still running on Mondays because nobody has dared delete them. Tabs hidden by right-click, never reopened. Workarounds that have hardened into unwritten rules over three quarters. We've inherited this collection before — the link-building platform we shipped started life as one shared spreadsheet doing six-figure revenue.
The breakdown above is a real client sheet, anonymised. One file, fourteen tabs, seventy-three columns, nineteen named ranges, four macros. Of those, roughly a third was already dead — duplicates, outdated rows, comments that became data and got forgotten. The rest was the spec. Every live column became a table or form field; every macro became a scheduled job; every hidden tab labelled "who sees what" became a permission role. The work wasn't designing a system. It was listening to the one that was already running.
Where most studios lose the plot is greenfield. They take the brief, ignore the sheet, and build the "ideal" system. It demos beautifully and is unusable on Monday because it doesn't know the unwritten rules. The two rebuilds we did last year were both follow-ups: each team had quietly abandoned a greenfield system and gone back to a spreadsheet, and we were brought in to make that spreadsheet legitimate. They took half the time of the abandoned builds, because we started from what each team actually does on Tuesdays. The unromantic part was asking what "Status: PARK" means in column F, and then asking again, until somebody on the team could tell us. The companion lesson is the one we wrote about un-frameworking the CMS: pay attention to the operation, not to the deliverable that fits the demo.
The hours above are real, drawn from three custom-systems projects we shipped last year. Weekly ops time per client team dropped from an average of thirteen hours to under two. The fall isn't from automation magic. It's from a team that finally trusts the numbers again — because the numbers don't live in "spreadsheet final v3 FINAL (use this one).xlsx" in someone's downloads folder anymore. One source, one question on standup: "where did you get that?" → "from the dashboard." Conversation over.
What we won't sell you is a greenfield rewrite of a process the client hasn't actually run yet. If there's no spreadsheet — or notion doc, or piece of paper taped to the wall — there's no process. There's a wish. We don't build software for wish lists. Run the work by hand first, with whatever's in front of you; then come back. This is the most common conversation we lose at the proposal stage, and we're not changing it.
What changed since we started saying this out loud: clients started showing up with the sheet. Not a Figma mock, not a ten-page PRD — a screen-share of the spreadsheet and an hour to pull it apart together. The conversation gets concrete, the estimate gets honest, the rebuild ships where we said it would. Transcription is less glamorous than greenfield. That turns out to be exactly the point.