Our take: the best custom software replaces a spreadsheet
Why the most valuable software we build starts from a workbook somebody built out of necessity, and how to recognise yours.
The short answer
Somewhere in your business there is a spreadsheet that runs a process: a workbook with tabs, colour codes, formulas nobody dares touch and one person who understands it. We think that spreadsheet is the best specification for custom software a business can have. It proves the process mattered enough for someone to build a tool for it, and that nothing on the market fitted, which is precisely the condition custom software exists for. Its columns are the data model. Its tabs are the screens. Its formulas are the business rules. Its owner is the domain expert. Software replaces it not because the spreadsheet was wrong, but because a spreadsheet cannot give many people safe, simultaneous, audited, integrated access to a process that has outgrown one file.
What the spreadsheet already knows
| In the workbook | In the software |
|---|---|
| Columns | The data model: entities, fields, types |
| Tabs | Screens and views |
| Formulas and conditional formatting | Business rules and status logic |
| The lookup sheet | Reference data |
| The colour codes | Statuses and priorities |
| The person who maintains it | The product owner and first tester |
| The email it is sent in | The permissions and sharing model |
| The version history in file names | The audit trail |
What software adds
- Many users at once, without overwriting each other or emailing versions.
- Permissions: who may see, edit and approve what, instead of a file everyone can change.
- Validation: a date is a date, a status is one of the allowed ones, a required field is required.
- An audit trail: who changed what and when, instead of a guess.
- Integrations: data from and to the systems around it, instead of copying.
- Backups and continuity: it does not live on one laptop or depend on one person.
- A future: it can grow with the process instead of collapsing under it.
How we do it
We ask each team which workbook they could not do without and who maintains it. We sit with that person for a morning and read the spreadsheet with them: every tab, every formula, every workaround. We write the stories in their words. We build the smallest tool that does the same job on proper foundations: login, permissions, audit log, validation, backups, a pipeline. We run it alongside the spreadsheet for two weeks with the owner checking. Then the spreadsheet is retired, and the owner, now the product owner, tells us what is next.
What this means for you
Find the spreadsheet that runs a process and the person who runs it. Treat the workbook as the specification and the person as the expert. Build the smallest tool that does the same job on proper foundations, test it against the spreadsheet, retire the file, and let the team decide what comes next. It is the fastest, safest and most reliably valuable custom software a business can commission, and it is already half designed.
Frequently asked questions
Is a spreadsheet not good enough?
It is good enough until it is not: two people editing at once, a formula broken by a sort, a version emailed around, the one person who understands it on holiday, customer data with no access control, no history of who changed what. The spreadsheet worked because someone cared; software makes that care survive scale, staff changes and scrutiny.
How do we find the spreadsheet worth replacing?
Ask each team which workbook they could not do without and who maintains it. The one with the most tabs, the most users and the most anxiety around it is the candidate. Then sit with its owner: they are the expert, and the spreadsheet is the specification they have already written.
Will replacing it take long?
Less than a project that starts from nothing, because the hard thinking is done: the data model, the rules and the flow are in the workbook. A few weeks for a small tool on proper foundations, with the owner testing it against the spreadsheet in parallel. The risk is not the build; it is over-building beyond what the spreadsheet did.