Internal tools
When a business needs an internal tool instead of another spreadsheet
The practical signals that a shared file has become an operating system—and what to define before replacing it.
A spreadsheet is often the right first tool
Spreadsheets are flexible, familiar, and quick to change. They are excellent for discovering a process while the team is still learning which information matters. Replacing one simply because custom software appears more sophisticated can turn an adaptable workflow into an expensive set of assumptions.
The decision changes when the spreadsheet stops being a document and starts acting like a system. If several people depend on it to coordinate customer work, approvals, inventory, schedules, or money, the hidden cost is no longer the file itself. It is the manual checking, duplicated entry, unclear ownership, and recovery work surrounding it.
Look for operational pressure, not file size
A large spreadsheet can still be manageable, while a small one can create serious risk. The strongest signals are behavioural. Staff copy the same information between tools. Status meanings differ between teams. One person knows how the formulas work. Permissions are all-or-nothing. Customers wait while someone verifies the latest version. Managers assemble reports by hand because the source data is inconsistent.
These are signs that the business needs a defined workflow and source of truth. A purpose-built tool can make states explicit, assign responsibility, validate inputs, and connect the systems that already hold customer or transaction data.
- The same information is re-entered in two or more systems.
- Approvals and exceptions happen in chat or email without a reliable record.
- People cannot tell which status, owner, or version is current.
- Access must differ by role, team, location, or client.
- Manual reporting delays decisions or creates frequent reconciliation work.
Define the operating model before the interface
An internal tool should be shaped around decisions and handoffs, not around reproducing every column on screen. Start by mapping how work enters the business, which states it passes through, who owns each transition, what can block it, and which systems must be updated.
The first release should cover one complete, valuable path. For example: receive a request, validate it, assign an owner, approve an exception, and record the outcome. Trying to absorb every edge case and report immediately often creates a long build before anyone experiences the core improvement.
Know when not to build
Custom software is difficult to justify when the process is temporary, changes every week, has very few users, or can be handled well by configuring an existing product. It also requires an owner after launch: someone must decide priorities, maintain data quality, and support changes in the business.
A short discovery phase should compare three options: improve the current process, configure an established tool, or build a custom one. The right outcome may be a cleaner spreadsheet with better rules. The purpose of discovery is to reduce uncertainty, not to manufacture a software project.
Practical takeaway
Build an internal tool when a stable, important workflow needs clear states, ownership, permissions, or integrations—not merely because a spreadsheet looks untidy.
Continue reading
AI & automation
Where AI belongs in business operations
Read articleBooking systems
A booking system is an operations product, not just a form
Read articleHave a workflow or product decision to untangle?
We can map the problem, test the useful scope, and decide what is worth building.