Six ways to build a Power App in 2026

The way you build a Power App is more than just a taste decision. It’s a decision for which responsibility you want to own. Sounds dramatic until you look at the menu we have in 2026:

Model-driven forms and views. Canvas apps. Custom pages. Generative pages. Code apps. Vibe apps.

Six ways to get something on screen.

Six very different answers to the same question:

What does the platform own, and what do you now own yourself?

The app can appear fast now. Sometimes very fast. A prompt becomes a plan, a table, a screen, a React component, or even a full app before your coffee has cooled down.

Lovely, isn’t it?

But speed changes the order of the work. It does not remove the work.

AI accelerates your job. It does not shrink your responsibility.

The app is not the decision

When we talk about Power Apps, we often jump straight to the build surface.

“Should this be canvas?”

“Could this be a model-driven app?”

“Can we generate this page?”

“Should we try Code Apps?”

Those are useful questions, but they are second-order questions.

The first question is this:

Where should the responsibility boundary sit?

A standard model-driven form hands more of the user experience to the platform. A Code App hands more of it to you. A generative page gives you speed, but you still have to check the generated code, the data scope, and the role behaviour. A Vibe app gives you the easiest start, but it is still a preview experience and needs review, testing, and compliance validation before broader use.

So the choice is not “which one looks coolest?”

The choice is “which one gives me the right amount of control for the risk I am taking on?”

The six build options

Build option	Use it when	The platform carries	You still own
Model-driven forms and views	The process is Dataverse-first, structured, and record-heavy.	A consistent app shell, forms, views, navigation, responsive behaviour, Dataverse security model, and solution packaging.	The data model, relationships, security roles, forms, views, business rules, and who can do what.
Canvas app	The user experience needs to be more tailored, especially for task-based work or mobile scenarios.	Power Apps Studio, the canvas runtime, connectors, sharing, and optional offline support for mobile apps.	Screen design, Power Fx, delegation, data loading, connector choices, performance, sharing, and testing on the devices people actually use.
Custom page	You need a richer page, dialog, or pane inside a model-driven app, but still want low-code authoring.	The model-driven app host, solution support, Power Apps Studio authoring, connectors, and the model-driven context.	The custom page logic, connector consent behavior, responsive design, state handling, and known limitations such as online-only mobile use.
Generative page	You need a React-based page inside a model-driven app and want AI to create the first version.	The model-driven app host, Dataverse-backed page experience, generated React code, and solution-aware deployment path.	The prompt, the data tables you expose, role-specific data scope, generated query review, code review, re-generation discipline, and ALM.
Code App	You need a standalone web app with React/Vue-style control, but still want it hosted and governed in Power Platform.	Power Apps hosting, Microsoft Entra authentication, connector access, app sharing limits, Conditional Access, DLP policy enforcement at launch, and health metrics.	Frontend architecture, service layer, data exposure, no embedded secrets, connection references, CI/CD, tests, and production support.
Vibe App	You want to explore an idea quickly and generate the plan, data model, and app together.	An AI-native build experience, planning, data model generation, app generation, and a fast path from idea to prototype.	Validation, testing, governance, data and compliance checks, refinement, and the decision to rebuild or promote through a more controlled path.

This is why I do not like the question “which Power Apps type is best?”

Best for what?

Best for a departmental checklist? Canvas might be perfect.

Best for a structured case process with strict data rules? Start with model-driven.

Best for a custom matrix inside a model-driven app? Custom page or PCF (Power Apps component framework) might make more sense.

Best for a fast generated page over Dataverse? Generative page.

Best for a proper standalone web app where your team can own the code? Code App.

Best for exploring whether the idea should exist at all? Vibe.

The right answer depends less on the screen and more on the burden you are willing to carry after the screen exists.

Start with the contract

The worst way to use AI-assisted app development is to start with the prompt.

“Create an app for event feedback.”

“Create a page for time entry.”

“Create a dashboard for project managers.”

That feels efficient. It is also where the trouble starts.

A vague prompt lets the AI decide things it should never decide alone.

Which columns should be shown?

Which records should this role see?

Should the write happen once per user, once per day, or as many times as the button is clicked?

What should be logged?

What happens if the same record already exists?

Those are not styling details. Those are governance decisions.

Before the first prompt, write the app contract:

Users and roles
- Who uses this app?
- Which roles are different enough to need different data scopes or screens?

Data scope
- Which tables are used?
- Which columns are needed on each screen?
- Which records should each role see?
- What filters, sort order, paging, and limits are required?

Write path
- Who can create, update, approve, delete, or submit?
- What validation must happen before save?
- What duplicates must be impossible?
- Which ownership or user-context checks are required?

Operations
- Who owns the app after launch?
- How does it move from Dev to Test to Prod?
- What tests must pass before release?
- What support evidence should exist when something breaks?

That contract can be one page. It does not need to be fancy.

But it has to exist before generation.

If you skip it, the AI fills the gaps for you. Not maliciously. Not stupidly. Just literally. It builds from what you gave it.

A thin prompt creates a thin architecture.

The platform can enforce security only after you design it

Model-driven apps are strong because so much structure comes from Dataverse.

The app is built around tables, forms, views, charts, dashboards, relationships, security roles, and solutions. Model-driven apps are suited to data-dense, process-driven work where the data model comes first.

That is the gift.

It is also the trap.

People say “Dataverse security handles this” as if the sentence configures the security role by itself.

It does not.

Dataverse gives you the security model. You still have to design the access.

If the generated page shows every accessible column, the answer is not to just hide the field in the component and hope for the best. The answer is to fix the access at the data layer. Use the role model. Use field-level security for sensitive columns. Use views and query scope deliberately.

The same applies to row access.

If users should only see data that they own, that rule belongs in the data access pattern. Not in a visual filter that makes the page look correct while the app still fetches too much.

Looks secure is not the same as is secure.

AI-generated apps usually miss the boring parts

AI is getting very good at the visible part of the app.

Cards. Tables. Filters. Forms. Layout. Navigation.

That is helpful. It also makes the first version feel more finished than it is.

The boring parts are where the app becomes real software:

Data scope
Does the query use only the columns it needs? Is it filtered server-side? Does it page results? Does it avoid fetching the whole table because the demo table had five rows?
Write-path validation
Does the save action check for duplicates? Does it check ownership? Does it know the current user? Does it handle errors when Dataverse rejects the write?
Role behaviour
Do different roles see different records, actions, or controls? Has anyone tested this as a non-admin user?
ALM (application lifecycle management)
Is this in a solution? Are environment variables and connection references used where they should be? Is production reached through a managed deployment path, not a direct push?
Support evidence
When someone says “it failed,” can you find the app, environment, version, flow run, connector, user role, or changed record?

Do not treat the output as magic.

Treat it as a first draft from someone very fast, very confident, and completely new to your organization.

Review it. Test it. Improve it. Then merge it deliberately.

Code Apps raise the ceiling and the bar

Code Apps are the most interesting new option for many fusion teams.

You can build a custom web app in a code-first IDE, use frameworks like React or Vue, develop locally, and still run the app in Power Platform. The official Code Apps overview lists Microsoft Entra authentication and authorization, access to Power Platform data sources and connectors, Power Platform hosting, Managed Platform policy support, and simplified ALM as key features.

That combination matters.

It means you are not leaving Power Platform just because you need more code.

But it also means you do not get to act like this is basically a canvas app with nicer UI.

A Code App is code.

So you need code habits.

No embedded secrets. No hardcoded sensitive datasets. No “the endpoint is obscure so we are fine.” Compiled Code App assets are served from a publicly accessible endpoint and IP-based restrictions are not supported today; access control needs to come through Microsoft Entra ID and Conditional Access.

That is not scary.

It is just a different boundary.

The platform gives you hosting, identity, connector access, sharing limits, DLP (data loss prevention) policy checks, Conditional Access support, and health metrics.

You own the architecture inside that boundary.

Vibe is a prototype, not a shortcut to production

I like Vibe.

It lowers the barrier. You can start from natural language, let the system propose a plan, generate data and an app, and see whether the idea has legs to stand on.

That is valuable.

But Vibe is still preview. And preview features are not meant for production use and might have restricted functionality. Makers are ultimately responsible for validating that apps meet functional, security, and compliance requirements.

So my rule is simple:

Use Vibe to explore the idea.

Do not use Vibe to skip the acceptance bar.

For a low-risk internal prototype, it may be enough to keep iterating there for a while.

For a business-critical process, the Vibe output should trigger the architecture conversation, not end it.

What did it create?
Which tables?
Which users?
Which connectors?
Which data?
Which owner?
Which release path?

If nobody can answer those questions, you do not have an app yet.

You have a generated first draft.

Testing is part of the build now

The biggest mindset shift for me is that testing can no longer be a polite afterthought.

Especially not when AI can produce more app surface faster than humans can manually click through.

Microsoft deprecated Power Apps Test Engine effective April 2026 and points teams toward the Power Platform Playwright samples as the Playwright-native alternative for Power Platform and Dynamics 365 testing.

That matters for this whole conversation.

If AI helps you generate the app, automation has to help you check the app.

At minimum, every AI-assisted app should have a small release gate:

Before sharing wider:
- Test as the real roles, not only as a maker or admin.
- Check that each role sees only the records and columns it should.
- Check one happy-path write.
- Check one duplicate or blocked write.
- Check one empty/error state.
- Check the app after deployment, not only in local preview.
- Keep the test evidence with the release.

This does not have to start as a huge testing program.

Start with five prompts or five user stories that must keep working.

Then automate the boring click-throughs.

Power Platform apps are production software. They deserve production checks.

The question before the first prompt

Before you generate anything, ask this:

What am I asking the platform to own, and what am I accepting responsibility for?

For a model-driven form, you accept responsibility for the data model and security configuration.

For a canvas app, you accept responsibility for the screen logic, delegation, connector behaviour, and performance.

For a custom page, you accept responsibility for the embedded page logic and its limits inside the model-driven host.

For a generative page, you accept responsibility for reviewing generated React, data scope, role behaviour, and re-generation discipline.

For a Code App, you accept responsibility for code ownership, service design, secrets, tests, and CI/CD (continuous integration and delivery).

For a Vibe App, you accept responsibility for treating the result as a draft until it passes the same functional, security, and governance checks as anything else.

That is the boundary.

And once you see the boundary, the build choice gets much easier.

Do this this week

Pick one app idea you are about to build or one AI-generated prototype someone already showed you.

Do not start by judging the UI.

Write the contract:

Who uses it?
What data can each role read?
What can each role write?
What must be checked before save?
How does it move to production?
What test proves it still works?

Then choose the build option.

Vibe-code the prototype if that helps.

Architect the production app.

Trust is earned after the generated part is over.