When a spreadsheet becomes an app

Almost every business I talk to has one. A workbook somebody built four years ago that now runs bookings, or stock, or job costing, with formulas nobody wants to touch and a tab called DO NOT EDIT.

It usually works. That is the part people get wrong about this conversation. The spreadsheet is not stupid, it is the fastest correct answer to the problem at the size the problem was when it was written, and a lot of software gets sold to replace things that were fine.

So the useful question is not whether a spreadsheet is a bad tool. It is when it stops being the right one.

Three sentences that mean it is time

I have heard these almost word for word from different businesses in different trades.

The first is two of us need it open at once. Shared workbooks in the cloud have made this less awful than it was, and it is still the point where you start losing edits, keeping a copy called final v3, or discovering on Thursday that Monday’s version was the one people had been typing into.

The second is they need to see their own row and nothing else. This is the one that has no good spreadsheet answer at all. You can hide columns, protect sheets, split the file into one per customer and then spend your life reconciling them. None of it survives contact with somebody clicking the wrong tab.

The third is the person who understands the formulas is leaving. Anything that can only be maintained by one person is a liability with a notice period attached.

If none of those apply, you probably do not need me. If the second one applies, you almost certainly do.

The permissions problem is the real threshold

I want to be specific about why that second sentence is different from the other two, because it is where most of the work goes.

Access control is not a feature you add. It is a shape you build the thing in, and it is very hard to retrofit. On the client portal I built for an IT firm, the decision that mattered was made before there was anything to look at: every client company gets its own database file rather than a tenant_id column on shared tables. It costs more at the seams, in code I have to write deliberately, and it means a query that forgets its filter cannot cross a boundary that does not exist.

Getting it wrong is quiet. On the same system I found one permission flag guarding two unrelated powers. It guarded seeing every client, and it guarded creating logins. Nobody would have noticed until somebody had both and should have had one. That is an authorisation bug in code, in a system designed by somebody paying attention. A spreadsheet gives you no such surface to be careful on.

What it costs, and what you actually get

Fixed price per project, quoted after a free call. Not a day rate.

That is a deliberate choice and I will defend it. A published day rate becomes the ceiling in every negotiation afterwards, and it prices the wrong thing anyway: you do not want to buy my hours, you want to buy a working application. If the estimate is wrong, that is my problem, which is the correct place for it to sit.

Rough shapes, from what I have actually built. A small internal tool is two to four weeks. Something with multiple user types and a client-facing side is more like two to three months. Anything large gets split into stages you sign off one at a time, so you are never more than a few weeks from something that runs.

What lands at the end: a working application deployed to a server you own, the database and the backups set up and documented, and the source code and credentials handed over. There is no version of this where I keep the keys. I still run the server the portal sits on, but that is a separate arrangement you can end.

When I tell people not to

Three cases come up often enough to name.

If off-the-shelf software does the job, buy it. Paying me four figures to rebuild something that exists for £30 a month is a bad trade and I will say so on the call. The reason to build is that your process is genuinely yours, not that the available products have the wrong colour scheme.

If the spreadsheet works and nobody else needs access, leave it. A single-user workbook doing arithmetic is a perfectly good piece of software.

And if nobody internally can say what the process actually is, a build will fail. Software makes a process explicit, which is uncomfortable when three people are quietly doing it three different ways. That is worth finding out in a scoping call rather than in week six.

Taking over something half-built

This comes up more than you would expect, usually a half-finished project from a developer who stopped replying. More and more it is a prototype somebody built with an AI tool, which is a perfectly good starting point, and here is what I check in one before real data goes in.

I will read it first and tell you honestly whether it is worth continuing. Sometimes it is fine and just needs deploying properly. Sometimes the useful answer is to keep the database and rewrite the parts that matter. I have never yet found one where the right answer was to throw away everything, and I have found several where the previous developer’s real mistake was one early decision that got expensive later. The portal’s bootstrap endpoint once returned 258MB of JSON to its longest-standing tenants, because employee photos had been stored as base64 on the user records. Correct, isolated, and completely wrong.

What to do with this

If you are somewhere near that second sentence, where people need to see their own data and nobody else’s, the spreadsheet has already stopped being the right tool. Every month you wait adds rows to migrate.

Bring the actual file to the call. Not a description of it, the file. Ten minutes looking at real columns tells me more than an hour of explaining, and it is the fastest way to find out whether this is a two-week job, a two-month job, or something you should not pay anyone to do.

The full offer, including what is in and out of scope, is on the software builds page.