When The Spreadsheet Stops Being Good Enough

There is a file. Everyone at a certain size has this file. It is called something like Master_Inventory_v4 or Jobs_2026_USE_THIS_ONE, it runs to nine tabs with four of them hidden, and somewhere around column R the headers stop meaning anything to anyone who was not in the room the day they were typed. Six people have the link. Two of them actually write in it. Last month somebody sorted a range without catching the whole table and about three hundred rows quietly came unstuck from their part numbers, which nobody noticed until a customer got invoiced for something they did not order. You have been told, probably by someone with a demo calendar, that you have outgrown the spreadsheet. What nobody will tell you is how you were supposed to know.

So here is the answer, up front, because you are busy and this is the part that matters. The spreadsheet does not stop being good enough when it gets big. It stops being good enough the moment two people can both be right about the same number at the same time. Size is not the threshold. Concurrent authority is. And that line gets crossed years before the file ever gets slow, which is exactly why so many shops sit inside a broken system for two years wondering why everything feels wrong when the thing still opens in under a second.

Nobody has ever outgrown a spreadsheet by size

Start by killing the story you have been sold, because it is doing real damage to your buying decisions.

Excel holds 1,048,576 rows by 16,384 columns on a single worksheet. Google Sheets holds 10 million cells or 18,278 columns, and that ceiling applies whether you built the thing in Sheets or imported it from Excel. Sit with those numbers against your actual file. A 90-person distributor with eleven thousand SKUs and four years of movement history is using something like two percent of what Google will give it for free. A field service shop logging every job it has ever run since 2019 is not close. You are not going to hit the wall. Almost nobody does, and the ones who do are running analytics workloads, not operations.

This matters because "you have outgrown it" is the standard opening line of a sales conversation, and it is a sleight of hand. It invites you to picture a capacity problem, which has an obvious shape and an obvious fix: buy something bigger. Then you go shopping for bigger, you get quoted per seat, and eighteen months later you are one of the many operators who regrets the purchase and cannot fully explain why. You cannot explain why because the diagnosis was wrong from the first sentence. You never had a capacity problem.

What you have is an arbitration problem. Your file has to answer the question "what is true right now," and it has stopped being able to.

The trade nobody makes explicitly

The interesting thing is that this was never a secret. It is sitting in Microsoft's own published spec, in the section covering the older shared workbook mode that plenty of shops still run on a network drive. Look down that list of limits and you find this: the maximum number of Excel tables in a workbook with multi-user editing turned on is zero. Not a low number. Zero. A workbook containing so much as one structured table cannot have that setting enabled at all.

Modern co-authoring in the subscription versions has moved past that specific restriction, so do not read it as a live limit on your current setup. Read it as an artifact, a place where the underlying trade-off got written down plainly and then quietly stopped being discussed. Structure and concurrency pull against each other. A spreadsheet's entire genius is that any cell can be anything, which is precisely what makes it impossible to guarantee that two people editing at once will end up agreeing. Every tool that solved concurrency solved it by taking away that freedom. That is the deal. Nobody presents it to you as a deal, so you never get to decide whether you want it.

The vendors know exactly where the line is, and you can read it straight off their pricing. Airtable charges per seat, and the billing FAQ is specific about which seats: you are charged for every user with edit permissions on at least one base. Read-only collaborators are free. Form submissions are free. Share links are free. They will let unlimited people look at your data and they will bill you forty five dollars a month, annually, for each person allowed to change it.

That is not a pricing quirk. That is the company telling you what the product is actually for. You are not buying storage, and you are not buying features. You are buying the right to have more than one writer without losing track of the truth. Which gives you a diagnostic you can run this afternoon, for free: go down your team list and ask, for each person, whether adding them to a per-seat tool would raise the bill. Everyone whose name raises the bill is a person who is currently straining your spreadsheet. If that list has one name on it, stay where you are. If it has six, you crossed the line a while ago.

Four tripwires, and you probably hit them last quarter

The abstract version is easy to nod along to and hard to act on, so here is what crossing the line actually looks like from inside the business. Any one of these means the spreadsheet has stopped being your system of record, whatever the file is still called.

1. Two writers, same rows, same hour. Not two people with access. Two people typing into overlapping territory in the same working day, which is when last-write-wins stops being a technicality and starts being a wrong invoice.
2. A rule that lives in somebody's head. "Do not touch column H, it feeds the pricing tab." That rule is load-bearing and it is not in the file. When the person holding it takes a week off, the rule takes the week off too.
3. Somebody keeps a private copy. The moment a person downloads it, works locally, and pastes back in on Thursday, you have two versions of the truth and a scheduled merge conflict. People do this for good reasons, usually because the shared file is too fragile to work in live, which tells you something on its own.
4. The file has quietly become an app. Data validation, conditional formatting driving actual decisions, a tab labeled something like "entry form," a macro nobody has opened in a year. Congratulations, you built software. You built it in the one environment that offers no version history you can reason about, no permissions below the tab level, and no way to stop a well-meaning person from pasting over a formula.

Read that list honestly and most operators find they crossed the threshold somewhere around the second hire on the ops team, not at some data volume they were waiting to reach.

What graduation actually means, and it is not what you think

Here is where the usual advice goes wrong, and it costs people real money.

The standard move, once you accept that the file is failing, is to go find a replacement for the file. Shop the category, sit the demos, pick the platform, migrate everything, retrain everyone. That is a large, disruptive, expensive project, and it is very often the wrong shape of solution to the problem you actually have.

You do not need to replace the spreadsheet. You need to demote it.

The failure is that the sheet is simultaneously your record of truth and your interface to that truth, and those two jobs have opposite requirements. The record needs one write path, some rules about what a valid row looks like, and a history of who changed what. The interface needs to be fast, familiar, and editable by anyone without training. The spreadsheet is genuinely excellent at the second job. It is structurally incapable of the first.

So split them. Put the data somewhere with one write path, and let the spreadsheet keep being the thing your team looks at. In practice that means the sheet becomes a view, refreshed from the real record, and the handful of operations that actually change things go through a form, a script, or a small internal tool. Nobody has to learn a new platform. The purchasing manager opens the same tab they have opened every morning for three years. The difference is that when they change something, it goes through a door instead of straight into the wall.

This is also the version a non-engineer can now actually ship, which is the part that changed recently enough that most advice has not caught up. Standing up a Postgres instance and a form that writes to it used to be a project you filed a ticket for and waited six weeks on. It is now an afternoon, and the reason is not that databases got easier. It is that describing what you want to an AI and reading what comes back is a skill an ops person can hold, where writing the syntax from memory was not.

The money, honestly

Twelve people who need to change data. On Airtable's Team plan at twenty dollars per user per month billed annually, that is 2,880 dollars a year. On the Business plan at forty five, it is 6,480 dollars a year, and it goes up every time you hire. The per-seat model means your data infrastructure bill is indexed to your headcount, which is a strange thing to agree to when the amount of data did not change.

The other side: Supabase's Pro plan starts at twenty five dollars a month for a dedicated Postgres instance, flat, and dashboard team members are unlimited on every tier including the free one. Three hundred dollars a year against 6,480, and the gap widens with every person you add.

Now the part a vendor comparison would leave out, because it is the entire catch. Those two numbers are not buying the same thing. Airtable hands you an interface, a permission model, views, filters, automations, and a support line, on day one, configured by nobody. Supabase hands you a database. The interface is your problem. The permissions are your problem. The backup restore at eleven at night when something has gone sideways is very much your problem. The 6,180 dollar difference is not savings. It is the price of the work, and whether that trade is good depends entirely on a question that has nothing to do with software.

Where this answer stops working

If nobody in the building can maintain it, buy the seats. This is the honest catch and it disqualifies more shops than any technical consideration. A 6,480 dollar annual bill you can phone somebody about beats a 300 dollar system whose only competent maintainer left in March. Be brutal about this one. "I could figure it out" is not a maintenance plan, and neither is a person who is already at capacity.

If you have one writer, stay. Genuinely. A single-writer spreadsheet is not a problem waiting to happen, it is a good tool being used correctly, and moving off it buys you nothing but ceremony. The tripwires are about concurrency. No concurrency, no tripwire.

Do not graduate your analysis. The spreadsheet is the best modeling and exploration tool ever built for people who are not programmers, and shops that move everything into a rigid system often discover they gave up the ability to just try something. Move the operational record. Keep the scratchpad.

The most common way this goes wrong is rebuilding the mess. People migrate and faithfully recreate all forty seven columns, including the eleven nobody has filled in since 2023 and the three that mean the same thing. Now you own the same confusion with a worse interface and a per-seat bill. The migration is the one moment you get to throw things away. Most of the value is in what you leave behind, and almost nobody takes it.

And you are giving something up on purpose. The spreadsheet's best feature is that anyone can fix anything instantly. One write path means somebody had to anticipate the case in advance, and the first time a person cannot enter a legitimately weird order because your form does not have a box for it, they will feel the loss and they will be right. You are trading flexibility for trust. Make that trade knowingly, because if you make it accidentally you will spend a year hearing about it.

The spreadsheet never really stops being good enough at holding your data. It stops being good enough at settling arguments, and that is a much earlier date than anyone selling you the next thing has any reason to mention.