When the business is running on a spreadsheet
There’s a file somewhere that the whole operation depends on. Three people have different copies of it. Someone rebuilds the same report every Monday. Nothing is wrong exactly — it’s just that the way you work stopped fitting the tools you work with. That’s the project this page is about.
What this usually looks like
The spreadsheet nobody can replace
Years of formulas, one person who understands it, and a growing fear of the day it breaks or they leave.
Work tracked in email
Status lives in a thread. Nobody can answer “where is this?” without reading backwards through fifty messages.
Paper or PDF forms
Filled in on site, typed into a system later, by someone whose job is now re-typing. Two chances to introduce an error.
A legacy database
An old Access or desktop application that still works, on one machine, that nobody dares update and no supplier supports.
Systems that don’t talk
Accounting, stock and the website each hold part of the truth, and a person is the integration between them.
The Monday report
Hours of copy-paste to produce numbers that are stale by the time anyone reads them.
Sometimes the answer is don’t build anything
We’d rather lose the project than sell you software you don’t need, because custom software you didn’t need is the most expensive thing on this site.
We’ll tell you to stop when:
- Off-the-shelf fits. If an existing product does 90% of it for a monthly fee, buy it. We’ll name the category and let you go and look.
- The spreadsheet is actually fine. Some processes genuinely suit a spreadsheet. Sometimes the real fix is one shared copy instead of four, with proper access control.
- The process is about to change. Building software around a workflow you’re mid-way through redesigning means building it twice.
- Nobody has agreed how it should work. Software makes a process concrete. If two departments disagree, code won’t settle it — it’ll just hide the disagreement until launch.
Where custom does win is when the process is genuinely your own, and bending it to fit a product would cost more than building to fit it.
Nothing switches off on day one
The failure mode for this kind of project is a launch where everyone’s familiar tools disappear at once. We don’t do that.
- One part of the process first — the one causing the most pain
- The spreadsheet stays live alongside it during changeover
- Your existing data imported, including the messy years
- Export to the formats people already use, so nothing feels locked in
- The next part only once the first is genuinely being used
That takes longer than a single launch and it’s the reason these projects stick. Staff adoption is the actual risk here, not the code.
On data: spreadsheets accumulate inconsistency — dates in four formats, names spelled three ways, notes in a column meant for numbers. Cleaning that is real work and we scope it rather than discovering it halfway through.
How we scope it
Watch the current process, don’t just hear about it
Send us the actual spreadsheet and the actual form. How people really work is usually different from the official description, and the difference is where the requirements hide.
Agree what success looks like in numbers
Hours saved, errors avoided, a report produced in minutes instead of a morning. Something you can check afterwards rather than a feeling.
Build versus buy, written down
Including the option of buying something, honestly compared. If buying wins we say so here, before anyone has spent anything.
Smallest useful first version
Something real in people’s hands early, rather than a complete system nine months later built on assumptions nobody tested.
Roll out a piece at a time, with training
Written for the people doing the work, not for whoever signed the invoice.
Common questions
How is this different from your software development page?
That page is what we build and what we build it in — web applications, APIs, dashboards, integrations. This page is one specific starting point: an existing manual process that needs replacing. Same team, same stacks, different first conversation.
What will it cost?
Not answerable before scoping, and anyone who answers it immediately is guessing. What we can do quickly is tell you the rough shape — a few weeks or several months — from seeing the spreadsheet and talking through the process once.
Will it work on phones and tablets?
Where that matters, yes. For anything filled in away from a desk, a web application usually fits; for field work with poor connectivity or hardware attached, a mobile app or a Windows application may be the better answer. We’ll say which.
Can it connect to our accounting or stock system?
Usually, if it has an API or a usable export. Integration is often the highest-value part of these projects, because it removes the person who was the integration. We check what’s actually possible before promising it.
What if we want to take it elsewhere later?
You get the source and the documentation. Standard stacks, standard database, no private framework. We’d rather keep you because the work is good than because leaving is painful.
Send us the spreadsheet
Genuinely. The file, and a sentence about what happens around it. That tells us more in five minutes than a requirements document does in a week.