When should a spreadsheet become a web app?

A spreadsheet can be an excellent place to understand a process. You can change a calculation, add a category and test a new report without commissioning a system. That flexibility is valuable, especially while the work itself is still changing.

The decision to replace spreadsheets with a web app becomes worth examining when the team needs more than a flexible document. Different people may need different access. A request may need approval before someone acts on it. A record may need a dependable history across several steps. The question is which part of that work needs a stronger structure.

Start with one record and follow it through the business

Pick something concrete: an enquiry, a project allocation, a booking request or an invoice. Trace how it enters the process, who changes it and where it needs to end up.

Write down the handovers. A person might copy an enquiry from email into a sheet, ask a colleague to confirm capacity, prepare a quote elsewhere and return to the sheet to update its status. The sheet is only one part of that route.

Ask what information has to be copied, where someone waits for a response and how the next person knows the record is ready. This exercise gives you a brief for improvement before you have chosen a new tool.

Look for rules that depend on someone remembering them

A coloured row can communicate a status, but it depends on everyone interpreting the colour consistently. A note can explain an approval, but it may not prevent a record from moving forward without it.

List the rules the team currently holds in conversation or memory. Who can approve an allocation? Which fields are required before a quote goes out? Can a completed task be reopened? Who should see the change?

Those rules help distinguish a reporting need from a workflow need. Better reports may be possible within the current sheet. A process with separate permissions, approval states and a traceable history may need a different structure.

Improve the smallest part that will make a useful difference

A custom application is one option. A better-organised sheet, a form, an existing business tool or a small integration may be enough for the immediate problem.

For example, if the repeated work is copying a confirmed request into a second system, an integration may remove that handover. If the difficulty is deciding who can change a record at each stage, the process may need role-based controls. If the team cannot agree what the stages mean, define them before automating their movement.

The useful first release is a complete, manageable piece of work. It might take a request from submission to review, approval and a visible result. That is often easier to assess than replacing every workbook at once.

Design the interface around the roles

The person entering information, the person approving it and the person reviewing a report have different jobs. They do not necessarily need the same screen.

A team member may need a short form and a clear status. A manager may need exceptions and an approval queue. An owner may need a reliable overview with a route into the detail. Designing those views starts with the decisions each person needs to make.

This is where interface and experience meet. A clean dashboard does little for a process that leaves the next action unclear. A well-defined process still needs an interface that makes those actions understandable. UIX’s practice-management showcase explores that connection through engagements, resources and timesheets.

Plan the transition before the first release

Decide which records will move, how they will be checked and which system will be authoritative after the change. Choose a responsible person for resolving differences rather than letting the team update both versions indefinitely.

Use representative test records and include the awkward cases: incomplete requests, cancelled work, corrections and changes of ownership. A process often looks straightforward until one of those cases arrives.

Agree on a recovery plan and a way to export the data. If a limited parallel run is useful, define its purpose, duration and reconciliation method. Otherwise, the transition can create more duplicate work than it removes.

Include the work that follows the build

A custom app needs an owner after launch. Access requests, backups, hosting, maintenance and changes to business rules all require attention. An integration also needs a way to show when a connection has failed.

Ask who will receive those signals and what they can do about them. Make sure your team can understand the routine work without depending on one person’s memory. Documentation should explain the process and the responsibilities as well as the screens.

If the business expects frequent changes, discuss an ongoing partnership. If the workflow has a stable, limited scope, a focused project with a clear handover may fit better. Our guide to design retainers and projects sets out the questions behind that choice.

A useful first brief

• One record you want to follow from start to finish.
• The people who create, review, approve and use it.
• The handovers that create repeated work or uncertainty.
• The rules that need to be enforced rather than remembered.
• The information that must remain accessible and exportable.
• The person who will own the process after launch.

Bring the current sheet and a recent example of the work to a free 30-minute consultation. We can explore whether the next step is a smaller fix, an integration or a purpose-built web application. The goal is a process your team can use and look after with confidence.