Replace a spreadsheet when the process needs controls the workbook cannot reliably provide: clear record ownership, approvals, restricted access, repeated handoffs or a history of corrections. Do not commission a web application simply because a spreadsheet has many rows. A well-run workbook can still be the right tool.
An internal tools development project should make a task easier to complete and verify. The dashboard comes after that decision. If source records disagree or nobody owns the next action, a more attractive chart will not repair the operation behind it.
Related service: CRM, ERP and web application development- 01Observe the task and identify fragile handoffs.
- 02Separate records, calculations and decisions.
- 03Compare configuration with a custom workflow.
- 04Import and reconcile a representative sample.
- 05Pilot the task and verify its reports before switching.
SECTION 01
Check whether the workbook needs replacing at all
Ask the team to demonstrate where work breaks. Examples include overwritten approvals, a departed employee owning the only copy, conflicting status columns or people repeatedly joining files to answer a daily question. Fix a training or ownership problem directly rather than assuming a new application is required.
Microsoft documents using Excel tables as a source for a Power Apps canvas application. That illustrates a configuration option between a workbook and fully custom software. Check licensing, access, data limits and support for your actual workflow; the reference is not a claim that every workbook converts cleanly or that Catapult is a platform-certified partner.
A custom internal application is more defensible when several roles must coordinate a distinct process, validations span related records or existing products cannot enforce the required permissions. Keep ad hoc analysis in exported data where useful instead of recreating every spreadsheet capability inside the app.
SECTION 02
Split the sheet into records and allowed actions
A workbook row may mix a customer, a request and an approval. Separate those concepts before designing a database. Choose stable identifiers, required fields and relationships. Preserve meaningful source references so staff can trace an imported request back to the original record.
List allowed actions in each state: submit, approve, return for correction, fulfill or cancel. A person permitted to view a request may not be allowed to approve it. OWASP's authorization guidance is relevant here because controls must apply to the underlying request, not only to a visible button.
SECTION 03
Illustrative example: equipment requests with an approval queue
Imagine an operations team uses a shared sheet for staff equipment requests. A manager changes a status cell, someone orders the item elsewhere, and an administrator copies the delivery date back. This is a hypothetical process, not a Catapult client result.
A focused application could let staff submit requests, managers approve them and operations record fulfillment. The existing purchasing system still owns the order. If a request changes after approval, the app asks for the appropriate new decision instead of silently preserving approval for different equipment.
An admin dashboard shows requests waiting for approval, approved requests awaiting fulfillment and exceptions needing attention. Clicking a total opens the matching records. It does not label every old request overdue without a defined due-date rule, or assume an email was read because the notification was sent.
SECTION 04
Project tracking needs decisions behind the status labels
If the spreadsheet tracks projects, separate the project, work item, milestone and deliverable. Give each item an accountable owner, planned date and explicit completion condition. A task being checked off should not automatically approve the deliverable, release a payment or close the entire project.
In an illustrative customer-launch workflow, design approval must happen before implementation begins. A reviewer requests changes to the submitted design version; the task returns to its owner and the downstream item shows the dependency as unresolved. A revised date records who changed it and why, rather than erasing evidence of the earlier commitment. A project lead sees blocked work across projects while a contributor sees only authorized assignments.
A useful first release can cover assignments, dependencies, versions and the weekly exception report. Test reopening a completed task, changing a dependency and removing a contributor's access. Standard project-management tools may already handle these needs. Custom development is worth considering when the acceptance rules or connection to your operating records cannot be expressed clearly in the existing product; it does not imply a full resource-planning suite.
SECTION 05
Fulfillment tracking must reconcile quantities, not just dates
For a fulfillment workflow, identify which system owns the sales order and which owns stock. Define a smaller operational sequence such as approved order, reserved, picked, packed and dispatched. Keep requested, picked and dispatched quantities separate, including their units. A dashboard showing one completed order cannot explain whether every line was shipped.
Imagine an order for ten units with six available. The team may be permitted to dispatch six and keep four open, or it may need approval for any partial shipment. Write that rule down. If cancellation arrives after picking, staff need a controlled release or return-to-stock step, not an automatic deletion of the work. This is an illustrative workflow, not a claim of a delivered warehouse system.
Begin with one location and a selected order type. Reconcile partial shipments against the approved order and stock records; test repeat dispatch submissions, shortages and failed synchronization. Limit who can correct quantities and preserve the correction history. A suitable order-management or warehouse product may be the better foundation. Carrier booking, multi-warehouse allocation and a full warehouse-management replacement require separate scope and capability checks.
SECTION 06
Make operations, inventory and sales reports explainable
For every report, write the decision it supports, the underlying records, filters, date definition and refresh timing. An operations backlog may count open requests; a sales report may group opportunities by expected close date; an inventory view may distinguish on-hand, reserved and available quantities. Those numbers are not interchangeable.
Have a staff owner manually reconcile a small sample against the proposed report. Show the last refresh time where information comes from another system. A stale connection should produce a warning rather than a fresh-looking zero. Restrict exports to the same permitted records and fields as the dashboard.
A custom data platform is a broader commitment than a few operational reports. Multiple ingestion pipelines, historical transformations and organization-wide analytical governance need a separate brief. Do not assume those capabilities are included because a web application can display charts.
| View | Definition to agree | Evidence |
|---|---|---|
| Approval queue | Submitted requests without a current decision | Open the exact matching requests |
| Inventory summary | Quantity and unit rules from the approved stock source | Reconcile selected items and partial receipts |
| Sales pipeline | Opportunity stage, owner and reporting date | Explain reassignment and reopened opportunities |
SECTION 07
Reconcile the data and plan the switch
Trial-import a representative slice containing duplicates, missing values and old status labels. Keep a rejection report and ask the data owner to resolve uncertain mappings. A successful import command is not evidence that every customer relationship or quantity is correct.
Agree when the workbook becomes read-only and how changes during the transition are captured. Give staff a fallback and a named support contact. A small pilot should include the people doing approvals and corrections, not only the manager who requested the dashboard.
SECTION 08
Give the agency the process, formulas and exceptions
Provide anonymized sheets, key formulas, current reports and one difficult correction. Ask the agency to explain which behavior becomes application logic and which remains an external tool. Contact us for pricing against records, roles, migration and integrations rather than a screen count alone. For remote delivery, identify staff who can review calculations and accept the results.
SECTION 09
Frequently asked questions
When should a spreadsheet become a web application?
When the task needs reliable multi-user ownership, permissions, approvals, validation or connected workflows that the current setup cannot maintain. First check whether better configuration or an existing product solves the problem.
Can a custom dashboard combine sales and inventory data?
Where approved access exists, it can present selected data from both sources. Define the owner, identifiers, refresh time, quantity rules and permissions, then reconcile the report against the underlying records.
Will all our spreadsheet formulas be copied into the new app?
Only the agreed business rules should be implemented. Review formulas for errors, obsolete assumptions and duplicated logic before translating them, and test representative calculations with the business owner.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Create a canvas app based on Excel dataMicrosoft Learn
- Authorization Cheat SheetOWASP Foundation
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy