Consider an internal application when the current tools cannot support essential access rules, approvals or handovers, even after improving data and file practices. If the problem is inconsistent input or duplicated files, address those first. Row count alone is not a reason to replace a spreadsheet.
“Have we outgrown Excel?” often follows a specific failure. Sales used different price lists, a report was out of date, or the person who maintains the main workbook was away. These situations have different causes. Replacing the spreadsheet is not automatically the right response to all of them.
First distinguish data quality, file management and workflow control. Otherwise a new application may reproduce the same uncertainty in a more polished interface.
Problems that may still belong in the file
Inconsistent product names, mixed date formats and missing required information can often be addressed through clearer fields, controlled choices and validation. Those changes deal with the input problem before it becomes a software project.
Multiple copies sent by email point to another issue: ownership and collaboration. A shared location, an accountable file owner and appropriate permissions may be the first improvement. Available collaboration and history features depend on the tools, versions and storage arrangement actually in use. Assess that setup rather than treating every spreadsheet environment as identical.
A slow workbook also deserves investigation of formulas, external references and duplicated information. Row count alone is a poor reason to commission a web application. Conversely, a small file can support a business process with serious responsibility and access requirements.
When the problem is the process
Follow one request from creation to completion. If people must message each other to explain every handover, or colours represent states that nobody has defined consistently, the process is relying on personal interpretation.
Consider a purchase request. An employee submits it, a manager approves it and purchasing acts on it. If the request changes after approval, the team needs to know which version the manager accepted and whether another decision is required. File edit history and business approval history answer different questions. Being able to recover an old file does not by itself define when an earlier approval stops applying.
Access requirements can expose a similar mismatch. If employees should see only their own branch but the workflow requires distributing the whole workbook, assess better permissions or a suitable application. Hiding a column should not be treated as an access control.
| Observed problem | First option to assess |
|---|---|
| Inconsistent entries | Forms, validation rules and data ownership |
| Several copies with no trusted current version | Shared storage, permissions and collaboration rules |
| Repeated copying between useful applications | Integration between existing tools |
| Required workflow states, roles and exceptions | Suitable packaged software or a scoped internal application |
Interview the people who handle exceptions
Ask a regular user to show a recent item that was difficult to complete. How did they discover its current state? Where did they check the missing information? Who could take over if they were unavailable?
These questions reveal rules that are not recorded in the sheet. Someone may know that a particular customer needs another document, while no field records that requirement. Copying the existing column headings into a new application would omit the rule again.
Include the receiving team. An employee may consider an item complete when the visible cells are filled, while accounts or operations still has to call for clarification. Agree what the recipient actually needs before deciding the application’s screens or feature list. This can expose an avoidable handover problem without requiring a complete replacement.
Migrate a bounded piece of work
Illustrative scenario: a service team maintains one file for requests and another for customers. A useful first scope could cover receiving, assigning and closing a service request, while retaining a reference to the existing customer record. It does not need to move every department at once.
Define each field before importing. Set contradictory records aside for review. Identical customer names can refer to different people. A status called “closed” may currently include both completed and cancelled requests. Importing those values unchanged can produce a tidy report with an unclear meaning.
Reconcile record identity, status, ownership and relationships, as well as the number of rows. Matching totals do not prove that data landed in the right fields or that a request belongs to the correct customer. Give the people who understand those relationships a role in acceptance.
Decide where edits happen during the transition
The transition becomes difficult when both the workbook and the new application remain freely editable. Once the records differ, someone must decide which version is authoritative.
One approach is to send new work to the new system while retaining the old file for history. Another is to trial a defined team or workflow first. Either needs a clear starting point, an owner for reconciliation and a rule for unfinished requests that cross the boundary.
A fallback plan needs more than a backup file. Describe how work created during the trial would return to the earlier process, who can stop the trial and which records need checking before normal work resumes. A small scope makes it possible to account for all of those outstanding items.
Make the decision from observable work
After the trial, ask whether staff can find a request, understand its state and take it over without reconstructing the history. Observe the work that caused the original concern: repeated entry, status enquiries or records returned for correction. Record a baseline before the trial so comparisons have a useful reference.
If better file management resolves the problem, custom software may be unnecessary. If important requirements remain unmet, the workflow examples and acceptance criteria now provide a basis for choosing packaged software, integration or a custom component. That is a stronger decision than replacing a tool simply because it looks old.
Once the spreadsheet’s limits are clear, use the guide to buying software or building custom to compare what to buy, connect or build against the work that matters.
Give your team a workflow beyond the latest spreadsheet
Talvyn Labs designs and builds internal applications around real work, from access and status tracking to handovers and a staged data migration. Bring an anonymised sample of your workbook and the task that keeps needing correction. We can use those to define a useful first scope.
Discuss your internal app