The spreadsheet is not automatically the problem
Spreadsheets are fast, flexible, familiar, and inexpensive. For a changing process owned by one or two people, that can be exactly right. Replacing a workable spreadsheet with custom software adds cost, training, and maintenance without necessarily improving the business.
The problem begins when the spreadsheet carries responsibilities it was never designed to manage: permissions, concurrent updates, workflow state, integrations, audit history, or reliable service to customers and staff.
Seven signs the workflow needs a decision
- People maintain multiple copies or disagree about which version is current.
- The process depends on formulas, macros, or knowledge held by one person.
- Staff copy the same information between the spreadsheet and other systems.
- Different roles should see or edit different information.
- It is difficult to tell who changed a value, approved a step, or owns the next action.
- The file becomes slow, fragile, or hard to test as rules accumulate.
- A mistake can delay delivery, misstate money, or affect a customer commitment.
The four-option decision matrix
| Option | Best when | Main trade-off |
|---|---|---|
| Keep and improve | Low volume, few users, changing process | Limited control and integration |
| Buy software | Common process with acceptable standard workflows | Subscription cost and adapting to the product |
| Connect tools | Existing systems work but data and actions do not flow | Integration ownership and system limits |
| Build a focused tool | Workflow is distinctive, important, stable, and underserved | Upfront cost and ongoing product responsibility |
Define requirements from the work, not the spreadsheet
- 01
Outcome
What must be true when the process is complete?
- 02
Users and roles
Who creates, reviews, approves, administers, and only views?
- 03
Normal path
What happens in most cases from trigger to result?
- 04
Exceptions
Which variations need support, and which should remain manual?
- 05
Systems
Where is the source of truth, and which data or actions must move?
- 06
Evidence
What history, status, approval, or export must the business retain?
- 07
Measure
Which time, cost, error, or service result will show improvement?
Anonymized example: approval work beyond the spreadsheet
A team used a spreadsheet to track financial requests and approvals. The calculations were manageable, but the surrounding workflow was not: access differed by role, supporting evidence lived elsewhere, status updates were manual, and nobody had a dependable audit trail.
Buying a broad platform would have forced the company to change more than the target process. Connecting systems solved only part of the problem. A focused internal tool was justified because the workflow was stable and high consequence. Its boundary stayed narrow: requests, role-based approval, audit history, and required integrations.
What to include in the build decision
- Discovery and process definition—not only interface development.
- Authentication, permissions, security review, backups, and auditability.
- Data migration and integration with existing systems.
- Testing, rollout, training, and a manual fallback.
- Hosting, monitoring, support, dependency updates, and future changes.
- The opportunity cost of the internal people needed to own decisions.
When not to build an internal tool
Do not build when a supported product meets the important requirements, the process has no owner, the rules change every month, or the organisation cannot maintain the result. Avoid a complete replacement when one integration or small operational interface removes most of the pain.