Spreadsheet to app: signs your process has outgrown Excel

Somewhere in most businesses there's a spreadsheet that runs something important. Job bookings, stock, commissions, a quoting tool. It started as one person's file and slowly became the place the business keeps the truth. Now three people edit it, nobody fully trusts the totals, and every month someone spends a morning fixing it.

That doesn't automatically mean you need an app. Spreadsheets are fast, flexible and already paid for. But there are specific signs that the process has outgrown the tool, and it's worth knowing them before the file fails at a bad moment.

Why spreadsheets end up running things#

A spreadsheet is the quickest way to turn an idea into a working process. There's no project, no budget approval and no developer. The person who understands the work builds the tool, and they can change it the same afternoon. That's a real advantage, and it's why the question here is "has it outgrown Excel?" rather than "should it ever have been in Excel?".

The trouble is that a spreadsheet mixes three things a software system normally keeps apart: the data, the logic that works on it, and the screen people use to edit it. In a small file that's convenient. In a file that ten people depend on, it means anyone who can type in a cell can also change the data, overwrite a formula or break a lookup, and nothing stops them.

Sign 1: it has quietly become the system of record#

Ask a simple question. If this file vanished tomorrow, could you rebuild the information from somewhere else? If the answer is no, the spreadsheet is your system of record, whether anyone decided that or not.

That raises the stakes on everything else in this list. A personal analysis file can be wrong for a day and nobody is hurt. A file that holds every open customer order, or the only record of who's been paid, needs backups you've actually tested, controlled access and some way to catch bad edits. Spreadsheets can have some of that bolted on, but none of it is there by default.

Sign 2: errors are cheap to make and hard to see#

Spreadsheet errors aren't a sign of careless staff. They're normal. When researchers at Dartmouth audited 50 operational spreadsheets, the kind people use for day-to-day work, they found errors in 0.9% to 1.8% of all formula cells, depending on how strictly an error was defined. Only three of the 50 workbooks had no issues at all under the broader definition, and 43 contained at least one formula that produced a wrong result. The same authors are careful to point out that a formula error doesn't always change the final answer much, so treat those numbers as a measure of how often mistakes slip in, not how often decisions go wrong.

Then there are errors Excel introduces for you. A 2016 study in Genome Biology screened supplementary Excel files from 18 genomics journals and found gene name errors in about one-fifth of the papers that included gene lists (704 of 3,597). Default settings had turned the gene SEPT2 into "2-Sep" and MARCH1 into "1-Mar", and an identifier like 2310009E13 into the number 2.31E+13. Swap gene names for part numbers, postcodes with leading zeros or long account references and you have the same problem in an ordinary business.

Recent versions of Excel do let you switch some of this off. Microsoft's data import and analysis options include settings to stop Excel removing leading zeros, truncating long numbers to 15 digits, treating digits around the letter "E" as scientific notation, and converting letter-and-number strings to dates. That page lists Excel for Microsoft 365, Excel 2024 and Excel 2021, so anyone on an older version won't have the setting.

The sign to watch for is this: you've had at least one error that reached a customer, an invoice or a report, and you only found it by accident. If checking the file depends on someone noticing that a number looks odd, the process has outgrown it.

Sign 3: several people edit it, and they collide#

A spreadsheet works well with one owner. Problems start when several people need to update it during the same day: two people editing the same row, someone sorting one column without the others, a copy saved to a desktop "just for now" that becomes the version everyone uses.

Excel's collaboration features have changed over the years, but the older "Allow changes by more than one user" shared workbook setting has some telling limits. Microsoft's specifications page notes, for example, that a workbook containing Excel tables can't have that setting turned on at all. When the tools for working together fight the tools for keeping data tidy, that's a hint you're asking the file to be a multi-user database.

Watch for the social signs too. People asking "is anyone in the file?" in chat. A rule that only one person may touch a particular tab. Locked cells that someone unlocks every month to fix something. These are workarounds for missing permissions and record locking, which any proper database gives you.

Sign 4: data is retyped or pasted between files#

If the same customer, product or job appears in several spreadsheets and someone copies it across by hand, you have several versions of the truth and a person acting as the integration. Each copy step is a chance to paste into the wrong row, miss a new entry or overwrite a correction.

The same goes for files that get emailed out, filled in and emailed back, then merged. That pattern is fine at five returns a month. At fifty, the merge becomes a job in itself, and one missing or malformed file can leave gaps nobody notices.

Sign 5: you're near limits you didn't know existed#

Excel's ceilings are high for everyday work. A worksheet holds 1,048,576 rows by 16,384 columns and numbers carry 15 digits of precision. You may never hit those. The more common issue is that a file-based process has limits somewhere, and you don't find out where until the volume grows.

The UK's COVID-19 testing data in October 2020 is the well-known example. Public Health England's statement explained that 15,841 positive cases between 25 September and 2 October were left out of the daily figures because some files of results "exceeded the maximum file size" the system could load. A letter to the Commons Science and Technology Committee dated 12 October said that increased testing volumes meant "some Excel files used in the transfer process exceeded their file size threshold and so were not uploaded". The same letter stated the issue was not caused by using an old file format, and that a new system to replace the legacy ones had already been commissioned. The quick fix was to split large files.

The lesson for a small business is about failure mode more than file format. When a spreadsheet step hits a limit, it often drops data quietly instead of stopping with an error. A database or a proper import job can be set up to reject a bad load loudly, which is what you want.

Sign 6: you need to know who changed what#

Sooner or later someone asks why a price, a balance or a delivery date changed. In a spreadsheet the honest answer is often "we're not sure". Version history helps you find an older copy of the file, but it's awkward for answering "who changed this customer's discount, and when?".

If you're dealing with money, customer personal information or anything an auditor or regulator may ask about, a reliable change history stops being a nice-to-have. That's a strong signal to move the data into something that records changes per record, with named users rather than a shared login.

What to try before building an app#

Not every sign means you should commission software. Some fixes are cheap and worth doing first.

• Convert ranges to Excel tables, add data validation lists for fields like status and region, and protect formula columns so people only type into input cells.
• Turn on the automatic data conversion settings above for everyone who edits the file, if your version has them, and store codes and IDs as text.
• Split the file so one sheet holds raw data and the others only read from it. That makes it obvious where edits belong.
• Check whether an off-the-shelf tool already does the job. Our build vs buy framework walks through that decision.

If the signs are still there after that, a small internal app is usually the next step. It doesn't have to be big. A single form, a database table and a couple of reports can replace a surprising amount of spreadsheet. For many internal tools a simple embedded database is enough; our piece on SQLite in production covers when that holds and when it doesn't. Budget for upkeep as well as the build, because an app needs ongoing maintenance in a way a spreadsheet seems not to. At TheAILAB, the first thing we do on these projects is keep the existing spreadsheet running in parallel until the new tool has matched its numbers for a full cycle.

A one-week test you can run now#

Pick the spreadsheet that worries you most and keep a short log for a week. Note every time someone fixes an error, waits for someone else to finish editing, copies data in from another file, or can't answer a question about who changed something. Note roughly how long each one took.

At the end of the week you'll have a concrete list instead of a vague feeling. If it's two or three minor items, tidy the file and move on. If it's a page of interruptions and at least one error that reached a customer or a report, you've got the case for moving that process out of Excel, and a list of the exact problems the replacement has to solve.

Sources

1. Errors in Operational Spreadsheets — Stephen G. Powell, Kenneth R. Baker, Barry Lawson, Journal of Organizational and End User Computing 21(3) (2009) (checked 2026-10-19)
2. Gene name errors are widespread in the scientific literature — Mark Ziemann, Yotam Eren, Assam El-Osta, Genome Biology 17:177 (2016) (checked 2026-10-19)
3. Worksheet and workbook specifications and limits — Microsoft Support (checked 2026-10-19)
4. Data import and analysis options in Excel — Microsoft Support (checked 2026-10-19)
5. PHE statement on delayed reporting of COVID-19 cases — Public Health England, GOV.UK (4 October 2020, updated 5 October 2020) (checked 2026-10-19)
6. Letter from Baroness Harding to the Chair of the Science and Technology Committee — UK Parliament, Science and Technology Committee (12 October 2020) (checked 2026-10-19)