When should a spreadsheet become an app?

Almost every trade business I have worked with runs on a spreadsheet that somebody built in an afternoon and never meant to keep. A job tracker. A snagging list. A price book. It was quick, it was free, and it did the job.

Then the business grew around it, and now four people need it at once, two of them are on a phone in a stairwell, and nobody is quite sure which copy is the real one. That is usually the moment somebody asks whether it should be proper software. Sometimes the answer is yes. Often it is no, and paying for a build at that point is the expensive mistake.

When is a spreadsheet still the right answer?

Keep the spreadsheet if it is doing what spreadsheets are genuinely good at. One person owns it and edits it. The data is small enough to see. The structure changes often, because you are still working out how you want to run the process. Nothing downstream depends on it being correct at a particular moment.

That is not a stopgap, that is the right tool. A spreadsheet is the fastest prototype you will ever get, and the fact that you can restructure it on a Sunday evening is the whole point. If you are still changing the columns every few weeks, the process has not settled yet, and building software around an unsettled process just freezes it in the wrong shape.

What are the signs it has outgrown itself?

The useful signals are not about size. They are about pain that repeats.

More than one person needs it at the same time. The moment there is a version on a laptop and another in WhatsApp, you have two sets of numbers and no way to know which is right.

Someone is typing the same thing twice. Job details from the sheet into the invoice. Site notes from a photo into the tracker. Double entry is the clearest sign in the list, because it is pure cost with nothing to show for it.

It is used away from a desk. Spreadsheets on a phone are miserable, and site staff will avoid them, which means the data arrives late or not at all.

A mistake in it costs real money. A wrong figure that nobody catches until an invoice goes out is a different risk to a typo in a shopping list. Software can validate. A cell cannot.

Only one person understands it. If the sheet has grown formulas that only its author can explain, the business now depends on a person remembering something, and that is a liability whether or not anyone says so out loud.

You need a record of who did what and when. Spreadsheets are terrible at proving anything, because anyone can edit any cell and nothing remembers it happened. If your paperwork has to stand up to a main contractor or an inspector, that matters. It is the same argument behind why a client portal earns its place and behind checking ventilation work in stages rather than at the end.

Two or three of those together, repeating every week, and the spreadsheet has stopped being a tool and started being an overhead.

What does "one tool, one problem" mean in practice?

Here is where most first builds go wrong. Somebody decides the spreadsheet has had its day, and the brief becomes a full system: jobs, quotes, invoices, staff, stock, reporting, a client login, an app for the vans. It takes months, it costs a lot, and half of it is never used, because it was designed around what somebody imagined the process was rather than what it actually is.

The version that works is smaller. Take the single worst repeating pain, the one you can put a number on, and build only that. One screen that does one job properly, used every day by the people who felt the pain. Everything else stays in the spreadsheet for now.

That gives you three things a big build does not. It is live in weeks. It is cheap enough that being wrong is survivable. And once people use it daily, you find out what the second tool should be, which is almost never what you would have guessed at the start.

If it works, you add the next piece against the same data. That is how custom software and internal tools should grow: one proven problem at a time, not one enormous launch.

Does it need to be an app at all?

Worth asking before you spend anything, because two cheaper answers often cover it.

An off-the-shelf product may already do this. If your problem is standard job management or invoicing, buy the thing that exists. Custom is for the part of your process that is genuinely yours and does not fit anybody's template.

Or the problem may be handover rather than storage. If information has to be retyped between two systems you already pay for, that is an integration, not a new app. We cover that under AI and workflow automation, and it is usually a fraction of the cost of a build.

What does it cost, and how do you keep that sensible?

Be honest about the maths before you start. Custom software is scoped and quoted fixed-price after a discovery call, and larger platforms start from £12,000. A single-screen tool that replaces one painful process is a much smaller job than that, which is exactly why it is the right first step.

Set the test in advance. Name the process, count the hours it eats or the errors it causes in a month, and decide what the tool has to change for it to be worth keeping. If it cannot pay that back, do not build it.

And whatever you build, own it. The code and the accounts should be handed to you on delivery, the same as with a website. A tool your business depends on that lives in somebody else's account is not an asset.

Where to start

If your website is the thing quietly costing you work, start there instead. Run the free site audit for an instant check on the technical basics and where enquiries are leaking away.

If it is the admin that is breaking, bring the actual spreadsheet to the conversation. See how we scope custom software and we will tell you honestly whether it needs building, buying, or just connecting to what you already have.