The Promise Was Big. The Reality Is Messier.
In 2019 and 2020, the pitch from low-code vendors was aggressive. Gartner predicted that by 2024, over 65% of application development would happen on low-code platforms. Platforms like OutSystems, Mendix, Microsoft Power Apps, and Appian ran campaigns telling businesses they no longer needed large development teams. Drag. Drop. Deploy.
It did not quite work out that way.
Low-code platforms are not a failure — that would be too simple a conclusion. But they are also not what was advertised. In 2026, they occupy a specific and genuinely useful place in the software landscape. The problem is that most businesses still do not know exactly where that place is — which leads to expensive mistakes in both directions.
What Low-Code Actually Got Right
Start with credit where it is due. Low-code platforms genuinely changed what is possible for certain categories of software.
Internal tools and dashboards are the clearest win. If your operations team needs a form to submit requests, a dashboard to track approvals, or a simple workflow to route tasks between departments — tools like Power Apps, Retool, or Zoho Creator can get that built in days rather than weeks. For problems of this shape, low-code is the right answer and traditional development is overkill.
Workflow automation is another genuine strength. Connecting systems that do not talk to each other — routing a form submission into a CRM, triggering an email when a spreadsheet row changes, syncing data between two platforms — this is exactly what low-code automation tools handle well. Microsoft Power Automate and Zoho Flow have saved thousands of businesses from writing custom integration code.
Prototyping and internal validation also benefit. Before you invest in a full custom build, a low-code prototype can validate whether a process actually works the way you think it does. That is a legitimate use of the technology.
Where It Falls Apart
The problems start when businesses try to use low-code platforms beyond these boundaries.
Complex business logic breaks the abstraction. Low-code platforms work by hiding complexity behind visual interfaces. That works until your business logic is itself complex. Pricing rules that vary by customer segment, region, and product category. Multi-level approval hierarchies with exception handling. Real-time inventory calculations across multiple warehouses. At a certain level of complexity, you are no longer dragging and dropping — you are writing logic inside a visual editor that is harder to debug than actual code, with fewer tools available to help you.
Performance ceilings appear faster than expected. Most low-code platforms are optimized for moderate data volumes and standard query patterns. When a business scales — more users, more records, more concurrent transactions — the platform's abstraction layer starts introducing latency that you cannot fix without access to the underlying infrastructure. A custom-built system lets you optimise at the database and application layer. A low-code platform gives you whatever performance the vendor's architecture allows.
Vendor lock-in is severe. With custom code, switching vendors or bringing development in-house is painful but possible. With a low-code platform, your application logic lives inside a proprietary system. If the vendor raises prices, discontinues a feature, or shuts down, your options are limited. Migration is rarely straightforward — the visual workflows do not export cleanly to any other system.
"No developers needed" was always a stretch. The more honest low-code vendors now use the term "low-code" rather than "no-code" precisely because serious implementations still require technical people. Someone needs to manage data models, handle integrations, write the logic for edge cases, and maintain the platform as the business changes. The developer did not disappear — they just changed tools.
The Right Way to Think About Low-Code in 2026
Low-code is a category of tooling, not a replacement for software engineering. The question is not "should we use low-code?" but "is this problem the right shape for low-code?"
A useful framework:
- Use low-code when the problem is a standard workflow, an internal tool, or an integration between existing systems — and when your data volumes and logic complexity are moderate
- Use custom development when your business logic is genuinely complex, when the software touches customer-facing experiences where performance and design matter, or when you need to own and control the system long-term
- Be cautious with low-code for anything that sits at the core of how your business operates — the risk of hitting a ceiling at the worst possible moment is real
The businesses that get the most out of low-code platforms are the ones that use them deliberately, for the right problems, alongside — not instead of — engineering capability.
The ones that struggle are the ones who bought the 2020 pitch and are now rebuilding.