TLDR: Agentic AI changed the economics of building apps. It didn’t change the economics of governing them. Power Platform’s value proposition was always 20% app builder and 80% operating system for citizen and pro-code work alike, and that 80% is exactly where enterprise spend actually lands over a five-year horizon.
Is Low-Code dead?
Here is a take I’ve heard a few times recently, “Low‑code is dead. With AI, I can build a React app in an afternoon. Why would I pay for Power Apps?”
It’s a reasonable thing to say, and Microsoft’s own move to support Code apps in Power Platform, letting developers bring TypeScript, React, and their tooling of choice into the platform, looks like an admission. If Microsoft is meeting pro‑code developers where they live, surely Canvas apps are a transitional technology on a slow march into irrelevance.
This take confuses the app with the platform. And it underestimates what enterprises actually pay for when they license Power Platform.
Before going further, it’s worth naming what I’ll call the moat throughout this piece: the governance, identity, DLP, lifecycle, and observability layer that every app inherits the moment it lands inside Power Platform.
- It’s invisible on Day 1.
- It dominates years two through ten.
- And it is the thing agentic coding cannot replicate, no matter how fast the first build gets.
Yes, Canvas-style building is getting commoditized – and that’s not the point
Let’s concede the easy part first. Building a working UI has genuinely gotten faster. An experienced developer with GitHub Copilot, Cursor, or Claude Code can stand up a polished, accessible, responsive React app in a fraction of the time it took two years ago. For straightforward CRUD-style applications, the gap between “I’ll build it in Canvas” and “I’ll build it in code” has narrowed enough that, in some teams, it’s effectively gone.
If the entire value of Power Platform was the Canvas designer, this would be a problem. It isn’t, and it isn’t.
The Canvas designer was never the moat. The moat is everything the app inherits the moment it’s deployed — identity, DLP, connector governance, the Dataverse security model, the licensing envelope, solution ALM, and CoE visibility.
That’s also the right frame for reading Microsoft’s Code apps move. It isn’t a retreat from low-code. It’s the platform team telling you which part of the stack actually matters to them: if you want to write code, write code – but do it inside our environment, with our identity, our connectors, our governance, our lifecycle. The designer is negotiable. The moat is not.
We’ll come back to Code apps later, because they’re the clearest example of this strategy in action. First, though, the question that should be driving the conversation in the first place.
The question should never be “how fast can you ship v1?”
To be fair, in a lot of early conversations with customers, the key question we hear is “how fast can you ship v1?”. But at Lantern, we always ground our answer in the reality that it’s not the most important question to consider.
If the only question that mattered in enterprise software was time to first working build, the conversation would have ended years ago, well before agentic coding. The reason we still have CIO conversations about platforms is that v1 is the cheapest, easiest, most fun part of the lifecycle. Everything that comes after, governance, security, audit, ownership transfer, dependency updates, retirements, M&A activity, is where the money actually goes.
This is what people miss when they reduce Power Platform to “the thing that builds Canvas apps.”
What’s in the moat
Let me make this real. Here are four scenarios I see play out repeatedly with mid to large customers. In each one, the gap between “custom code” and “Power Platform” is not about who shipped v1 faster. It’s about what happens on the day someone other than the original builder needs an answer.
1. The CISO question that becomes a project
The trigger. Your CISO walks in and asks: “Show me every application in our environment that reads customer PII from Dynamics. Tell me who owns it, who’s used it in the last 30 days, and what other systems it writes to.”
In Power Platform. With the CoE Starter Kit and Managed Environments turned on, this is a query not a project. Dataverse inventory joined with Purview’s data classification returns owners, last-run timestamps, connector inventory, environment, and sharing scope in hours. The answer is current because the inventory is live.
In custom code. This is a project. Someone audits repos. Someone audits Azure subscriptions. Someone interviews team leads. Someone correlates that with deployed frontends nobody has bothered to decommission. The CISO gets an answer in weeks and it’s wrong by the time it’s delivered, because the inventory is a snapshot of a moving target.
Takeaway: Agentic coding made it easier to build the app. It did nothing to make it easier to find the app five years later.
2. The data exfiltration that never happened
The trigger. A well-meaning analyst, or an agentic AI faithfully following their instructions, builds an app that pulls a customer list from SharePoint and posts it to a public Twitter account “for marketing.”
In Power Platform. Power Platform DLP is a connector-level runtime policy, not a data-classification scan. With a DLP policy separating Business and Non-Business connectors, the app cannot be saved, let alone published. The platform refuses on the analyst’s behalf, before any code runs, and the same policy travels with every connector call across the tenant.
In custom code. The analyst (or the agent) wires up the Twitter SDK and the SharePoint Graph API and ships it. DLP isn’t a feature you can recreate with a git pre-commit hook, it’s a runtime control. Recreating it for a custom app fleet means building, owning, and maintaining your own connector proxy and policy engine. Almost nobody does this. Almost everybody who skips it learns why eventually.
Takeaway: Agentic coding made the analyst faster. It also made the analyst’s worst idea faster, and only one of the two stacks knows how to refuse.
3. The app you forgot to maintain
The trigger. A team built a field service app in 2021. It runs on iPads in trucks. Nobody has touched the code since launch. It still works.
In Power Platform. That’s the default. Microsoft has shipped hundreds of platform updates in those years: runtime improvements, security patches in the hosting layer, connector SDK refreshes, identity stack rotations, TLS deprecations, browser-engine changes. The app inherited every one of them without a deployment, without a regression test, without a maintenance window. The team’s only job for four years was building new things.
In custom code. The same five years look different. React 17 → 18 → 19. Node 14 → 16 → 18 → 20 → 22. MSAL.js v1 → v2. Webpack → Vite. Five years of npm CVE advisories. A TLS 1.0 deprecation. An Azure App Service runtime stack reaching end of life. None of it is feature work. All of it is mandatory.
Takeaway: Agentic coding made the first build cheaper. It did not make the maintenance backlog disappear.
4. The acquisition
The trigger. You buy a company. They have 200 line-of-business apps. You need to move them into your tenant, apply your DLP policies, fit them under your licensing agreement, and prove to your auditors that nothing leaks across the boundary during the transition.
In Power Platform. This is a tenant-to-tenant migration with a Microsoft-documented path: solution export/import, environment-level segmentation while you triage, and Managed Environment policies that apply uniformly the moment apps land in the new home. The governance posture is consistent on day one of integration.
In custom code. This is numerous consulting engagements — each one re-deriving identity mapping, secrets rotation, audit evidence, and deployment topology for a different stack. Two hundred apps means two hundred discovery exercises before you can even begin to enforce a single uniform policy.
Takeaway: Agentic coding made each of those 200 apps cheaper to build. It made exactly zero of them cheaper to absorb.
TCO is the argument
The “low-code is dead” crowd makes one consistent mistake: they benchmark Day 1 cost against Day 1 cost. Power Platform’s licensing looks expensive if your reference point is “two days of a developer’s time.”
It looks remarkably cheap when your reference point is the five-year total of everything you stop paying for: identity integration, DLP enforcement, audit logging, secret rotation, dependency upgrades, framework migrations, connector maintenance, environment promotion tooling, observability, ownership tracking, and retirement workflows.
The numbers bear this out. Forrester’s 2024 Total Economic Impact of Microsoft Power Platform study — built around a composite organization of 30,000 employees and $10B in revenue — found a 224% ROI, $81.7M in net present value over three years, and a payback period of under six months, with $61.4M of that benefit coming specifically from reduced development and IT costs. That last number is the one to sit with. The platform’s biggest financial impact isn’t faster v1 delivery, it’s the IT cost line that never gets created in the first place.
Now flip the question: if you don’t license the platform, what do you have to build and staff instead? The honest answer, and the one most CIOs underestimate, is a platform engineering team.
Industry benchmarks from Gartner Peer Community, the CNCF, and platformengineering.org converge on the same ratio: mature platform teams run at roughly 5 to 10 percent of total engineering headcount, or one platform engineer for every 8 to 12 product engineers. For a U.S.-based enterprise with 80–200 product engineers, that’s a dedicated team of 6 to 12 specialists at a fully-loaded annual cost of $1.2M to $2.4M, every year, forever, before you’ve shipped a single feature.
That team’s job description, almost word-for-word, is to rebuild what Power Platform gives you on Day 1: golden paths, identity integration, DLP enforcement, connector governance, observability, and lifecycle tooling.
A custom-coded portfolio of 300 apps isn’t 300 apps. It’s 300 snowflakes, each with its own dependencies, its own deployment quirks, its own forgotten owner, its own CVE backlog. You don’t pay for that estate in license fees. You pay for it in the seven-figure platform team you staff in perpetuity to keep it alive, and which, per the DORA research, still only improves productivity by ~6% when poorly structured, and can actively reduce deployment throughput and stability if you get the team topology wrong.
Power Platform is, at its core, a deal: give up some of the freedom of arbitrary code, and we’ll handle the unglamorous 80% of the lifecycle for you – and we’ll do it for less than the platform team you’d otherwise have to staff yourself. The arrival of agentic coding changes the cost of writing the code. It doesn’t touch the cost of running the estate. It may have actually made that cost worse, by lowering the bar for what gets built, shipped, and forgotten.
The value of pro-code
To be clear, plenty of enterprise software still genuinely belongs in custom code: high-scale customer-facing products, specialized engines, anything with bespoke performance or UX requirements that no platform should pretend to abstract. The discussion here isn’t that pro-code is dead. It’s that the long tail of internal business apps: the workflow, approval, and field-data tooling that makes up most of an enterprise’s portfolio has always been the wrong place to optimize for Day 1 velocity over Day 1,000 governance.
Where Code apps fit, and why this is the right move
So we have two truths the industry usually tries to pit against each other:
- Some applications genuinely need code. The complex UI, the specialized libraries, the niche performance requirements, the team with React muscle memory.
- Every application, code or no-code, needs the moat: identity, DLP, ALM, CoE, lifecycle, observability.
For most of the last decade, the platform conversation treated these as a choice. Either you got the developer experience pro-code teams wanted, or you got the governance posture the CIO needed. Pick one. Live with the trade.
Code apps in Power Platform end that trade.
The mechanics are straightforward: developers bring TypeScript, React, and their tooling of choice into the platform – but the app they ship still inherits the environment, the DLP policies, the connector governance, the Dataverse security model, the licensing envelope, the solution ALM, and the CoE visibility. The designer is optional. The moat is not.
That’s the architectural read. The strategic read is sharper:
Microsoft is telling you which part of the stack they think the next decade of enterprise value lives in, and it isn’t the editor.
A vendor whose moat was the Canvas designer would be defending the Canvas designer. Microsoft is doing the opposite. They’re widening the front door to let pro-code developers walk in on their own terms, because they’ve correctly identified that the editor is commoditizing and the operating system is not. Agentic coding accelerated that commoditization. Code apps are the response.
For the reader trying to make a buying decision, this resolves the low-code vs. pro-code debate into something simpler:
The pro-code developer gets the dev experience they want. The CIO keeps the governance posture they need. The religious war ends not because one side won, but because the platform team finally drew the line in the right place.
Which sets up the only question that still matters.
The strategic read
If you’re a CIO or enterprise architect listening to the “agentic AI killed low-code” pitch, notice what question it’s quietly asking you to optimize for: how fast can my developers ship v1?
That answer is increasingly yes, very fast. And it’s increasingly the wrong question.
The right question, the one that predicts your cost, risk, and audit posture five years from now, is this:
Not “how fast can we ship v1?” but “who owns v1,000?”
Because v1,000 is what an enterprise application estate actually looks like after a decade of agentic coding lowering the bar for what gets built. It’s the field service app from 2021 still running on iPads. It’s the analyst’s “marketing automation” experiment that touched customer PII. It’s the 200 apps you inherited in last year’s acquisition. It’s the CISO query that has to return an answer by Friday. None of those are v1 problems. All of them are v1,000 problems.
So when you hear the pitch, ask the question back: who owns v1,000 in the world you’re describing?
- If the answer is “the platform,” you’re describing Power Platform. The moat; identity, DLP, ALM, CoE, licensing, lifecycle, comes with the license. It’s already built, already staffed, and already maintained by someone whose full-time job is keeping it current.
- If the answer is “us,” you’re describing a platform engineering team you’re about to staff and fund. That team will spend the next several years rebuilding most of what Power Platform gives you on Day 1, because that’s what platform engineering teams always do when the policy layer is missing from the stack. And as the TCO numbers above make clear, that’s a seven-figure annual commitment before a single line of feature code gets written.
The moat isn’t the designer. It never was. The moat is everything that surrounds the app and that part of the stack is still expensive, still hard, and still very much worth licensing.
The pitch is selling you v1. The job is owning v1,000. Pick the platform that knows the difference.
