Power Apps is one of those tools that generates strong opinions on both sides. Its advocates will tell you it cuts development time by 70%, empowers business users to build their own solutions, and eliminates the need for developers on internal tooling. Its critics will tell you it’s slow, inflexible, expensive at scale, and produces apps that look like they were designed in 2011.
Both groups are partially right. The honest answer is more nuanced — and in 2026, the landscape has shifted enough that the question “should we use Power Apps?” deserves a harder look than it used to.
Two different tools under one name Link to heading
Before anything else, it’s worth clarifying that “Power Apps” actually means two fairly different products:
Canvas Apps give you a blank screen and a drag-and-drop editor. You design every screen from scratch, control exactly where each element sits, and connect to data sources using a formula language called Power Fx. Think of it as Excel-meets-UI-builder.
Model-Driven Apps start from the data model, not the UI. You define your Dataverse tables, relationships, and business rules — and the app generates its own interface based on that structure. You get forms, views, dashboards, and navigation mostly for free, but you give up pixel-level control over how things look.
These are not interchangeable. Choosing the wrong type for your use case is one of the most common mistakes in Power Apps projects.
Canvas Apps: where they shine Link to heading
Canvas Apps are at their best when you need something task-specific, role-focused, and visually customized.
A field technician app that shows the day’s work orders, allows photo uploads, and syncs to SharePoint in the background? Perfect canvas app. An approval form embedded in Teams that routes a request through three departments? Canvas app. A data entry interface that replaces a complicated Excel spreadsheet used by 15 people? Canvas app.
The strengths are real:
- Speed to first working version. A competent maker can have something functional in a day or two that would take a developer a week to build from scratch.
- Microsoft 365 integration. The connectors for SharePoint, Teams, Dataverse, Outlook, and OneDrive are deep and well-maintained. If your data lives in Microsoft’s ecosystem, canvas apps are an obvious fit.
- No deployment complexity. You publish, share a link, and it runs in a browser or on mobile. No CI/CD pipelines, no server maintenance.
- Accessible to non-developers. With sufficient Power Fx knowledge, a capable business analyst can build and maintain these apps without developer intervention.
Canvas Apps: where they break down Link to heading
The limitations are just as real, and they tend to bite hardest when the app grows beyond its original scope.
The 500/2,000 record ceiling. By default, canvas apps retrieve 500 records from a data source. This can be extended to 2,000, but beyond that you’re fighting the platform. Delegation — the mechanism that offloads filtering to the server — only works with a subset of connectors and functions. Build an app against a SharePoint list thinking you’ll have 200 items, and three years later when you have 8,000, you have a problem.
One developer at a time. Canvas apps have no real version control or collaborative editing. Two people cannot work on the same app simultaneously without overwriting each other’s changes. For anything beyond a solo project, this is a significant workflow constraint. The integration with Azure DevOps exists but is cumbersome compared to a standard Git workflow.
No JavaScript. Canvas apps are Power Fx only. Power Fx is capable but not Turing-complete in the traditional sense, and for complex conditional logic, string manipulation, or anything algorithmically non-trivial, it gets verbose and hard to maintain quickly. You can use PCF (Power Apps Component Framework) to write custom TypeScript components, but that requires a developer anyway — at which point you’ve largely negated the “no-code” benefit.
Performance on large or complex apps. Canvas apps that grow to 20+ screens with many data connections and complex formulas slow down noticeably. The loading time for a large app can frustrate users accustomed to native applications. Performance tuning in canvas apps is a real discipline with its own best practices — it doesn’t happen automatically.
The “premium connector” tax. Many of the most useful integrations — Dataverse, SQL Server (on-premises), SAP, custom APIs — require a Power Apps Premium license at ~$20/user/month. The base Microsoft 365 license only covers a limited set of “standard” connectors. For small teams, this adds up fast.
External sharing is not straightforward. Power Apps are fundamentally designed for internal organizational use. Sharing an app with someone outside your Microsoft tenant requires guest accounts or specific licensing arrangements. Building a customer-facing application with Power Apps is technically possible but architecturally awkward.
Model-Driven Apps: the structured alternative Link to heading
Model-driven apps solve a different set of problems. If your use case looks like a CRM, a case management system, a project tracker with complex relationships, or any scenario where the data structure IS the application — model-driven is the right choice.
The strengths:
- Business logic at the data layer. Validation rules, calculated fields, business rules, and workflows are defined in Dataverse and apply everywhere the data is used — not just in one app’s formulas.
- Role-based security out of the box. Dataverse has a sophisticated security model (business units, security roles, field-level security) that canvas apps simply don’t match.
- Automatic UI generation. As your data model evolves, the app adapts. You’re not manually updating screens when you add a new column.
- Scales to enterprise complexity. Dynamics 365 is itself a model-driven app. The underlying platform is production-tested at large scale.
The limitations:
- You don’t control the look. Model-driven apps have a characteristic Microsoft aesthetic that you can influence but not fully override. If branding and UX customization matter to stakeholders, this will be a friction point.
- Dataverse is mandatory — and not free. Model-driven apps require Dataverse as the data source, which requires Premium licensing. There is no model-driven app against a SharePoint list.
- Steeper learning curve. Understanding Dataverse table design, relationships, security roles, and business rules requires real investment. This isn’t a tool a business analyst picks up in an afternoon.
- Can feel over-engineered for simple use cases. If you need a form that sends an email, a model-driven app is significant overkill.
The honest comparison: Power Apps vs. custom development Link to heading
This is where the conversation gets interesting — and where the answer has genuinely changed over the past two years.
The traditional comparison looked like this:
| Power Apps | Custom App | |
|---|---|---|
| Time to first version | Days | Weeks/months |
| Total cost (simple app) | Lower | Higher |
| Flexibility | Limited | Unlimited |
| Maintenance | Managed by Microsoft | Your responsibility |
| Developer required | No (ideally) | Yes |
| Scalability | Platform limits | Your architecture |
| UI quality ceiling | Moderate | Unlimited |
This table still holds — but the “weeks/months” and “developer required” cells for custom apps have been dramatically compressed by AI-assisted development.
Vibe coding changes the calculation Link to heading
In 2025, a new term entered the developer vocabulary: vibe coding — the practice of building software by describing what you want to an AI system and iterating on the result, with the AI writing most or all of the actual code.
Tools like Cursor, GitHub Copilot, Claude, and v0 have reached a point where a developer — or sometimes even a technically-minded non-developer — can produce a working, reasonably well-structured web application in hours rather than days. A React frontend with a REST API, deployed to Vercel or Azure Static Web Apps, with a Postgres database — what used to require a sprint can now be drafted in an afternoon.
This is exactly the argument Zack Liscio made when he documented his company’s migration away from Retool (a low-code internal tool platform) to AI-built custom apps. His conclusion was blunt: “It is now often faster, cheaper, and easier to ship the kind of tools you might have built with low-code tools outside these platforms.” His team completed the migration in a couple of sprints, ended up with a better UI, better codebase integration, and eliminated an entire platform’s worth of licensing and maintenance overhead.
The same logic applies to Power Apps — at least partially. For a developer who’s comfortable with AI-assisted coding, building a custom web app that does what a canvas app would do is no longer the multi-week investment it once was.
A critical, use-case-by-use-case assessment Link to heading
So when should you actually use Power Apps, and when should you reach for something else?
Use Power Apps when: Link to heading
Your organization is heavily invested in Microsoft 365 and the process is internal. If the data is already in SharePoint, Teams, and Dataverse, and the users are all internal employees with M365 licenses, Power Apps provides connectors and governance that would take real effort to replicate from scratch.
The maker is a business analyst, not a developer. Power Apps remains the most credible option for empowering non-developers to build and maintain their own tools. The governance model (environments, data loss prevention policies, admin controls) is also mature. This is a genuine advantage that AI coding tools don’t yet fully replace — a business analyst can’t realistically maintain a React codebase, even with AI assistance.
You need something working in 48 hours. For a prototype, an MVP, an internal form that needs to replace a spreadsheet today — the speed advantage is real.
Model-driven for structured, multi-user CRM-like systems. If you’re tracking entities with relationships, need security roles, and want the app to grow with the data model — model-driven on Dataverse is genuinely hard to beat for the Microsoft ecosystem.
Skip Power Apps when: Link to heading
You need to share the app with customers or external users at scale. Licensing, authentication complexity, and UI limitations make Power Apps a poor choice for public-facing applications. Build something real.
Performance and UX quality are non-negotiable. Power Apps apps have a recognizable “platform look” and are noticeably slower than native applications. If users are going to spend 6+ hours a day in the app, this matters.
Your data exceeds a few thousand records and complex querying is required. The delegation limitations aren’t just an inconvenience — they’re an architectural constraint that can require expensive workarounds.
The team is developer-led and comfortable with AI coding tools. In this case, the time savings of Power Apps largely disappear, while the flexibility constraints remain. A developer building an internal tool with Cursor and a modern stack will produce a better result faster, own the code, and not pay per-user licensing.
The app will need deep customization or integration with non-Microsoft systems. Every custom requirement in Power Apps adds friction — custom connectors, PCF components, workarounds for missing features. The further you get from the platform’s happy path, the slower and more expensive development becomes.
The verdict Link to heading
Power Apps is not dying, and the “RIP low-code” narrative is somewhat overstated — particularly for organizations where non-developers are building and maintaining tools within a governed Microsoft environment. That use case is real and Power Apps serves it well.
But the honest answer is that Power Apps has always been a compromise, and the terms of that compromise have shifted. You accepted UI limitations, platform constraints, and per-user licensing costs in exchange for speed and accessibility. In 2023, that trade-off was often worth it. In 2026, with AI coding tools dramatically lowering the bar for custom development, the cases where it’s worth it have narrowed.
If you’re a Power Platform developer, none of this means your skills are obsolete. Model-driven apps, Dataverse architecture, Power Automate, and Copilot Studio are all growing in capability and relevance. But the era of building canvas apps because “it’s too expensive to get a developer to do it properly” is over. Now you have to make the case on its own merits — and sometimes the honest answer is to vibe-code the custom app instead.
Sources: Power Apps system requirements and limits – Microsoft Learn · Canvas vs. Model-Driven Apps – Hitachi Solutions · RIP Low-Code 2014–2025 – Zack Liscio