Low-code vs custom software: what should SMEs choose?

What to look at first

The choice is not ideological. It depends on lifespan, risk, integrations, and who will maintain it.

• Estimate expected lifespan.
• Check integration depth.
• Assess data sensitivity.
• Plan maintenance ownership.

What the result should be

The company chooses speed where speed matters and ownership where ownership matters.

Choose by lifespan, risk and rate of change

Low-code works well when an internal process needs quick validation, risk is limited and platform boundaries fit. Custom engineering fits distinctive customer journeys, high volume, complex permissions and long-lived product work. Evaluate expected life, users, integration depth, security and who operates the system in three years. A prototype decision does not need to become the permanent production architecture.

• Temporary workflow or structural operating system.
• Internal users or external customer product.
• Simple forms or complex domain rules.
• Standard connectors or deep API contracts.
• Acceptable platform dependency and exit plan.

Model total cost at realistic usage

Low-code can start cheaply and become expensive through per-user licences, automation runs, premium connectors and specialist administration. Bespoke work costs more initially but gives control over hosting and direction. Build scenarios for growth, external users, storage and transactions. Include internal development, governance, tests and migration. Compare equivalent functionality and service over several years, not a free trial with a mature application.

• Maker, staff and external-user licences.
• Run, storage, API and premium-feature charges.
• Engineering, testing, security and operation.
• Impact of price changes and platform limits.
• Cost and feasibility of export or rebuild.

Assess data, security and governance before the pilot

A visual builder does not remove privacy or access responsibility. Review data location, subprocessors, roles, logs, backups, identity and secret management. Decide who may publish applications and how changes are reviewed. Without governance, critical workflows end up in personal accounts. Sensitive or critical work deserves an independent security and architecture review regardless of technology.

• Organisation-owned accounts and central identity.
• Separate development, test and production.
• Versioning, review and recovery of changes.
• Least-privilege connectors and maker access.
• Export, monitoring and incident response.

Use a hybrid architecture where it offers the best balance

The choice is not binary. A low-code interface can call a stable API and owned data layer while custom services execute complex rules. A bespoke product can use managed identity, email or payment services. Make the boundary explicit so core data and logic do not disappear into hidden automations. Every component needs an owner, tests and monitoring.

• Low-code for internal forms and simple approvals.
• Owned APIs for domain rules and integration contracts.
• Managed services for commodity infrastructure.
• One source for core records and state.
• End-to-end observability across the workflow.

Match quality and operations to the platform

Low-code changes engineering work but does not remove it. Makers need process, data, security and testing skills; engineers remain important for complex integrations and critical logic. Define review, test data, release and incident ownership. More than one person must understand each important flow. Bespoke systems need the same discipline plus dependency, infrastructure and technical-documentation work. Compare team capability and continuity, not only tooling speed.

• Two people understand each critical workflow.
• Automated tests where the platform supports them.
• Release calendar and recoverable previous version.
• Monitoring of errors, queues, cost and latency.
• Documented rules, connectors and manual fallback.

Decide through recognisable operating scenarios

An internal approval flow using standard fields and common productivity connectors often suits low-code. A customer platform with thousands of external users, specialised pricing and its own roadmap points toward bespoke or hybrid. A temporary migration dashboard can remain low-code; a real-time order engine should not be chosen on speed alone. Score each scenario for differentiation, scale, sensitivity, integration depth and lifespan, then choose by component.

• Internal CRUD tool: test low-code first.
• Customer digital product: compare bespoke and hybrid seriously.
• Critical transactions: fixed rules and engineering control.
• Temporary campaign or pilot: weight speed more heavily.
• Uncertain use case: build small and schedule a formal review.

Plan the transition before the prototype succeeds

Lock-in often grows when a pilot becomes popular. Define limits for users, volume, complexity, latency and risk. Crossing a limit triggers architecture review and a choice to optimise, split or rebuild. Keep data exportable, document rules and use API contracts. A successful pilot then proves value without becoming a permanent platform by accident.

• Thresholds for cost, volume and response time.
• Ownership of data, process and documentation.
• Automated export and restoration test.
• Review before a substantial new module.
• Phased migration without stopping operations.