Registered office
20 Wenlock Road
London N1 7GU
Low-code is strongest for well-understood workflows that fit a platform’s connectors, permissions and governance model; custom software is stronger when the experience, rules, scale or integrations are distinctive. Neither route removes engineering discipline. The right choice depends on lifecycle cost, risk and who can safely own change.
Reviewed: 9 September 2026
Low-code vs custom software at a glance
| Factor | Low-code | Custom software |
|---|---|---|
| Early delivery | Often fast for supported patterns | More setup, but full design control |
| Best fit | Forms, approvals, internal records and standard integrations | Distinctive products, complex rules and specialised integrations |
| Change | Accessible to trained makers within governance | Requires a maintained engineering capability |
| Constraints | Platform limits, licences and vendor roadmap | Architecture, team capacity and ownership |
| Exit | May require rebuilding platform-specific logic | Code is portable only when contracts and architecture support it |
What counts as low-code?
Low-code platforms provide visual components, managed data services, connectors and automation so teams can create apps and workflows with less hand-written code. “Less” matters: meaningful solutions still require data modelling, permissions, testing, error handling and environment management. Custom connectors or code may still be needed.
A spreadsheet macro, a departmental form and a business-critical approval service do not carry the same risk. Classify the solution before deciding how much governance it needs.
Where low-code works well
Good candidates have a clear internal audience, repeatable rules and supported systems. Examples include equipment requests, site inspections, simple case tracking, approval flows, onboarding tasks and notifications. The platform can reduce infrastructure setup and let subject-matter experts participate closely in delivery.
Microsoft’s Power Platform delivery guidance describes several models, from decentralised citizen development to central delivery and blended teams. That is a useful reminder that low-code is an operating model as well as a tool choice.
Where custom software is safer
Custom development may be preferable where the workflow is customer-facing, differentiating, high-volume or difficult to express inside platform limits. It also provides more control over interface, performance, deployment and integration patterns. Complex real-time behaviour, unusual devices or strict portability requirements can make a general-purpose low-code platform an awkward fit.
Custom does not automatically mean secure or maintainable. It transfers responsibility for architecture, dependencies, testing, monitoring and long-term stewardship to the organisation and its development partners.
Do not ignore governance and shadow IT
Easy creation can lead to unknown apps, duplicate data and flows tied to an employee’s account. Establish:
- approved environments and connectors;
- solution owners and business-criticality classes;
- data-loss-prevention and access policies;
- development, test and production separation where needed;
- review, monitoring, backup and incident routes;
- handover when a maker or supplier leaves;
- a retirement process for unused solutions.
Microsoft’s governance-at-scale guidance sets out why security, monitoring, alerting and application lifecycle management must grow with adoption.
Compare the full lifecycle cost
Low-code cost can include per-user, per-app, automation, data, premium connector and environment licensing, plus administration and specialist support. Custom cost includes discovery, build, cloud services, dependencies, security, maintenance and developer capacity. Provider terms change, so price the actual users, transactions and environments against current licensing rather than an old headline.
Count change frequency. A low-code solution that trained operators can safely adjust may be economical. A heavily extended solution that repeatedly hits platform boundaries can cost more than a focused custom service.
Use a proof against the hardest requirement
Do not prove only that a form can be built. Test the uncertain part: permission boundaries, a large data set, a difficult connector, offline work, audit evidence or failure recovery. Define pass and fail before the proof begins.
- Map the current workflow, volume, exceptions and owners.
- List mandatory security, accessibility and operational needs.
- Price a representative scale, not a tiny pilot.
- Build the riskiest slice in the likely platform.
- Test support, handover and export as well as the happy path.
- Record the decision and the conditions that would trigger a review.
If the starting workflow is still unclear, use the guide to decide whether a manual process is ready for automation.
When a hybrid approach is best
A team might use low-code for internal approval and administration while a custom service handles the customer experience or complex calculation. Standard identity and data services can sit beneath both. The important work is defining system boundaries, source-of-truth data and failure ownership.
ACA’s software development and integration service covers both process discovery and production delivery. A workshop can test whether configuration, low-code, integration or focused custom work is the smallest sound answer.
Frequently asked questions
Is low-code only for simple apps?
No. It can support significant workflows, but criticality increases the need for architecture, testing, governance and skilled ownership.
Does low-code eliminate developers?
No. It changes where effort goes. Makers, administrators, security specialists and developers may all be needed as integrations and criticality grow.
Can a low-code app be migrated later?
Data may be exportable, but workflows and interface logic can be platform-specific. Test the exit route before the solution becomes essential.
Which option is faster?
Low-code is often faster for supported patterns. Custom can be faster than forcing a poor-fit platform through repeated workarounds. Validate the hardest requirement.
