Power Apps vs Custom Development: When Low-Code Is Right, and When It Quietly Becomes the Expensive Option

What This Decision Actually Turns On

Most Power Apps versus custom development comparisons argue about features. That is the wrong argument. Power Apps can build almost anything you can describe in a meeting. The question is what it costs to run five years from now, and who is allowed to touch it.

Three things decide it, and none are on a feature list:

• The licence model. Power Apps is priced per user, per month, forever. A custom build is priced once, then maintained. • The ceilings. Request limits, delegation limits and storage entitlements are documented and non-negotiable. • The blast radius. Who owns the app when the person who built it leaves.

Be honest about which one is actually biting you. Teams often say "Power Apps is too slow" when the real problem is a non-delegable query over 40,000 rows. That is a data model problem, not a platform problem, and a custom rebuild will not fix a bad data model.

Everything below is checked against Microsoft's own documentation as of September 2026. Licensing changes often. Verify against your own agreement and the current Power Platform Licensing Guide before you commit budget.

Where Power Apps Genuinely Wins

Power Apps wins on time-to-first-release, and the gap is large. A working internal app over SharePoint or Dataverse can be in users' hands in days. A custom .NET equivalent — authentication, hosting, CI/CD, a data layer, an admin UI — is weeks before anyone sees a screen.

It wins decisively in these cases:

• Internal apps with fewer than roughly 100 users, where per-user licensing stays small. • Forms-over-data: inspections, approvals, requests, asset registers, site checklists. • Anything replacing an Excel workbook that is emailed around. The bar is low and Power Apps clears it on day one. • Apps with a short or uncertain life. If you might kill it in eighteen months, do not build a custom platform for it. • Teams already paying for Microsoft 365, with no in-house developers.

It also wins on something people undervalue: the identity, audit and admin layer is already built. Entra ID sign-in, conditional access, DLP policies and tenant-level audit come free. In a custom build, you write and maintain all of that.

If your scenario is on this list, a custom build is usually the more expensive answer, not the more professional one.

What Actually Triggers a Premium Licence

This is where most cost surprises come from. Microsoft lists the triggers explicitly: premium connectors, Dataverse tables, on-premises data gateways and custom APIs all require premium entitlements. Custom connectors are treated as premium. Model-driven apps use Dataverse and are premium by default.

The practical consequence: the moment your app touches SQL Server, an on-premise system through a gateway, or any API you wrote yourself, every user of that app needs a premium licence. Not the maker. Every user.

Two 2026 changes matter more than the price list:

• The Power Apps per app SKU stopped being available to new customers through some channels effective 2 January 2026. The cheap per-app escape hatch is narrowing.

• Microsoft has stated that from February 2027, licensing requirements applied leniently until now will be enforced. That covers apps in managed environments, model-driven apps, and apps used outside a Dynamics 365 environment context.

Read that second point carefully. In a managed environment, the requirement applies to active usage in the environment, not to the app type — so users running standard, non-premium apps need a qualifying licence too. If your governance strategy is "turn on Managed Environments everywhere," price it before February 2027, not after.

The Ceilings Nobody Mentions in the Demo

These are documented and specific. Know them before you design.

• Delegation. When a query cannot be delegated to the data source, Power Apps pulls the first 500 rows by default, up to a configurable maximum of 2,000, and filters locally. It does not error. It silently returns incomplete data. This is the single most common cause of an app that "worked in testing."

• Daily request limits. Power Apps Premium and per-user licences get 40,000 Power Platform requests per user per 24 hours. Per app, pay-as-you-go, Microsoft 365-seeded licences and Dynamics 365 Team Member get 6,000.

• The service-account ceiling. Non-licensed identities — application users, service principals, integration accounts — draw from a pooled tenant limit. For Power Apps that pool is 25,000 requests per 24 hours, with no per-licence accrual. If your architecture pushes integration traffic through a service principal, this is a hard, low ceiling.

• Dataverse service protection. Per user, per web server, in a five-minute sliding window: 6,000 requests, 1,200 seconds of combined execution time, and 52 concurrent requests.

• Offline. Canvas offline works with Dataverse only. SharePoint and other non-Dataverse connectors are not supported offline, and Power Automate flows do not run offline. Background sync only runs with the app in the foreground and the screen unlocked.

Do the Licence Arithmetic Before You Argue About Code

Power Apps Premium lists at $20 per user per month, paid yearly. There is an enterprise tier at $12 per user per month with a 2,000-seat minimum. Regional list prices in India and the Gulf differ; check your own agreement.

Run it out. At list price:

• 100 users: $24,000 a year. $72,000 over three years. • 250 users: $60,000 a year. $180,000 over three years. • 500 users: $120,000 a year. $360,000 over three years, $600,000 over five.

Then add storage. Additional Dataverse database capacity lists at $40 per GB per month, paid yearly. That is $480 per GB per year. A hundred gigabytes above entitlement is $48,000 a year — often more than the app cost to build. Each Premium licence accrues 250 MB of database plus 2 GB of file capacity. That accrual is small. Transactional apps outgrow it.

One more trap: unused capacity cannot flow upward. Spare database capacity can offset log and file overage, but spare file capacity cannot offset a database overage. Every environment consumes 1 GB whether or not it has a database.

Third-party analyses put the three-year crossover near 100 users. Treat that as a rough marker, not a rule — it depends entirely on your build cost. Get a real quote, put it against the numbers above, and compare like for like.

Where Governance and ALM Get Hard

Power Apps is easy to start and hard to run at scale. The difficulty is organisational before it is technical.

The pattern is consistent. One app becomes forty. Nobody knows which are in use. Several were built by people who have left. Two connect to production SQL through a personal account. None have a test environment.

Fixing this is real work:

• Environment strategy. Separate dev, test and production environments, with the default environment locked down and its creation restricted. • DLP policies. Connectors get classified Business, Non-Business or Blocked, tenant-wide. This is the main control stopping business data reaching unsanctioned destinations. • Managed Environments and Power Platform Pipelines, so production deployments go through a pipeline instead of manual solution imports. Note the licensing consequence above. • Solution-aware development, managed solutions, and a service principal doing the deploying — not a named person.

Custom .NET is not automatically better here. It is just more familiar. Git, pull requests, automated tests and Azure DevOps are a well-worn path, and a .NET developer joining your team already knows it. Power Platform ALM is mature now, but the skills are rarer and the tooling has changed more than once.

The honest framing: both stacks need governance. Power Apps lets you skip it for longer, which is the problem.

When a Custom Build Is Over-Engineering

Plenty of custom builds should never have happened. The tells are recognisable.

• The app is a form, a table and an approval. You are writing a React front-end and a REST API for what a canvas app does in a week. • Fewer than 50 users, and no plan to grow. Licensing will never reach the cost of maintaining your own deployment pipeline. • The requirement is "we need control" with nothing specific behind it. Control of what, exactly? If nobody can answer, it is preference, not requirement. • You are rebuilding identity, role management, audit logging and an admin console. Dataverse gives you all four. • The driver is that a developer finds low-code boring. This is a real reason people give. It is not a business case.

There is also a hidden cost people ignore. A custom app needs someone to patch it. Framework upgrades, dependency vulnerabilities, certificate rotations, hosting changes. Five years of that is not free, and it does not appear in the build quote. A Power Apps solution inherits Microsoft's patching by default.

If the app is small, internal and boring, build it low-code. Spend your engineering budget where it changes something.

The Hybrid Pattern: Power Apps Over Your Own APIs

There is a third option, and it is underused. Keep Power Apps as the front-end. Move the hard parts behind a custom API.

The shape is straightforward. Business logic, heavy queries, complex integrations and anything performance-sensitive live in a .NET API on Azure. Power Apps calls it through a custom connector. Dataverse holds what belongs in Dataverse; your own database holds what does not.

What this buys you:

• Delegation stops being a constraint. Your API returns a filtered, paged result. Power Apps just renders it. • Integration complexity moves somewhere it can be tested, versioned and monitored properly. • You keep the fast UI iteration and the free identity and audit layer. • Migration off Power Apps later is a front-end rewrite, not a rebuild. The logic is already portable.

The costs are real. Custom connectors count as premium, so every user needs a premium licence — you do not escape licensing this way. You now maintain an API, its hosting and its release pipeline. And you have two stacks, which means two sets of skills.

Use it when the UI is simple but the logic is not, or when you expect the app to outlive the platform decision. Do not use it to avoid a decision you should just make.

The Triggers That Mean You Have Outgrown Power Apps

Concrete signals. Any two together are worth a serious review.

• More than 200–300 users on premium licences, with headcount growing. Run the five-year number before renewal. • Any external or customer-facing audience. Per-user licensing does not fit anonymous users. • Dataverse database use climbing past your entitlement toward 100 GB. At $40 per GB per month, storage starts rivalling development cost. • Users or service accounts approaching 40,000 requests per 24 hours — or integration traffic pushing against the 25,000-request non-licensed tenant pool. • Repeated Dataverse service-protection errors: the 6,000-request, 1,200-second or 52-concurrent limits in a five-minute window. • Delegation warnings you have "solved" by raising the row limit to 2,000. That is a countdown, not a fix. • Offline is a genuine requirement and your data is not in Dataverse, or you need flows to run offline. • More than three or four non-trivial integrations, each with its own retry, error-handling and reconciliation needs. • A regulator, auditor or client contract that requires control over hosting region, release process or source code that the platform cannot give you.

If none of these apply, stay. If several do, the cheap option stopped being cheap a while ago.

A note on where we stand: we build both sides of this — Power Platform and custom .NET. That is deliberate. Most firms writing about this decision sell only one answer. We would rather size the problem honestly than sell the bigger project.