We published our thoughts on low-code last year. Since then, three more clients have asked us to evaluate platforms, two more have asked us to rescue projects that started on low-code, and one client used Power Apps well for exactly the right thing. The question has not changed. The data has.
The Question Nobody Asks First
Every low-code conversation starts with "how fast can we build this?" That's the wrong first question. The right first question is "how long does this need to last?"
If the answer is six months, low-code is probably fine. Build it fast, validate the idea, throw it away or rebuild it properly. That's a legitimate use case and we've recommended it to clients.
If the answer is three years, you need to think harder. Three years means the platform will change. Your requirements will change. The person who built it might leave. The data model that made sense in month one will be awkward by month eighteen. And you'll be locked into a vendor whose pricing and roadmap you don't control.
The speed advantage of low-code is real. But speed to build and speed to maintain are different metrics, and most organisations only measure the first one.
John Li
Chief Technology Officer
What Changed Since Last Year
Three things have shifted in the low-code landscape.
Microsoft is winning. Power Platform adoption has accelerated. It's not because Power Apps is the best low-code tool. It's because most enterprises already have Microsoft licences. The procurement barrier is zero. That matters more than feature comparisons.
Shadow IT is getting worse. We predicted this last year and it's playing out exactly as expected. Business teams are building applications that IT doesn't know about. Some of them are genuinely useful. Some of them are handling sensitive data with no governance, no backup, and no security review. The person who built it doesn't think of themselves as a developer and doesn't know what they don't know.
The "citizen developer" promise is hollow. Every low-code vendor talks about empowering business users to build applications. In practice, the people who build useful low-code applications are technically minded people who would probably be decent developers if they had the training. True non-technical users hit the complexity wall within weeks.
41%
of enterprise low-code applications have no formal governance or oversight
Source: Gartner Low-Code Survey, 2022
Where We're Recommending It
Our recommendation hasn't changed much, but it's gotten more specific.
Internal dashboards and simple workflows. This is the sweet spot. Low volume, defined audience, tolerance for rough edges, short expected lifespan. Power Apps connected to SharePoint for an internal approval workflow? That's fine. That's a good use of the tool.
Prototyping before custom build. Want to validate whether a process works before committing to a six-month development project? Build it in low-code, test it with real users, learn what actually matters. Then build the real thing with those insights.
Data collection forms. Simple CRUD applications where the data model is stable and the user interface requirements are basic. Don't overthink this. A Power Apps form that writes to Dataverse is perfectly adequate for a lot of internal data capture.
Where We're Not
Anything customer-facing. The UI limitations of low-code platforms are fine for internal users who have no choice. They're not fine for customers who have plenty of choices. Brand consistency, performance, accessibility - low-code platforms compromise on all three.
Anything with complex business logic. If your workflow has more than five conditional branches, you're building spaghetti in a visual editor. That's harder to debug than code, not easier.
Anything that needs to integrate deeply with existing systems. Low-code platforms have connectors for popular SaaS tools. They struggle with legacy APIs, custom data transformations, and anything that doesn't fit the platform's mental model.
The Rescue Pattern
We've now done two "low-code rescue" projects. The pattern is the same both times. A team builds something in low-code. It works. People start depending on it. Requirements grow. The platform can't keep up. Performance degrades. The visual logic becomes unmaintainable. Someone calls us.
The rebuild takes longer than the original build because we're reverse-engineering business logic from a visual flow editor that nobody fully understands anymore. The total cost - original build plus rescue plus rebuild - is higher than if they'd built it properly the first time.
I'm not saying this to be smug. The original decision was reasonable at the time. But the lesson is clear: if something is going to last and grow, build it to last and grow.
The Honest Answer
Low-code is a tool. Like any tool, it has appropriate and inappropriate uses. The problem isn't the technology. The problem is that the marketing suggests it's appropriate for everything, and most organisations don't have the technical judgement to know when they've crossed the line from appropriate to painful.
If you're evaluating low-code for your organisation, ask three questions: How long does this need to last? How complex will it become? What happens when you outgrow the platform? If you have honest answers to all three, you'll make a good decision.