Internal Tools for Small Business: When to Retire the Spreadsheet
The signals that a spreadsheet has quietly become a business system, what a right-sized internal tool replaces, and how to size the budget before you call anyone.
The question changed this year
Spreadsheets got a serious upgrade recently. Excel now ships an agent that takes a plain-English request, plans an approach, writes formulas, and checks its own work. Google Sheets has its own version. For the first time, the person running a business out of a workbook can ask the workbook to build itself.
That makes the old advice sound stale. If the tool is smarter, why would you ever commission software?
Because the reason spreadsheets fail in operations was never the formulas. It was everything around them: who is allowed to change what, whether last Tuesday's version still exists, whether the number you are reading was entered correctly in the first place. None of that got better this year.
This post is narrower than our piece on buy vs build, which asks whether to commission software at all and whether something off the shelf would do. Here we assume the process already runs, it runs in a spreadsheet, and the question is only this: has that spreadsheet stopped being a spreadsheet?
Seven signals it already happened
None of these are about size. A 40,000 row workbook can be perfectly healthy. A 60 row one can be a liability. Look for these instead:
- Two people need the same row at the same time. This is the cleanest signal there is. The moment concurrency matters, a file is the wrong container.
- There are columns that are really a workflow. Status, assigned to, follow up date, a color code everyone has memorized.
- Correctness depends on somebody remembering. If the numbers are only right because Denise runs the pivot every Friday, the process has a single point of failure with a calendar on it.
- It holds data you would have to disclose losing. Client names, payment details, health information, anything covered by a contract you signed.
- Rows leave it and get re-keyed somewhere else. Into QuickBooks, into the CRM, into an invoice.
- Someone's job description quietly includes maintaining it.
- You have stopped improving it because you are afraid to break it.
Three or more of those and you are not running a spreadsheet. You are running an application that happens to have no permissions, no validation, no audit trail, and no backup strategy beyond the version history of whoever owns the file.
What AI added, and what it did not
It is worth being precise about the new capability rather than hand-waving at it.
When Microsoft shipped Agent Mode in Excel, it published the benchmark rather than a slogan. On the full 912 task SpreadsheetBench suite, Microsoft reported an accuracy rate of 57.2 percent. For context, the researchers who built that benchmark measured expert human performance at 71.33 percent on an annotated subset, using a comparable grading method.
That is genuinely impressive for a general purpose agent, and it is not a number you would accept from a person doing your accounts receivable. Microsoft's engineers put the underlying risk plainly in the same post, noting that many spreadsheet errors are silent: the formula returns a value, the sheet looks fine, and the mistake only surfaces downstream.
Silent errors are the whole problem, and they long predate AI. A 2024 literature review in Frontiers of Computer Science, surveying more than three decades of spreadsheet research, reported that about 94 percent of spreadsheets in use contained faults.
So the honest summary is that AI made spreadsheets faster to build and no better governed. It writes the formula. It does not decide who may edit the price column, it does not stop a rep from typing a delivery date into the invoice date field, and it does not tell you who changed cell F212 last March.
What a right-sized internal tool actually is
The phrase "custom software" makes people picture a year and a budget with a comma in it. That is not what replaces a spreadsheet. In practice the replacement is small and boring, and it has four parts:
- A table with rules at the edge. Required fields, valid options, a date that has to be a date. Bad data gets rejected at entry instead of discovered at month end.
- A form. One screen, the fields that person actually needs, nothing else.
- Permissions. Three roles is usually enough: view, edit, admin.
- One or two automations at the seams. The notification, the handoff, the export that used to be copy and paste.
That is it. No dashboard nobody opens, no mobile app, no five year platform. Our current build for a residential treatment provider is a healthcare analytics dashboard replacing a spreadsheet-based reporting workflow, and the first version deliberately did nothing but read and display. It shipped early precisely because it was small.
There is a Utah-specific version of this that shows up constantly. The Utah State Tax Commission publishes combined sales and use tax rates by location, and those rates change quarterly. A rate table pasted into a spreadsheet column is correct on the day it is pasted and silently wrong some time after. That is not a formula problem an agent can catch. It is a data ownership problem, and it is exactly the kind of thing a small internal tool fixes permanently by holding the rates in one place with a date on them.
Size the budget before you call anyone
You can do this yourself in about twenty minutes, and you should, because it turns a vague want into a defensible number.
Count the hours the spreadsheet consumes in a normal week. Include the re-keying, the reconciling, the Friday pivot, the meeting where two people compare versions. Multiply by a loaded hourly cost for the people doing it. Multiply by 50.
That annual figure is your ceiling for year one. If it comes out near nothing, you have your answer and you can stop reading. If it comes out at a number that makes you wince, you now have a budget conversation grounded in something checkable rather than in how modern the software feels.
Migrate without a shutdown weekend
Do not schedule a day when the spreadsheet dies. Do this instead:
Build the read layer first. A view of the same data, pulled from the sheet, that people can trust and check side by side. Nobody changes how they work. If the view is wrong, you find out cheaply.
Then move entry. New records go into the tool, the old sheet stays available and read-only. This is where the undocumented rules surface, one at a time, in small enough batches to handle without an emergency.
Then retire the file, and only then. The same sequencing logic applies to bigger systems, which we covered in legacy software modernization. One rule holds at every scale: insist on being able to export the entire dataset yourself, on day one, without asking anyone. If you cannot, fix that before you build anything on top of it.
Most of the work at this size turns out to be connective rather than constructive, which is the same discipline behind our workflow automation practice.
When the spreadsheet is the right answer
Sometimes it is, and the honest recommendation is to leave it alone.
Spreadsheets are excellent at thinking and poor at operating. Modeling a scenario, comparing three vendors, sketching next year's budget, exploring a dataset once and throwing it away: keep the spreadsheet. It is the best tool ever built for that work, and the new agent features make it better.
The trigger for replacing one is never that it is old fashioned. It is a specific, nameable cost you can point at: hours, a compliance exposure, an error that already happened, or a decision the current setup is blocking.
Frequently asked questions
Could a no-code database do this instead of custom software? Often yes, and that is worth trying first for a single, self-contained workflow. The tradeoff shows up later: per-seat pricing that grows with the team, limits on logic you cannot work around, and the awkward moment when the tool must talk to your accounting system. Test the escape hatch before you commit. If you cannot export everything and there is no real API, treat it as a rental rather than an asset.
Who owns the data if you build it for us? You should, unambiguously, in writing, including the database and the repository. Ask that question of any developer before scope, not after. The answer tells you most of what you need to know about the relationship.
We have six broken spreadsheets. Where do we start? The one that touches money or clients, and only that one. Finish it, run it for a quarter, then choose the next. Doing all six at once is how these projects stall.
Does the AI in Excel change any of this? It changes who can build a complicated spreadsheet, not whether a spreadsheet is the right place for a shared business process. If anything it raises the stakes, because it is now easy to generate a large workbook that nobody in the building fully understands.
If you can name the cost your current setup is creating, we can tell you plainly whether a small internal tool would remove it or whether you should keep the sheet. Start with our custom software team and we will work through it in an initial consultation.