Most internal business software starts as a spreadsheet that worked. Someone built something useful, it spread, people depended on it, and nobody decided it had become a system — it just did.
The question is not whether that was wrong. It usually was not. The question is whether it still is.
Signs it has crossed over
- Macros or scripts that do real work, not just formatting
- Lookups across many tabs, where changing one breaks others
- Instructions on how to use it — a tab explaining the tabs
- Deliberate sequence: fill this before that, or the numbers are wrong
- Copies circulating, with no certainty which is current
- One person who understands it, and a shared reluctance to change anything while they are away
Three or more of these and it is an application maintained by someone whose job is not maintaining applications.
The real risks
Key person dependency. The most serious. Business logic exists only in formulas and in one person's memory. If they leave, so does it.
Silent errors. A dragged formula, a range that did not extend, a paste that overwrote a calculation. Spreadsheets fail quietly — they produce a plausible wrong number rather than an error.
No audit trail. Nobody knows who changed what.
Concurrency. Two people, two versions, a manual merge.
Scale. Performance degrades, and the file becomes slow enough that people avoid using it properly.
Options, in increasing order of cost
- Leave it alone. If it works, one person uses it, and errors would be caught elsewhere, this is a legitimate answer.
- Harden it. Protect formula cells, add validation, move it somewhere with version history and access control, and document the logic. Cheap, and removes a surprising amount of the risk.
- Move to a no-code or low-code tool. Structured data, multiple users, forms. Suits straightforward workflows. The ceiling arrives sooner than expected for anything with complex logic.
- Adopt an off-the-shelf product. If what you are doing is a solved problem — inventory, CRM, accounting — someone has built it better than you will.
- Build custom software. Right when the process is genuinely specific to how you operate and is a real competitive advantage.
Most organisations jump from one to five and skip the middle. Options two and four solve more cases more cheaply than either end.
When custom is genuinely the answer
- The process is unusual enough that products do not fit without distorting how you work
- Several people need concurrent access with different permissions
- It must integrate with systems you already run
- Errors here are expensive — financial, regulatory or safety
- It will be used for years, so the build amortises
If instead the spreadsheet is unusual mainly because nobody has examined it for years, look at products first. Many spreadsheets are bespoke by accident, not by requirement.
The spreadsheet is your specification
If you do build, the existing file is the most valuable input you have. It encodes years of edge cases and exceptions that nobody would remember to mention in a requirements meeting.
Walk a developer through it, including every oddity, and specifically ask the person who maintains it why each unusual part exists. Those answers are the requirements.
About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.
Gallery
