The problem is usually ownership, not row count
A spreadsheet can be an excellent working tool. It is flexible, familiar and easy to change while a process is still being discovered. A large sheet is not, by itself, a reason to commission software.
The warning sign is that people can no longer agree on what a row means or who should act on it. One person changes a delivery date, another works from an exported copy, and the customer gets an answer based on an older message. The real cost is reconstructing context.
Start by following one recent piece of work. Write down every place its details were copied and every time someone had to ask whether a task was finished. This tells you whether you have a spreadsheet problem, an unclear process, or both.
Look for recurring failure patterns
Use concrete incidents rather than a general feeling that the business needs a dashboard. A missed follow-up and a difficult monthly report may need different fixes. Record the frequency, people involved and consequence of each issue.
Consider a made-to-order business. A customer request, an approved specification and a paid order are different records. If they are represented by one freely editable row, a change in one field may silently alter what the team believes was agreed.
- Two people maintain competing versions of the same record.
- Access should differ by role, but everyone can edit everything.
- The next action depends on someone remembering to send a message.
- You cannot explain who changed a status or why.
- Reporting requires repeatedly cleaning the same information.
Choose the smallest intervention that removes the failure
First test clearer ownership, protected fields, a shared definition of statuses and one agreed working file. If that resolves the issue, you have avoided an unnecessary build. If an established product matches the process, configuration may be enough.
Custom software becomes more plausible when the business has a stable workflow that existing tools repeatedly bend out of shape. A focused intake and work queue may solve that problem without replacing accounting, email or every spreadsheet.
| Situation | Useful first move |
|---|---|
| Unclear responsibilities | Agree on owners and status definitions |
| Reliable process, scattered records | Choose one source of truth and connect the tools |
| Distinct workflow with repeated exceptions | Prototype a narrow internal tool |
| Process changes every week | Keep discovery flexible; delay a large build |
Scope the first release around one journey
Choose a path such as enquiry received → requirements checked → quote approved. Specify the information required at each handoff and the people allowed to move it forward. Include a way to correct mistakes and an obvious queue for incomplete records.
Migration deserves its own plan. Decide which historical records are worth moving, who checks the imported data and when the old sheet becomes read-only. Keeping two editable systems indefinitely usually recreates the original ambiguity.
Make the decision reviewable
Write a one-page brief with the current failure, the proposed change and the evidence you will look for. Useful observations include fewer unowned requests, less copying, easier corrections and more reliable status answers. Establish the baseline before launch; do not assume that a new interface proves improvement.
Also name who will maintain permissions, handle exceptions and request changes. Custom software has an ongoing ownership cost. The right decision is the one your team can operate and sustain, not simply the most impressive demonstration.