From Spreadsheet to System
When a spreadsheet carries a business-critical process, the first decision is what needs to change. DBHQ investigates the rules, exceptions and dependencies, then delivers an agreed improvement - stronger controls, integration with existing software, or a replacement application.
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.
When replacing it is the answer
The answer is not always a rebuild - stronger controls, a product you can buy, or connecting what you already run may be enough, and the investigation is what settles it. When a rebuild is the right call, 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 by one principal engineer, with AI applied inside the delivery itself, and it is yours: the code, the data and the documentation, all of it.
What it takes to build it so it holds
Even once the process is understood, the build is where these projects come apart, and what decides it is rarely the tooling. Four things have to be in place: a process owner who can settle what the rules actually are, a representative set of real cases rather than the tidy ones, reconciliation criteria agreed before anything changes over - how the new answers get checked against the old, and what counts as a match - and a named operational owner to hand the finished thing to. Where those are missing, no platform choice rescues it, and the honest first job is to establish them.
Building it so it holds is then ordinary engineering discipline, and it is what twenty-six years across defence, banking and 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
The work runs as a fixed-price Production Delivery Sprint, with scope, price and acceptance criteria agreed before anything starts. Where the rules, exceptions and dependencies are not yet clear enough to quote, a Delivery Definition answers the named questions first, priced and charged on its own. Migration, training and support are scoped and priced with the work rather than assumed into it. Everything stays with you - the code, the data and the documentation, hosted in your own accounts.
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 seven 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.
- Does this always mean replacing the spreadsheet?
- No. The investigation can land on any of four answers: stronger controls around the workbook you already have, moving the process onto software you can buy, integration with existing software so the re-keying stops, or a replacement application. Which one is right is a finding, not the starting assumption.
- Can you change the one we depend on right now?
- Usually, and a parallel run is the normal approach - the new route proves itself alongside the existing workbook before anything is switched off. Whether that works here depends on the process, the data and who can authorise an exception while both are running, so the cutover is agreed in the scope rather than promised in advance.
- 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. Migration, training and support are scoped and priced with the work rather than assumed into it. Where the process is not yet clear enough to quote, a Delivery Definition answers the named questions first, priced and charged on its own.
- How long does it take?
- The build is a fixed-timebox Sprint - weeks, not quarters. A Delivery Definition, where one is needed first, is around five working days of effort.
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. Then bring me what it found, and fifteen free minutes will tell you whether it is worth doing anything about.
Need this process changed?
Describe what the business needs to do, what is stopping it and any deadline. DBHQ will establish whether the work fits and whether there is enough information to quote.
I reply within 24 hours