From Spreadsheet to System
The spreadsheet that began as a quick fix now runs a core part of your business - and only one person really understands it. I turn fragile, business-critical spreadsheets into real systems: proper applications, a real database, the integrations that let data flow instead of being re-keyed - so your best people get their time back and the process stops being a risk.
When the spreadsheet becomes the system
Almost no one decides to run the business on a spreadsheet. It starts as one person's quick fix, spreads because it works, and one day something that genuinely matters - the pricing, the orders, the compliance return - depends on a workbook nobody designed for the job. The file has become a system. It just has none of the things a system needs: no controls, no audit trail, and no one but its author who can safely change it.
What it's quietly costing you
- The key-person risk - one person holds the logic in their head, and the process wobbles the moment they are on leave, ill, or gone
- Errors that surface too late - a wrong formula or a mistyped cell reaching a customer, a board pack or a regulator before anyone catches it
- Version chaos - competing copies emailed around, and no one certain which one is the truth
- A ceiling on growth - more users, more data and more edge cases than a spreadsheet was ever built to hold
- Your best people taxed - senior time spent nursing and re-keying a workbook instead of the work that moves the business forward
A spreadsheet is a canvas, not a system
This is the part most people miss. A spreadsheet has some rules in it - a formula here, a validation there - but it does not enforce a process. A person does. The real process lives in the head of whoever runs it: which exceptions are allowed, when to override the number, what to do with the order that does not fit, the thing that is always done differently on a Friday. The workbook is only half the system. The other half is human judgement, and almost none of it is written down.
That is why turning a spreadsheet into a system is harder than it looks. A system is constrained by definition - it encodes the rules and it holds people to them. So every one of those unwritten judgements has to be found, and then decided on: is this a rule the system should enforce, or a decision a person should still make, with the system supporting them rather than replacing them?
Get that wrong in one direction and you build something too rigid to survive a real week - and the team quietly starts keeping a spreadsheet alongside your new system, which is how most of these projects actually die. Get it wrong in the other and you have rebuilt the same mess behind a nicer interface.
So first, I learn what you actually do
I sit with the people who run the process - not the process document, the people - and watch what they really do. Where they hesitate. What they check twice. The workaround nobody mentions because it is just how it has always been done. Every rule buried in a formula gets mapped, and so does every rule buried in someone's head.
Only then is it clear what the system must enforce, what it should simply make easy, and where a person still needs the final say. Most of the skill in this work is knowing which is which. That judgement is the thing you are actually buying, and it is the part no tool and no AI can do for you - because the answers are not in the spreadsheet. They are in your business, and in your people.
I turn it into a system you can trust
I rebuild the process as a real application: a proper database in place of a grid of cells, and the integrations that connect it to the systems you already run - the CRM, the finance stack, the database that has been there for twenty years - so data flows instead of being copied by hand. Every change is tracked. The whole team gets safe, role-appropriate access rather than a master copy passed around by email. It is built quickly, by one senior engineer directing a team of AI, and it is yours: the code, the data and the documentation, all of it.
Why a senior engineer, not a no-code tool
Even once the process is understood, the build is where these projects come apart. Point a no-code tool at the spreadsheet yourself and you own another fragile thing to maintain - one that stalls the moment it meets a real integration, a data migration, or anything a regulator cares about. Hand it to the cheapest developer you can find, or let an AI generate it overnight, and what you get is a convincing demo rather than something you can run the business on: the integrations half-done, the migration untested, the security an afterthought, and nobody who can safely change it.
Building it so it holds is ordinary engineering discipline, and it is what twenty-six years across defence, banking and national digital identity buys you - systems built where a wrong number was expensive. Independent, too: no product to upsell, and no licences to resell.
How it works
- It starts with a Delivery Blueprint - a short, fixed-fee diagnostic that maps the spreadsheet, ranks what is riskiest, and hands you a costed plan; the fee comes off the build if you go ahead
- Then a fixed-price Delivery Sprint builds it - scope, price and timebox agreed before work starts, acceptance criteria set on day one
- Business-critical spreadsheets are replaced in phases, running in parallel - the new system proves itself alongside the old file before anything is switched off
- Everything stays with you - the code, the data and the documentation, hosted in your own accounts
It runs on the same machinery as every DBHQ engagement - the Delivery Blueprint, then a fixed-price Sprint. No open-ended discovery, no report left in a drawer.
I have done this for two decades
At a tier-1 UK bank, a quant and analyst team worked out what each affected customer was owed - the redress, and the consequential loss on top - in spreadsheets, one case at a time. That was fine at pilot scale. The portfolio ran to more than 100,000 cases and over £1 billion, copies had drifted far enough apart that the same case could come out at different numbers depending on whose workbook ran it, and a spreadsheet cannot show a regulator its working.
Almost none of the real logic was in the files. Analysts overrode the answer on cases they knew the formula had got wrong, and nothing recorded why, or when that was allowed. The same rule existed in three versions across three copies, so before anything could be encoded somebody had to decide which one was actually right. That came out of sitting with the people who ran the process, not from reading their workbooks. And not all of it became a rule: some decisions stayed with a person, with the system putting the evidence in front of them and recording the call.
It became a production system - a .NET application over a SQL Server database - with every figure traceable to its inputs and to the version of the rules that produced it. It passed FCA and SOX audits, and went from that first pilot to bank-wide.
That was not a one-off. Over eight years there the same job came round again and again - fraud, consequential loss, and plenty of other places where a spreadsheet had quietly become the system. See the work.
Questions, answered
- Isn't a spreadsheet fine?
- Often, yes - until the business depends on it. The problem is not Excel; it is a critical process running with no controls, no audit trail and a single point of failure. When that is what you have, it has outgrown the tool.
- Can you replace the one we depend on right now, without downtime?
- Yes. The rebuild runs in phases, in parallel - the new system proves itself alongside the existing spreadsheet before anything is switched off. Nothing stops while it is replaced.
- Will we be locked in?
- No. You own the code and the data, hosted in your own accounts. Nothing is licensed from me, and there is nothing to unpick if you ever bring in someone else.
- What does it cost?
- A fixed fee, quoted after a short call, never open-ended. It starts with a Blueprint whose fee comes off the build it leads to - so the scoping pays for itself if you go ahead.
- How long does it take?
- The Blueprint is two to three weeks. The build is a fixed-timebox Sprint, scoped to exactly what the Blueprint found - weeks, not quarters.
The Spreadsheet Health Check
Not sure it is a risk yet? Run the free Spreadsheet Health Check - drop in the workbook and see in seconds what is fragile, all in your browser, nothing uploaded. Or send me the file and I will tell you what I would fix first and what it would take - no charge, no obligation. Start there.
Fifteen minutes will tell you if this fits
Bring the problem - the stalled pilot, the systems that do not talk, the manual process eating your team. You will get a straight answer on whether it is sprint-shaped, roughly what it would cost, and when it could be running.
I reply within 24 hours