Your spreadsheet was always a database
Someone showed me a thing last week that they’d built — not a developer, no intention of ever becoming one — by talking to an LLM. It did something genuinely useful. It worked. It had been quietly working for months. And the reaction from the engineers who’d seen it was the reaction I’ve now seen a dozen times: a sort of appalled fascination, followed by a list. It doesn’t validate its inputs. The credentials are sitting in plain text. It won’t survive a second user. It can’t be deployed. Who owns it? Where are the tests?
Every item on the list is true. And every item walks straight past what had actually happened, which is that a person with a problem nobody else was solving sat down and solved it.
The industry has decided this is new, and a little dangerous — “citizen developers”, “vibecoding”, unsanctioned software seeping in at the edges. I want to make the case that it is not new at all. We have been doing exactly this, in plain sight, for thirty years, and we built whole companies on top of it without anyone reaching for the smelling salts.
We have always done this
Walk into any business that has been running for more than a few years and you will find them: the Excel workbook that is really a database, the Word document that is really a form, the macro nobody alive understands that finance run on the last working day of the month. Somebody reached for the tool already open on their desk because they had a problem and the queue for “proper” software was six months long and pointed the other way. They made a tracker. The tracker was useful. Other people started using the tracker. At no point did anyone stop and say this should be a database, or this needs to scale, or where are the access controls. It simply grew, a column at a time, into part of how the business works.
We didn’t call that shadow IT and shun it. Excel is, by a distance, the most widely used programming environment on earth, and almost none of the people writing in it would tell you they were programming. They were getting the thing done. The spreadsheet was never really a spreadsheet — it was a database with the serial numbers filed off, folded into a grid, and it was integral to the business long before anyone admitted it.
So when I watch someone in the team build a small app by describing it to a model, I don’t see a new species of risk. I see the same instinct that produced the spreadsheet, handed a more powerful tool. The grid got bigger. That is most of what changed.
The example the industry keeps leaving out
Here I have to declare an interest, because there is a third member of this family, and it’s the one I have personally been shunned for.
I came up as a software engineer. I have stood on the orthodox side of this argument with total confidence. I have been handed someone’s spreadsheet-that-runs-the-department and felt the engineer’s particular blend of contempt and panic, and I have said the words out loud: this isn’t a real system, this should be rebuilt properly, look at the state of it.
Then I edged into data science, and the spreadsheet became mine.
A data scientist’s notebook is end-user computing too. It’s a person reaching for the familiar tool — a few cells of Python, the output sitting underneath — to answer a question the formal system isn’t answering: is this number really going up, does this model actually help, what on earth is going on in the data. It is informal. It has the credentials hard-coded near the top. It runs end to end only if you know which cells to skip. It does not scale and it does not deploy. And then one day someone important starts making decisions off the chart it produces, and the notebook is integral, and now I am the one being told by an engineer that this isn’t a real system and ought to be rebuilt properly.
Having sat in both chairs, I can tell you the engineer is making the same mistake each time. The vibecoded app, the operations spreadsheet, and my notebook are not three problems. They are one phenomenon — people solving real problems with the nearest tool to hand — wearing three different costumes. The contempt travels from one to the next entirely unchanged.
The engineers are not wrong — they’re early
I want to be fair to the list, because the list is not paranoid. The spreadsheet horror stories are real, and they are expensive.
In October 2020, Public Health England lost roughly sixteen thousand positive COVID-19 results — not to a hack, but because the file they were collating into had been saved in an old Excel format that stops at 65,536 rows. The cases past the line were simply dropped, and the contact-tracing calls that should have followed them never went out, in the middle of a pandemic. A decade earlier, an influential economics paper, Reinhart and Rogoff’s Growth in a Time of Debt, was found to rest partly on a spreadsheet whose averaging formula had quietly left five countries out of the calculation; correct the omission and the headline number flips from a 0.1% decline to a 2.2% rise — after the original had already been wielded across Europe to argue for austerity. JP Morgan’s “London Whale” losses in 2012 were magnified by a risk model living in spreadsheets, with figures copied by hand from one sheet to the next and a formula that divided by a sum where it should have divided by an average.
So no — I’m not going to tell you the informal thing is always fine and the engineers should relax. Sometimes it is genuinely dangerous. But look closely at when the danger arrives. Not the day someone opened Excel. Not the afternoon the chatbot wrote the app. The failure lands much later, at a specific and almost always unmarked moment: the day the scratchpad became infrastructure and nobody said so. Public Health England’s problem was not that someone reached for a spreadsheet. It was that a spreadsheet had quietly become a piece of national health plumbing and was still being treated like a spreadsheet.
That is what the shunning gets wrong. It fires at the moment of creation — the one moment the informal tool is doing nothing but good, solving a real problem cheaply for the person who has it. The moment that actually warrants attention comes later, and it is a transition, not an origin.
Certainty is a destination, not an entry fee
The engineering reflex is to demand that everything be born production-ready: validated, tested, access-controlled, owned, deployable. Hold a vibecoded tool or a notebook up to that standard and of course it fails — but so did the spreadsheet, and the spreadsheet was right to. None of these things were built to be production systems. They were built to find out whether the problem was even worth solving, and they answered yes by being used.
Scalable, secure, deployment-ready: these are not prerequisites for being allowed to exist. They are properties an artefact earns as it becomes integral. That, more or less, is the whole argument I keep circling — that the road from a notebook to a system is a real road with real stages, and you do not have to travel all of it on the first day. You take on technical debt deliberately when you build the quick thing, and that is usually a sound trade; debt is only a problem when you stop servicing it. The work is not to stop people reaching for the familiar tool. The work is to notice when what they built has become important, and then to walk it the rest of the way — to give it the version control, the tests, the proper home for a secret, the named owner — at the point where those things finally start to earn their cost.
That reframing also changes who the difficult person in the room is. It is not the operations analyst with the chatbot, or the data scientist with the notebook. It is whoever is still pretending, six months in, that the integral thing isn’t integral — that we’ll get round to doing it properly one day, while the business quietly runs on it in the meantime.
So ask the better question
The next time you find one of these — and you will, they’re everywhere, they always were — try not to open with the list. The list is for later, and it’s mostly right when it gets there. Open instead with the question that actually scales: not should this have been built properly? but is this integral yet, and is anyone willing to admit it?
Because the spreadsheet was always a database. The document was always a form. My notebook was always going to end up in front of someone who mattered. The only thing that was ever genuinely new was the size of the grid — and the only mistake that was ever truly dangerous was refusing to notice the day the toy became the tool.
Part of an occasional series reframing everyday engineering through a data scientist’s eyes. The ideas here are developed properly in Thinking in Uncertainty and Building with Certainty.