Solution
Replace the spreadsheet your business runs on
A spreadsheet that four people edit is not a database, and the day it becomes one is the day it starts costing you more than it saves.
Start with the workflow that costs you the most
Tell us what the process is and what it currently runs on. A senior engineer reads it and replies with either questions or a straight answer that we are not the right fit.
What is actually going wrong
Spreadsheets are extraordinary software and most businesses should use more of them, not fewer. They are the fastest way ever invented to model a problem, and a great many processes should never be anything else. This page is not an argument against spreadsheets. It is about the specific moment one stops being a tool and becomes the system your operation depends on.
That transition is always accidental. Someone builds a tracker for themselves, it works, others start using it, and within two years it holds live operational data, has no access control, no history of who changed what, no validation preventing a date being typed into a quantity column, and one person who understands the formulas. Nobody decided this. It happened one useful addition at a time.
The failure mode is not that the spreadsheet is bad. It is that it has no concept of concurrent users, no audit trail, and no way to stop an accidental sort from silently detaching every row from its neighbour. Those are not bugs. They are simply not what the format is for.
You will recognise some of these
- Filenames ending in _final, _final_v2 and _FINAL_use_this
- A rule that only one person may have it open at a time, enforced by asking in a group chat
- Someone re-sorted a column and it took a week to notice which rows were wrong
- Nobody can tell you who changed a figure, or when, or what it was before
- Formulas only one person understands, and that person is on holiday
- Copies emailed around, edited separately, and merged by hand afterwards
- A weekly report built by pasting from three sheets into a fourth
- The file has grown slow enough that opening it is a coffee break
Tell us which workflow it is
A short description of the process and what it runs on now is enough to get a straight answer on whether this fits.
What you actually lose by staying
The obvious cost is time: the manual consolidation, the double entry, the half-day report. That is the one people count, and it is usually the smaller half.
The larger cost is the decisions made on wrong numbers. A spreadsheet gives you no way to know that a figure was overwritten last Tuesday, so an error propagates quietly into reports, quotes and forecasts, and is found weeks later by accident if at all. There is no audit trail because there cannot be one, and no validation because the format has no opinion about what belongs in a cell.
Then there is the concentration risk. When a critical process depends on formulas that one person wrote and only they understand, that is a single point of failure sitting in your operation, and it will be discovered at the worst possible moment.
When it is not worth replacing
A spreadsheet used by one person for analysis, modelling or a one-off calculation should stay a spreadsheet. Rebuilding that as software makes it slower to change and adds nothing, and anyone who tells you otherwise is selling something.
The test is whether the file has become a shared operational record: several people depend on it, it holds live data rather than a snapshot, and the business would be disrupted if it were lost or silently corrupted. If none of those are true, leave it alone.
There is also a middle ground worth taking seriously. Sometimes the right answer is a proper database with a decent interface for the few screens that matter, not a full application. We would rather propose the smaller thing when it is enough.
What replacing it looks like
The work is one bounded workflow, which is why it fits the thirty-day shape. Your existing data is imported rather than retyped, so the history comes with you. The screens are built around the process as it actually runs, including the exceptions the spreadsheet handles with a highlighted row and a note in the margin.
What you gain is what a spreadsheet structurally cannot offer: several people working at once without collisions, permissions so the wrong person cannot edit the wrong field, validation that refuses impossible data, and a complete record of who changed what and when.
And you keep the exports. Every application we build exports to Excel and CSV, because the answer to "can I still get it into a spreadsheet" is always yes. The goal is to stop the spreadsheet being the system of record, not to take away a tool your team is good at.
Common questions
Our spreadsheet works. Why change it?
If it genuinely works, do not change it. The question is whether it has quietly become a shared operational record: several people depending on it, live data, real disruption if it were corrupted. At that point you are relying on a format with no access control, no audit trail and no protection against an accidental sort, and those are not faults to be fixed but things spreadsheets were never built to do.
Can you import our existing data?
Yes, and it is part of the standard build. We import the live data from your current sheet so you keep your history and nobody retypes anything. Genuinely messy sheets need a cleaning pass first, which we will flag at scoping rather than discovering it in week three. Very large archives of historical files are quotable separately.
Will we lose the flexibility of a spreadsheet?
You lose some, deliberately, and that is most of the value. Not being able to type text into a quantity field or delete a row without a trace is the point. Where flexibility genuinely matters we build it in as a designed feature, such as custom fields or configurable statuses. And everything exports to Excel, so ad hoc analysis stays exactly as easy as it is now.
Could we use Airtable, Notion or a low-code tool instead?
Frequently yes, and you should look at them first. They are considerably cheaper than a custom build and they solve a real part of this problem. Their limits appear when you need specific business rules, real permission structures, integration with systems you already run, or when the per-seat pricing scales badly with your headcount. We would rather you tried one than paid us to rebuild something a product already does.
How long does it take and what does it cost?
One workflow is about 30 days. Discovery is £500 to £1,500 and is credited against the build; the build itself is £8,000 to £25,000 fixed against a written scope. Where you sit in that band depends on the number of screens, roles and integrations, which is exactly what the discovery session establishes.
Related
The capability pages behind this work, and the other offers in this set.
Which spreadsheet would you kill first?
Describe the workflow and what it runs on today. If it is not a fit for a fixed-scope build, we will tell you that rather than sell you one.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.