When does a spreadsheet become a system?

‍

There's probably a spreadsheet somewhere in your business that everyone is slightly frightened of touching. It might be called the Master, the Bible, or just "the sheet". One person knows how it works, everyone else knows not to mess with it, and if it disappeared tomorrow quite a lot of work would grind to a halt.

What interests me about these spreadsheets is that they're rarely the result of a business refusing to invest in software. Usually it's the opposite. The company already pays for a perfectly good CRM, accounting package or job management platform, but there's something particular about how it operates that those products don't accommodate. So someone creates a spreadsheet to fill the gap. Then another. Before long the most important parts of the business are happening outside the expensive software everyone was supposed to be using.

Businesses have put up with this for years, because building custom software to handle a small, specific workflow was hard to justify financially. That's starting to change, and I think a lot of small and medium-sized businesses haven't realised it yet.

Why do businesses end up with so many spreadsheets?

Because off-the-shelf software is built for the average business, and yours isn't average. Your CRM might be excellent at managing customers and sales opportunities, but your quoting process involves a pricing calculation it can't handle. Your accounting software does the numbers, but your finance director still combines figures from three places to produce the monthly management report.

None of that means you've bought the wrong software. It means there's a gap between what the product does and how your business works, and spreadsheets are very good at filling gaps. They're flexible, familiar, cheap and nobody needs permission to create one.

The trouble starts when the spreadsheet stops being a convenient tool and becomes an essential part of running the business.

How do you know when a spreadsheet has become a problem?

When several of these are happening regularly, the spreadsheet has become the system.

You're spending too much time moving information around. Someone exports data from the CRM, works on it in Excel, sends it to a colleague, and someone else types the results into a different system. When that happens every day, the time adds up, and so do the mistakes.

‍

It's getting hard to trust the data. Different people have different versions, information is entered inconsistently, and meetings turn into arguments about which numbers are correct rather than what the numbers mean. That's a real problem when management decisions depend on them.

You can't see what's happening now. Your monthly report might be excellent, but it takes someone two days to prepare. You have plenty of history and no easy way to spot a problem while it's developing.

Compliance is a scramble. If an auditor, insurer or regulator asks for evidence and you have to pull together spreadsheets, emails, PDFs and scanned documents, every request becomes a small emergency.

I wouldn't suggest replacing every spreadsheet in an organisation. Plenty are doing a good job, and building software for its own sake is a waste of money. Sometimes a better configuration of the tools you already have is all that's needed. But when several of these are true at once, the process underneath is worth a proper look.

What does this look like in practice?

Two of our own projects show the two versions of it: software that collected data but gave nothing back, and compliance that was running on spreadsheets or not at all. Both clients are ours, so read what follows with that in mind.

The ABC: data going in, nothing coming out

‍

The Association of British Climbing Walls (ABC) represents around 250 member climbing walls across the UK. I spoke to its CEO, Kath Hipwell, on The Humans Behind the Tech about how the industry records and learns from accidents.

Kath makes a distinction between calling a sport safe and making it safer. Making it safer means collecting information about accidents and near misses, understanding why they happen, and using that to reduce the chance of them happening again. The ABC already had an online system for this, but it was limited. Walls were, in Kath's words, "having to fill things in online and have bits of paper and scan bits of paper", and the only way to look at the results was to export them to a spreadsheet:

"The previous product was quite static in a sense. So it collected data and it lived in an online repository that could come out as a spreadsheet, but it didn't have a sense of live reporting."

The information was being collected, and the people providing it weren't getting anything back. So we built a platform where walls record incidents, manage the paperwork and signatures, and see what's happening in their facility: where accidents occur, which injuries are most common, and how their rate compares with anonymised data from the rest of the industry. If people keep turning their ankles under one section of wall, the manager sees it in the reporting that week rather than in a solicitor's letter months later.

Kath pushed for one detail I thought was clever: an interactive diagram of the human body for recording injuries, instead of a text box. If one person writes "twisted ankle", another "left ankle injury" and a third "sprain", nobody can analyse anything. Structured data from the start is what makes the comparisons possible.

The ABC's historical incident data came across into the new platform, and access is role-based so front-of-desk staff, managers and the association each see what they need. Design, build and test took about three months. Within the first six months Kath reported roughly five times the uptake of the previous platform, and I suspect that's mostly because the new system gave people a reason to use it. Wall managers learn something about their own facility every time they log in. There's more on the ABC project here.

Mariana UFP: compliance on spreadsheets, or not at all

Mariana UFP is a London derivatives brokerage, and market abuse rules require its compliance team to monitor every trade and every client communication for signs of things like insider trading. Their existing system was expensive and didn't cover all of it, so the rest was being done on spreadsheets, or not at all.

We built them a platform that flags the trades and messages that need a compliance look, with the escalation steps built in, pulling straight from their own systems. Their verdict was that it's "better, cheaper and more reliable than the one we had before". More on the Mariana project here.

A climbing trade body and a derivatives broker have nothing in common except this: the software they had didn't do the whole job, and the gap was being filled by exports, scanned paper and spreadsheets.

Has custom software actually got cheaper?

For well-defined internal tools, yes. Until recently, commissioning bespoke software for a narrow operational problem was hard to justify. By the time you'd paid for design, development, testing and deployment, the cost could outweigh the inconvenience of living with the spreadsheets.

AI-assisted development is changing that. At Old.St Labs we've built AI tools into our engineering process from end to end, and the time many development tasks take has dropped substantially. That doesn't mean anything can be built for next to nothing, or that a complicated project becomes simple. But for a well-defined internal tool, particularly one that connects to systems you already use, the economics now look quite different. A project that couldn't justify its budget two years ago may be viable today.

You also don't need to replace the software you've already invested in. If HubSpot is managing your pipeline well, keep HubSpot. If Xero is doing your accounts, keep Xero. What you may need is a relatively small application that connects the two, automates one process, or produces the report neither product can.

‍

‍

What if someone has already vibe coded a replacement?

Then you're ahead, and I'd encourage it. The newest version of the Bible isn't a spreadsheet at all. It's a small app that someone in operations or finance built in an afternoon with Lovable, Replit or Claude, because they were sick of the sheet. It does the job for their team, nobody in IT knows it exists, and it's usually quite good.

That's useful to us, not a problem. A working prototype is the clearest brief we ever get. It shows exactly which gap the spreadsheet was filling, who uses it and what they need from it, and that takes a lot of the friction, time and cost out of building the proper version. So if someone on your team wants to vibe code their way out of a spreadsheet, let them. The moment to come and talk to us is when it starts holding real data, when other teams start depending on it, or when it goes anywhere near a customer. We've written about why the last 20% of a vibe-coded app is the expensive part and what the security risks are, and the short version is that those are the points where "quite good" stops being good enough.

What hasn't got cheaper?

Understanding what needs to be built. You can automate a broken process and end up with a very efficient way of doing something you shouldn't be doing at all.

Before building anything, you need to know why the spreadsheet exists, who uses it, where its information comes from, what decisions depend on it and what happens to it afterwards. You also need to check whether the SaaS you already own can do the job with a different configuration, an integration, or a feature nobody has explored. This is why we spend time on how a business operates before recommending anything technical. Sometimes the spreadsheet people want to replace isn't the problem, and occasionally the right answer is to leave things exactly as they are.

The ABC project is a good illustration. The opportunity wasn't a nicer way of recording incidents. It was making that information useful to the people running climbing walls, and improving the data available to the whole industry. That's a different brief from the one that walked in the door.

So should you replace your spreadsheets?

Not necessarily. If a spreadsheet is maintained by one person, does a simple job and rarely causes trouble, leave it alone.

But if people are regularly copying information between systems, spending hours assembling reports, or relying on one complicated spreadsheet to run a critical process, it's worth asking whether there's a better way. The options aren't limited to keeping the spreadsheet or commissioning an enormous platform. You might configure what you have, connect two existing tools, use a low-code product, let someone vibe code a first version, or commission something small that does exactly what your business needs. And because the cost of building software is changing, ideas that looked too expensive a year or two ago are worth revisiting.

If there's a spreadsheet in your office that everybody calls the Bible, I'd be interested to hear what it does. Chances are it's telling you quite a lot about what your business actually needs, and we're happy to have a look and tell you what we think.

‍