Spreadsheets are not the enemy. They are fast, flexible and let a capable person solve a problem before a product exists. The problem starts when the sheet stops being an aid and becomes invisible infrastructure: it contains rules, states, decisions and knowledge only a few people understand.
Moving to a platform is not justified by appearance or by the number of files. It is justified when the current way of working creates risk, prevents learning or makes every increase in volume demand more manual coordination.
The signals that matter
The first signal is constant reconstruction. If answering what happened requires crossing emails, tabs, messages and file versions, the operation no longer has a defensible source. The second is personal dependency: someone knows which column must not be touched, which exception was approved or which value must be copied before closing.
States matter too. When pending, blocked or resolved mean something different to every team, the file format is not the problem. A shared operating model is missing.
- Duplicates or contradictory versions are common.
- Assignments and approvals live in conversations.
- Permissions depend on sharing the correct file.
- There is no reliable change history.
- Reporting consumes nearly as much time as execution.
What must be defined before building
A platform cannot repair a process nobody has decided. Before designing screens, entities, responsibilities, states and exceptions must be agreed. What is an asset, request or work order? Who may change its state? Which information is mandatory? What happens when an integration does not respond?
That work reduces scope. Many columns exist through habit, and many proposed automations only move disorder into another system. The goal is to preserve useful decisions and remove steps that do not create control.
A transition that reduces risk
The change should not be a blind jump. Start with a bounded workflow, import a representative data sample and run it for a short period with explicit criteria. Compare time, errors, traceability and support load. If the new system does not improve those signals, expanding scope is not justified yet.
Migration also needs a way back: source backup, reproducible mapping, rejected-row log and a clear cutover date. Imported does not mean validated.
What value should remain
The result is not a polished spreadsheet. It is an operation with legible states, visible responsibilities, coherent permissions, history and measurable data. On that foundation, notifications, integrations and AI can become useful.
Keeping spreadsheets and disciplining the process may be the right decision. Buying an existing product may be right too. Custom development makes sense when the workflow differentiates the business, integrations are specific or forcing the operation into a rigid product costs more than governing an owned platform.
Frequently asked questions
How many spreadsheets justify building software?
No number does by itself. Risk, coordination frequency, traceability needs and the cost of errors are what matter.
Must everything be migrated on day one?
No. A bounded first workflow validates the model and real usage before modules or full history are expanded.
When is buying better than building?
When the process is standard, the product covers the required integrations and adapting the operation does not destroy meaningful control or advantage.
