Every operations-heavy business has them. The pricing calculator that grew tabs for fifteen years. The order intake sheet with conditional formatting nobody dares touch. The capacity planning workbook that lives or dies by the analyst who built it. Officially, they're spreadsheets. Functionally, they're software.
It has every hallmark of an application.
These workbooks encode business rules. They have inputs, computations, and outputs. They have user interfaces — even if the interface is a colored cell and a tooltip. They have failure modes. They have a maintainer. They get version-controlled in the form of _FINAL_v3_DO_NOT_EDIT.xlsx filenames.
What they don't have is any of the things that make real software trustworthy. No audit trail of who changed what. No data validation at the edges. No tests. No staging environment. One broken formula in row 4,892 can quietly produce wrong numbers for a month before anyone notices.
For most of the history of software, that was an acceptable trade. Turning a spreadsheet into a real application meant a multi-month engagement, a six-figure quote, and a fight about scope. The spreadsheet was bad, but the alternative was worse. So the spreadsheet stayed.
The math flipped.
We can now take a workbook with a few hundred formulas and a clear use pattern, and stand up a proper web application in a week or two — original logic preserved, data properly validated, change history captured, multiple users working at once without stepping on each other. The interface can look like the spreadsheet they're used to. The engine underneath is real software.
The way to spot a candidate is mechanical. Look for any spreadsheet where: more than one person touches it; the logic has accumulated for more than a year; an outage or a wrong number would matter to the business; and the person who originally built it has either moved on or no longer wants to be on call for it. Most operations teams can name three within ten seconds.
The phrase we hear most often is "we keep meaning to replace that with a real tool, but it never quite makes the priority list." That's the pattern. The cost of replacement used to be prohibitive, so it slid down the list every quarter. The economics flipped. The habit of deferring hasn't.
Spreadsheets are fine. Production systems should be more.
None of this is anti-spreadsheet. Spreadsheets are a phenomenal way to think out loud, prototype an idea, work through a problem. They earn their place. They make a poor production system, and most of us know that already.
The good news is the upgrade is no longer expensive enough to defer. The next time you find yourself saying "we should really replace that spreadsheet," try asking what it would actually cost now. The answer has changed.