Power Apps vs custom development

What it does

The build-versus-configure decision, applied to business applications. On one side, Power Apps: platform-hosted, connector-fed, governed by DLP and environment policy, maintainable by people who aren't developers. On the other, a bespoke application your client or an SI writes, hosts and owns end to end.

Key facts

Microsoft's own framing is fusion development — pro developers and makers on the same workload — rather than a binary. The platform is positioned as a tool in the toolset, with pro devs handling specialised problems and makers handling the rest.
Power Apps code apps went generally available in February 2026 and sit deliberately in between: developers build a web app in their own IDE and framework, and it runs on Power Platform with connector access, DLP enforcement at launch, sharing limits, app quarantine and Conditional Access on the individual app.
Code apps still carry documented gaps — no Power Platform Git integration, no support in the Power Apps mobile app or Power Apps for Windows, no PowerBIIntegration yet, and service principals can't create or own one. Check the current list rather than this one.
The extensibility ladder inside the platform is real: Power Fx, then component libraries, then PCF code components, then plug-ins and custom APIs on Dataverse, then code apps. Most "we need custom development" conversations are answered somewhere on that ladder.
Building a canvas app requires no licence. Building a model-driven app does. Running anything premium requires an end-user entitlement, and that's the cost line that scales with the user count rather than with the build.
Power Platform gives you tenant-level controls a bespoke app has to reimplement: data policies, cross-tenant isolation, environment-level security, admin reporting, and a licence model that already exists in the client's agreement.

When to use / skip

Low-code is the right answer when the application is a business process over business data, when the user count is bounded, when the requirement will change every quarter, and when the client wants to change it without raising a change request. That covers a very large share of internal line-of-business work, and the reason it's the right answer isn't cost — it's change velocity and the fact that the platform absorbs the plumbing.

It becomes a trap in four recognisable situations. When the app is external-facing at consumer scale, because the licence model and the platform aren't shaped for anonymous volume. When throughput, latency or transaction volume is the requirement rather than a side effect. When the UI is the product — a genuinely novel interaction that you'd end up building entirely in PCF anyway, at which point you've written a web app with extra steps. And when the client has no maker capability and no intention of building one, so the "anyone can maintain it" argument, which is most of the value, never lands.

The failure mode you'll meet is the third one arriving late. An app starts as a form over Dataverse, accretes eleven code components and a plug-in per table, and now needs a developer for every change while still carrying every low-code constraint. Watch the ratio of custom code to configuration over time. When it crosses roughly half, the platform has stopped paying for itself and someone should say so out loud.

Configuration decisions

Where on the ladder this workload sits — configuration, configuration plus a component or two, or code apps — and what would have to be true to move it a rung.
Whether the client is buying a solution or a capability. If they want to own change, that's an argument for low-code that survives a worse feature fit.
What the exit criteria are. Write down, at design time, the conditions under which you'd rebuild this outside the platform: user count, transaction volume, external audience, latency. It's much easier to agree those in a workshop than during an incident.
Who owns the pipeline. Code apps don't get Power Platform Git integration, so that's your build to design and the client's to run.
Whether the deciding factor is genuinely technical or actually political — developers wanting their stack, IT wanting governance. Code apps exist largely to settle that argument, and naming it usually shortens it.

Gotchas

TCO comparisons almost always price the build and skip the operate. Bespoke means hosting, patching, dependency upgrades, penetration testing, an on-call rota and a hiring risk. Put those lines on the same page as the licence cost or the comparison is meaningless.
Per-user premium licensing scales with adoption, which is the one variable everyone is optimistic about. Model it at the number the client hopes for, not the number in the pilot.
"We'll build it properly in .NET" often means a small team who will move on in eighteen months. Ask who maintains it in year three and watch the room.
Platform limits are documented and enforced. Bespoke limits are undocumented and discovered. Neither of those is obviously better, but only one of them is knowable at design time.
A code app is still a licensed premium app for every end user. It doesn't get you out of the entitlement conversation, only out of the low-code UI constraint.

Consultant notes

Frame it as a portfolio rule, not a per-app fight. Agree with the client where the line sits — user count, data sensitivity, external exposure, integration volume — and apply it consistently. Otherwise every project relitigates it and the loudest architect wins.
Fusion is the honest answer more often than either extreme. Makers own the screens and the process, developers own the components, the integrations and the pipeline. Say that at the start rather than discovering it at the third sprint review.
Never sell low-code as cheaper. Sell it as faster to change and cheaper to own by people already on the payroll. The first claim is arguable; the second is the one that's actually true.
When you inherit an over-customised low-code app, resist the instinct to rewrite. Measure the custom-to-configured ratio, show it to the sponsor, and let the number make the argument.

Worth rechecking each wave — the code apps limitations list is the thing most likely to move this decision