Turning your spreadsheet into an app: when it is time and what changes

It is time to turn a spreadsheet into an app when the spreadsheet has become the system your business runs on: several people edit it, it feeds the documents you send to clients, and a mistake in it costs money or a compliance failure. What changes is not the logic. The spreadsheet already describes that, often in more detail than anyone realises. What changes is where the information lives and what protects it. An app, meaning here a private web application with a database behind it, keeps one record of each job, checks entries as they are made, controls who can change what, and produces your documents from the data instead of by retyping. Your spreadsheet is the specification. You have already written it.

How do you know the spreadsheet is no longer enough?

The signs are familiar to anyone who has lived with one. More than one person needs to edit it at the same time. There is a file called final, and another called final v7. A formula exists that nobody dares touch because the person who wrote it has left. Cell colours mean something: yellow is waiting, green is invoiced, and everyone just knows. Values are copied out of it into Word, into certificates, into invoices, by hand. Nobody can say who changed a figure or when. It travels by email, so two versions exist by lunchtime.

The clearest test is this: if the spreadsheet were unavailable for a day, would work stop? If the answer is yes, it is not a spreadsheet any more. It is your business system, running on a tool built for calculations. In 2020 Public Health England lost track of nearly 16,000 positive test results because the spreadsheet format used to collect them could not hold more rows, as the BBC reported. The lesson is not that spreadsheets are bad. It is that they have limits nobody sees until the day they matter.

What does an app actually mean here?

It does not mean something in an app store. When an owner asks whether the business needs a mobile app, the honest answer is usually no. What most firms need is a private web application: software that runs in a browser, on a phone in the field and a laptop in the office, with a database behind it. A database is simply a store where each piece of information is kept once, in its own labelled place, so it can be found, checked and combined without being retyped.

A web application does not need to be installed, does not go through an app store, and is updated once for everyone. It can work without a signal and catch up when the connection returns, which is how we built FireRecord to behave on site. A native phone app makes sense when you need something only the phone can do, such as particular hardware. For a job list, a checklist, a certificate or a report, the browser is enough, and it costs a fraction of building for two app stores.

What carries over from the spreadsheet?

Almost everything, and that is the point. The columns become fields. The tabs become record types: jobs, properties, clients, engineers. The formulas become rules that the app applies automatically. The colours and comments become proper statuses and notes that can be filtered and reported on. The lookups between tabs become links between records, so a job knows its property and its client without anyone typing the address again.

Most valuable of all is the knowledge that has accumulated in the sheet over the years: the exceptions, the special cases, the column added in 2019 because a particular client needs a particular reference. A spreadsheet that has run a business for a decade is the most complete description of that business anyone will ever write. Nobody sat down to write a specification, but there it is. Turning it into an app starts with reading it properly, with the people who use it, and asking what each column is really for.

What gets better?

Five things, and each one removes a category of error or work.

• One record per thing. A job, a property, a client exists once. Every document and every list draws from that record, so a corrected address is corrected everywhere.
• Checking at entry. A date has to be a date. A certificate number has to match the pattern. A required field cannot be left blank. Mistakes are caught when they are typed, not when a client rings.
• Permissions. An engineer sees their jobs. The office sees everything. Only certain people can approve, delete or change a price.
• Documents from data. Quotes, certificates, reports and invoices are generated from the record, in your own templates, instead of being retyped from the sheet.
• History. Every change is recorded with who made it and when. That is the question an auditor, an inspector or an insurer asks first, and a spreadsheet cannot answer it.

Several people can work at once without overwriting each other, from any device, and the file that used to travel by email no longer exists.

What do you lose, and how do you keep some of it?

You lose some freedom, and it is worth being honest about it. In a spreadsheet you can add a column on a whim, try a quick calculation, or reorganise everything on a Friday afternoon. An app is more deliberate. Adding a new type of information means changing the app, and that should be a decision rather than an accident.

There are three ways to keep the flexibility that matters. First, insist on export: your data should come out as a spreadsheet at any time, because it is yours. Second, design the app so the office can manage its own lists, such as job types, statuses and standard wording, without calling a developer. Third, keep using spreadsheets for what they are good at, which is analysis. Pull the data out, chart it, and explore it. Just do not make the spreadsheet the record again. And if a process is still changing every week, wait. Build the app when the process has settled enough to be worth protecting.

Is our process too particular for an app?

No, and the spreadsheet is the proof. Every firm believes its way of working is unusual, and in the details it usually is. Those details are exactly why off-the-shelf products never quite fit: the extra reference, the two-stage approval, the certificate that needs a different layout for one type of client. An app built around your spreadsheet keeps the details, because they are already written down in it.

Twenty years of doing something by hand is not a reason it cannot be automated. It is an asset. The exceptions are known, the edge cases have all happened at least once, and the people who handle them can explain them. The processes that resist automation are the ones nobody can describe. Yours has a description, with formulas.

To start, take the spreadsheet, remove anything confidential, and write down three things: what goes into it, what comes out of it, and who touches it between the two. That is enough for a developer to tell you whether it should become an app and what the first version should contain.

Frequently asked questions

Do we lose our data when we move away from the spreadsheet?

No. The existing rows are imported once, cleaned along the way, and the app becomes the record from that point. You should be able to export everything back to a spreadsheet at any time.

Do we need a phone app as well as the web app?

Usually not. A web application works on a phone, a tablet and a laptop, and it can be built to work without a signal. A separate phone app only earns its cost when you need something the browser cannot do.

Can we keep using the spreadsheet while the app is being built?

Yes, and you should. The usual approach is to run both for a short period, compare the results, and switch when the team trusts the app. Nothing is lost in the meantime.

If you have a spreadsheet the business could not run without, describe what goes in, what comes out and who touches it on our contact page. We will tell you whether it should become an app and what that would involve.