Every enterprise conference in 2021 has a low-code keynote. The pitch is compelling: build applications without developers, ship faster, enable business users. Gartner says 65% of application development will be low-code by 2024. After evaluating half a dozen platforms for clients this year, we have some thoughts about what that prediction is actually worth.
What You Need to Know
- Low-code platforms genuinely reduce time-to-market for simple, well-defined applications
- They struggle with complex business logic, custom integrations, and anything that doesn't fit the platform's mental model
- The real cost isn't the licence. It's the lock-in, the workarounds, and the eventual rebuild when you outgrow the platform
- Low-code is a tool, not a strategy. Knowing where it fits (and where it doesn't) is the real skill
Where Low-Code Works
Let's start with the genuinely useful applications. Low-code platforms like Microsoft Power Apps, OutSystems, and Mendix do real things well.
Internal tools and dashboards. If you need an internal form that writes to a database, a dashboard that pulls from your CRM, or a workflow that routes approvals, low-code is often faster and cheaper than custom development. The audience is small, the requirements are well-defined, and the tolerance for rough edges is higher.
Prototyping and validation. Need to test whether a process works before investing in a full build? Low-code is excellent for this. Build it in a week, test it with real users, throw it away or rebuild it properly based on what you learn.
Simple data capture. Forms, surveys, basic CRUD applications where the data model is straightforward and the UI requirements are standard.
65%
of all application development will be low-code by 2024 (predicted)
Source: Gartner, Low-Code Development Technologies Forecast, 2021
Where Low-Code Breaks
The problems start when you push past the basics.
Complex business logic. When your approval workflow has twelve conditional branches based on three variables, the visual flow builder becomes harder to read than code. We've seen Power Automate flows that span seventeen screens of branching logic. Debugging them is a nightmare. Modifying them is worse.
Custom integrations. Low-code platforms have connectors for popular SaaS tools. Need to connect to a legacy system with a SOAP API from 2008? Need to transform data in a way the platform doesn't support? You're writing code anyway, just inside a platform that makes it harder.
Performance at scale. Most low-code platforms work beautifully with a hundred records. Some struggle with ten thousand. We've seen dashboard response times go from two seconds to forty-five seconds as the data grew. The platform abstraction that makes building fast also makes optimising hard, because you don't control what's happening under the hood.
The promise of low-code is that you don't need developers. The reality is that you still need developers, but now they're also debugging someone else's platform.
John Li
Chief Technology Officer
Vendor lock-in. This is the one nobody talks about at the conferences. Your low-code application lives on the vendor's platform, uses the vendor's data model, and often can't be exported in any useful format. If you outgrow the platform or the vendor changes their pricing, your options are limited. Migration means rebuild.
The Shadow IT Risk
Here's the pattern we're seeing more and more. A business team builds an application in Power Apps or Airtable because IT is too slow. It works. They use it every day. Six months later, twenty people depend on it. Nobody in IT knows it exists. There's no backup strategy. There's no security review. The person who built it goes on leave and nobody can modify it.
36%
of enterprise applications are now built outside of IT departments
Source: Everest Group, 2021
This isn't the fault of low-code platforms. It's the predictable result of making application building easy without making application governance easy. The same democratisation that's supposed to help creates new risks if there's no framework around it.
Our Recommendation
Low-code is a useful tool in a toolbox that should also contain custom development, SaaS products, and sometimes pen and paper. Use it for the things it's good at: internal tools, prototypes, simple data capture. Don't use it for the things it's bad at: complex logic, performance-critical applications, anything that needs to last more than two years without a rewrite.
Most importantly, have a clear policy about what gets built in low-code and what doesn't. That policy should include who owns it, who maintains it, where the data lives, and what happens when it outgrows the platform.
The question isn't "should we use low-code?" It's "for which problems, with what governance, and what's the exit plan?" Most organisations skip straight to "yes" without answering any of those.
Isaac Rolfe
Managing Director