A spreadsheet has stopped being good enough when the limit is concurrency and trust, not size. The tells are concrete: two people need to edit the same file at once, a wrong formula reaches a client deliverable, and a reconciliation takes longer than the work it checks. When those appear, the fix is shared structure, not another tab.
A spreadsheet is the right tool for far longer than most software vendors will admit. It is fast, it is understood by everyone in the building, and it costs nothing to start. Almost every real system in a small business begins as one, and that is not a mistake to apologize for. So the honest question is not whether you should be embarrassed to still run on Excel or Google Sheets. It is narrower: what is the specific point where the spreadsheet stops helping the business and starts quietly putting it at risk, and how do you know you have reached it.
What actually signals that a spreadsheet has been outgrown?
Not the number of rows. A one-tab sheet with 80,000 rows can be perfectly healthy, and a tidy little tracker can be a disaster. The real limits are about concurrency and audit trail, and they show up as a short list of failure modes you can name without a consultant.
Two people need the same file at the same time. The moment more than one person has to edit a spreadsheet at once, you are managing versions instead of data. Someone works off a copy, someone overwrites a change, and the same fact ends up entered in two places that slowly disagree. A spreadsheet assumes one editor at a time. A business past a few people does not.
Nobody fully trusts the numbers. When every report has to be manually rechecked before it goes out, the spreadsheet has stopped being an answer and become a draft. This failure is expensive enough that developers keep building tools to catch it. Tally, one such tool, recalculates every figure in a report against its underlying source rows and marks each one verified or not, on the stated premise that "reviewed isn't reconciled." An entire small category of software exists because spreadsheets produce confident, wrong totals that survive a review. The sharpest version of this is the day a formula that was copied wrong lands in a deliverable a client actually reads.
One file is understood by exactly one person. The most dangerous spreadsheet in any company is the one only a single employee can open without breaking something. It is not a system. It is a dependency with a calendar, and it walks out the door when that person does.
Reconciliation takes longer than the work it checks. When someone spends more time making two systems agree than doing the underlying task, the tool has become the ceiling. A fulfillment operator writing on X framed the same idea in volume: doing it by hand is fine under roughly 100 orders a month, and the tipping point is around 400 to 500, "or sooner if bundles and subscriptions outgrew your spreadsheet." The number is specific to that business. The shape, manual effort growing in step with the thing you are trying to grow, is universal.
Those four are a usable threshold test. If none of them are true, the spreadsheet is fine and a migration is a solution hunting for a problem. If two or more are true, the business has outgrown it, no matter how neat the file looks.
Does outgrowing a spreadsheet mean you need custom software?
Usually not, and this is where the decision most often goes wrong. Outgrowing a spreadsheet means outgrowing an unmanaged, single-file way of holding data. The cheapest fix that removes the failure modes above is often a shared database or a maintained off-the-shelf tool, not a custom build.
The difference that matters is not features, it is guarantees. A spreadsheet lets anyone change any cell, keeps no reliable record of who changed what, and assumes one editor at a time. A database stores a given fact once, validates what is allowed into each field, and lets several people work at the same time without overwriting each other. One source of truth, validation, and safe concurrent access are exactly the three things that fail in a growing spreadsheet, which is why the fix is structural rather than a matter of tidying the sheet.
Building your own software is a real option with a real bill, and it is easier to reach for once a working tool can be generated in an afternoon. The catch is ownership. A tool that takes a weekend to build can take years to maintain, and teams that stand up a custom internal system on impulse often abandon it later, when the upkeep outruns the value, and move back to a product someone else keeps running. Build when the workflow is part of your advantage, when the way you route jobs or price quotes or track inventory is something a competitor cannot buy off a shelf. Buy or adopt a database when the need is generic. The tradeoff, and the true cost of the build side, is laid out in how much custom software costs for a small business and in the wider question of outgrowing your SaaS stack.
How do you move without breaking the business?
The pattern that stalls is the big-bang rebuild that tries to replace the whole spreadsheet at once. The safer path is narrow and unglamorous.
Start by writing down what the spreadsheet actually does, field by field, before choosing any tool. The demand for this is not hypothetical. On r/webdev, a business owner opened a thread titled "Practical database advice needed for business" and drew roughly two dozen replies inside a day, which is what the first hour of one of these projects looks like every time.
Then move the single worst failure first. Migrate the one workflow with concurrent editors, or the one file only one person understands, and leave everything else in the spreadsheet until the new thing has earned trust. If the move does point to a purpose-built system, the hard part is getting the data model right, not writing code, which is what custom platform development is actually for.
A spreadsheet was never the wrong choice. It was the right choice the business grew past. The sign that it is time to move is not that the file got big. It is that two people now need it at once, and nobody is quite sure the numbers are right.