An operational Excel workbook can become the place where requests are entered, approvals are recorded, jobs are tracked and decisions are made. When that happens, the question is not simply how to make the workbook easier to use. It is whether low-code or a managed custom web application is the better way to run the process.
For UK SMEs, low-code can be a strong option where a workflow fits standard forms, stages and permissions. A managed custom web application is often the better fit where the spreadsheet contains business-specific rules, complex exceptions, sensitive permissions or integrations that need dependable handling.
Start with the workflow, not the platform
Excel remains useful for modelling, forecasting, ad-hoc analysis and flexible calculations. It becomes harder to govern when it is also the live system for operational work.
A workbook is supporting an operational workflow when people use it to:
- submit requests, jobs, inspections or orders
- assign work or update statuses
- approve, reject or amend records
- create documents or pass information to another system
- decide what work can proceed next
- retain evidence of what happened and who acted
The number of users is not the deciding factor. A workbook used by one administrator can still be business-critical if it controls live records or decisions.
Replace the process the spreadsheet supports, not just its rows, columns and formulas.
Before comparing approaches, map one record from entry to completion. Identify who enters it, who may change it, which rules apply, what happens when information is incomplete, and which downstream activity depends on it.
Map the Excel process before replacing it so that the replacement reflects the work people actually do, including exceptions and handoffs.
Low-code vs managed custom web app
Low-code platforms provide configurable building blocks, such as forms, workflows, roles and connectors. A managed custom web app is designed around a particular operational process and is then supported as an ongoing service.
Neither approach is automatically right. The useful comparison is whether each approach can enforce the controls your workflow needs without relying on hidden knowledge, manual corrections or fragile workarounds.
| Decision area | Low-code approach | Managed custom web app approach |
|---|---|---|
| Workflow rules | Works well when rules fit supported configuration | Suits rules, calculations and exceptions that need purpose-built behaviour |
| Permissions | Assess whether standard roles cover who can view, submit, approve and amend records | Permissions can be designed around roles, ownership, stages and specific business rules |
| Auditability | Check what changes, approvals and actions are recorded and available to administrators | Audit records can be designed around the evidence the business needs to retain |
| Integrations | Useful where supported connectors handle the full process reliably | Useful where systems need specialised validation, reconciliation or recovery handling |
| Process changes | Efficient where change remains within the platform's configuration model | Useful where the workflow itself changes and needs new behaviour rather than more configuration |
| Ongoing operation | Requires people who can govern configuration, access and platform changes | Uses a managed service for the application while business owners retain responsibility for policy decisions |
Both routes can provide forms and dashboards. The difference is whether a form, permission or workflow stage means what your business needs it to mean in practice.
Test the difficult scenario, not only the demonstration
A standard demonstration often shows the straightforward path: someone enters a record, a manager approves it, and the record moves to the next stage.
Your decision should be based on the harder situations already handled by the workbook or surrounding emails.
For example, consider an approved job where the price must change. The process may need to preserve the authorised amount, apply the correct calculation rules, seek further approval and prevent paperwork being issued too early.
Ask how each approach would handle:
- a user attempting an action they are not authorised to take
- an approval that is amended or withdrawn
- an exception requiring a different route
- a failed export or rejected record in another system
- a duplicate submission or repeated integration attempt
- a rule change while records are already in progress
A feature label is not enough. Role-based access, workflow automation and audit history only help when they cover the actual control required.
When low-code is a good fit
Low-code deserves serious consideration when the workflow is conventional and the platform can express it cleanly.
It may be a suitable route where:
- staff submit consistent information through standard forms
- records move through stable, straightforward stages
- approval routes are predictable
- calculations are limited and readily represented in the platform
- required integrations are supported and can be tested end to end
- a named team can maintain configuration, access and platform changes
For example, a request register with validated fields, a clear approval route, searchable records and a reliable connection to an existing service may suit low-code well.
The key qualification is that the required controls should work natively. If users need a separate spreadsheet, email process or manual correction to make an essential rule work, the configuration may not be a dependable replacement.
When a managed custom web app is the better fit
A managed custom web application is usually stronger when the spreadsheet represents a distinctive operational process rather than a standard form and approval pattern.
Consider a managed custom approach where the workflow needs:
- permissions based on a combination of role, record ownership, location and workflow stage
- calculations that depend on versioned rules, historical assumptions or complex exceptions
- specific approval evidence and decision history
- integrations that need validation, reconciliation and clear failure handling
- controlled changes to documents, rules or business processes over time
- a supported route for technical maintenance, monitoring and operational change
This is not an argument for rebuilding every familiar spreadsheet layout. A custom application should simplify and clarify the process, not reproduce avoidable complexity.
The strongest case for custom behaviour is where an essential control would otherwise depend on staff remembering an unwritten rule or performing a workaround outside the system.
Auditability and permissions should be specific
Operational spreadsheets often use informal controls: a coloured cell may indicate approval, a comment may explain an exception, or a protected tab may contain calculations that only one person understands.
A replacement should make these controls explicit.
For permissions, define who can:
- create a record
- view sensitive fields
- amend a record at each stage
- approve or reject a decision
- reopen completed work
- administer access
For auditability, define the evidence that matters. A technical log may not be sufficient if the business needs to know the previous value, who made the change, why it was made and which approval applied at the time.
Research on spreadsheet quality identifies risks including ambiguity, conflicts, redundancy and formula errors. Moving the workbook into a browser does not resolve those risks by itself. The replacement needs clear rules and clear ownership.
Compare responsibility after launch
The decision is also about who governs the application after the original workbook expert is unavailable.
With low-code, the platform provider may run the infrastructure while your business remains responsible for configured rules, access, integration credentials and internal governance. With a managed custom web app, the technical operation can be managed as part of the service, while the business still decides its policies and authorities.
Whichever route you choose, agree responsibility for:
- approving business-rule changes
- managing joiners, movers and leavers
- monitoring failed workflow steps and integrations
- investigating incidents
- maintaining documentation
- reviewing recovery arrangements
“Managed” should have a clear scope. It should not mean that nobody knows who is responsible when an operational record is wrong or a process needs to change.
This is especially important when Excel has become an unofficial system of record. The replacement should establish an agreed source of truth rather than creating another uncertain copy of the process.
A practical way to decide
Use the same realistic scenario to assess both approaches. Include representative records, the most important approval rule, a meaningful exception and an integration failure or interrupted handoff.
Then ask:
- Can the approach enforce the required rules without manual workarounds?
- Can users understand what they are allowed to do at each stage?
- Can the business explain and evidence important approvals and changes?
- Can failed integrations or duplicate actions be identified and resolved safely?
- Can a future rule change be implemented and tested in a controlled way?
- Is there a clear owner for the application once it is live?
If low-code handles the difficult scenario cleanly and your organisation can govern the configured application, it may be the proportionate choice. If essential controls depend on workarounds, specialised logic or a tightly managed operational process, a focused managed custom web application may provide better control.
For a separate decision about adopting an established product rather than building around a specific workflow, see our comparison of managed custom applications and packaged software.
Start with a Free Fit Check
A Free Fit Check is the normal first step if you are considering replacing an important Excel workflow. It helps establish whether the workbook is supporting an operational process, whether a managed custom application may be suitable, and which questions need answering before any commitment.
Bring the workbook's purpose, the people involved, the records it holds and the most difficult exception. If there is a good fit, any later discovery can be scoped around the workflow, rules, permissions, data and acceptance criteria required for a safe replacement.
You can also review how Spreadsheet Upgrade works and the current pricing information.