When should a spreadsheet become a web app?

Look for a process problem, not a row count

A spreadsheet can be an excellent place to calculate, explore and organize information. Its size alone does not tell you whether an app would help. Look at the work around it: people copying the same details into several places, uncertainty about who changed a status, or customers needing information that is unsafe to expose through the whole file.

Observe one complete task from arrival to completion. Record who supplies the information, what decisions are made, which changes matter and where people leave the sheet for email or another system. Separate inconvenience from a meaningful operational risk. If a clearer layout, protected formula or agreed owner fixes the problem, try that before commissioning software.

Compare three possible next steps

Improving the spreadsheet preserves a familiar tool and allows flexible analysis. It works best when the team can coordinate edits and access needs remain simple. An existing product can provide a defined workflow sooner, provided its permissions, exports and integration options suit the task. Check those capabilities in the subscription you would actually use.

A custom web app gives you more control over a distinctive process or customer experience. It also creates responsibilities for hosting, access, backups, support and future changes. Compare the complete operating arrangement, including manual work that remains. A custom interface is worthwhile when it resolves an important constraint, not merely because it looks more finished than a sheet.

Translate columns into records, rules and actions

Start with a copy containing invented sample data. Name the real things represented by rows: customers, requests, projects or appointments. Decide which need stable identifiers and how they relate. A customer name is a label that can change; it is usually a poor way to connect every related record.

Then document the rules hidden in formulas, colors and team habits. If a green cell means approved, define who can approve it and what becomes possible afterward. Record required fields, valid status transitions and correction procedures. List every export and downstream tool that relies on the current format. These dependencies often matter more than reproducing the spreadsheet’s appearance.

A hypothetical request-tracking app

Imagine a small production studio tracking customer requests in a shared sheet. Staff copy updates into emails, and customers ask which version is approved. A focused first release might let a staff member create a request, attach a reference, move it through agreed stages and publish a customer-visible update.

The customer sees only their own requests and approved information. Internal notes remain restricted. The first release includes correction history and an export, while payments, a scheduling engine and a general chat system remain outside scope. The acceptance test follows one request from creation to completion, including a rejected attachment and an unauthorized access attempt. This is a hypothetical design example, not a claim about client work.

Make permissions and failure behavior explicit

Describe access as actions on specific records: who can view, create, edit, approve and export. Logging in does not mean a person should see every record. OWASP’s authorization guidance distinguishes identity from permission and recommends checking permissions on every request. Hiding a button is not a substitute for enforcing access in the application.

Decide what happens when two people edit the same request, an upload fails or a notification cannot be sent. Show whether a change was actually saved. Give users a way to recover without accidentally repeating an action. A backup is only part of recovery: assign someone to restore it, define what data loss the business can tolerate and test the restoration procedure.

Use a first-release and migration checklist

Choose a small representative set of records for a trial import. Compare totals, relationships, dates and important calculations with the source. During transition, state which system is authoritative; allowing both to change without reconciliation creates a new version of the original problem.

• Name the primary user, complete task and result that the first release must support.
• Document required fields, permitted state changes and who can perform each action.
• Test representative records, unusual cases and access from a different user account.
• Agree an import process, a reconciliation check and a plan for changes made during migration.
• Provide an export and document account ownership, support, backup and recovery responsibilities.
• Keep a rollback decision and review the trial with the people who perform the task daily.