← Notes

27 July 2026 · 6 min read

When a spreadsheet becomes a custom web app

Almost every internal tool we build replaces a spreadsheet. Not because spreadsheets are bad — they are one of the most useful pieces of software ever made — but because they are so useful that teams keep using them well past the point where they fit.

Here is how to tell when you have crossed that line, and what to do about it.

The five signs

1. Someone is the human database. There is one person who knows which tab is current, why row 340 is highlighted yellow, and what happens if you sort column C. When they are on holiday, work stops. That knowledge should live in software, not a person.

2. You keep a copy of a copy. Bookings_v4_FINAL_updated_Jan.xlsx exists. So does Bookings_v4_FINAL_updated_Jan (Dave's version).xlsx. Nobody is entirely sure which is authoritative. Every hour spent reconciling those is pure loss.

3. The same data is typed in twice. It goes in the spreadsheet, then it gets retyped into the invoicing system, or the email, or a second sheet. Double entry is not just slow — it guarantees the two copies will eventually disagree.

4. You cannot answer a simple question quickly. "How many jobs did we do for this client last quarter, and what did they pay?" should take seconds. If it takes a filter, a pivot and a phone call, the structure is fighting you.

5. You are afraid to change it. The formulas work, nobody fully understands them, and touching the sheet feels risky. That fear is a real business cost, and it grows.

One of these is survivable. Three or more means you are paying for a custom web app already — just in wasted hours instead of a build.

What actually replaces it

A custom web app is not "the spreadsheet, but prettier". The substantive differences are:

• One source of truth. No versions, no copies, no reconciliation.
• Rules the software enforces. A date cannot be before the job started. A status cannot skip a step. The system refuses invalid data rather than silently accepting it.
• Roles. The people who need to read something can read it; the people who should not edit it cannot.
• A history. Who changed what, when. This turns disputes into lookups.
• Automation of the forgettable. Reminders, follow-ups and handoffs stop depending on someone remembering on a busy Friday.

The mistake that causes a rebuild

The most expensive error in this kind of project is rushing the data model.

It is tempting to start with screens, because screens are what people can see and react to. But the underlying structure — what a "job" is, whether it belongs to a client or a site, whether a person can exist without a company — is what determines whether the tool can absorb the next two years of change.

Get the screens wrong and you redesign a page. Get the structure wrong and you rebuild the application. We model the data first for exactly this reason, and it is worth insisting on regardless of who builds it for you.

Start smaller than you think

You do not need to replace the whole spreadsheet at once, and you should not try. Pick the single most painful part — usually the bit causing double entry — and replace that first. Ship it, let people use it for a fortnight, then decide what is next based on what actually annoyed them.

A tool that does one thing well and is genuinely used beats a comprehensive system that everyone quietly works around.

When to stay on the spreadsheet

If it is only you, the process changes constantly, and the data fits on one screen — stay where you are. Spreadsheets are excellent at exploration and genuinely unbeatable for one-off analysis.

Move when the process has settled and more than one person depends on it. That is the point where structure starts paying for itself instead of getting in the way.