When a Business Outgrows Its Spreadsheets
Spreadsheets scale further than people expect, then stop suddenly. The signals that a team has passed the point, and what to build first when it has.
Article
Almost every business runs on spreadsheets before it runs on anything else, and that is usually the right call. A spreadsheet costs nothing, needs no brief, and can be reshaped the same afternoon the process changes. Replacing one too early is a common and expensive mistake. What is harder to see is the point where the spreadsheet has started costing more than it saves. It is rarely a dramatic failure. It shows up as friction that everyone has quietly agreed to live with. The signals that matter Someone has become the file. One person understands the structure, and their absence stops the process. This is the clearest signal and the most often ignored, because that person is usually capable enough to keep absorbing the problem. Reporting is a task rather than a query. If answering "how did last month go" takes an afternoon of consolidation, the numbers are being assembled rather than read. Decisions get made on stale figures because fresh ones cost too much to produce. The same fact lives in several places. A customer's details are in the sheet, the inbox and someone's phone. Nobody knows which is current, so everyone checks two of them. Permission is social rather than technical. Access is controlled by asking people not to edit certain columns. That works until it does not, and the failure is silent. What to build first The instinct is to specify the whole system. That produces long projects that arrive late and match the business as it was at the start of the build. Better to find the single record everything else refers to, and build that first. For most businesses it is the customer or the job. Get one authoritative version of that record, with the history attached and the right people able to see it, and a surprising amount of the surrounding friction disappears without being addressed directly. Reporting comes next, because it is what justifies the change to everyone who did not want it. Automation comes last. Automating a process you have not yet made consistent just makes the inconsistency faster. What not to build Do not rebuild the spreadsheet as a web page. If the new system is the old grid with a login, the team has gained a slower spreadsheet and lost the ability to fix it themselves. The point of a system is not to store the same data more formally. It is to make the operations that were manual into operations the software performs: the follow-up that fires without being remembered, the status that is true without being updated, the report that exists without being built.