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 actually 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
Which is why this work starts with people, not code. I sit with the people who actually 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 commanding 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
None of this is new work for me. Finance reporting rebuilt from manual re-keying into an automated warehouse; legacy systems finally made to talk to each other; a manual reporting process replaced end to end. The same pattern runs through the work - take the fragile, manual thing a business depends on and make it dependable. 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. There are no licences to me, and 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 don't talk, the manual process eating your team. You will get a straight answer on whether it is sprint-shaped, what it would cost, and when it could be running.
Delivered inside defence, banking and national digital identity
I reply within 24 hours