Canvas, model-driven, or a code app. Pick by the shape of your data.

Pick canvas when the interface matters more than the data structure and one person will own the build. Pick model-driven when your data already has, or could have, a clean relational shape in Dataverse, because the platform builds most of the app for you once that structure exists. Pick a code app when neither fits, usually because the logic is complex, and you have a developer who'll own a real repository for it going forward. Most wrong picks get made on taste.

If the data is still in SQL Server, Access or a spreadsheet, the Power Platform migration hub covers getting it into Dataverse first.

One more shape that is none of the three: a site for people outside the firm, which is Power Pages, priced per site in what Power Pages costs a small NZ business.

Before choosing an app type, check whether a plain Microsoft List or a Form does the job: Microsoft Lists, a Power App, or a Form.

Canvas: pixel control, fast to start, painful to maintain at scale

A canvas app starts as a blank screen. You place text boxes, galleries and buttons where you want them, wire each one up with a formula in Power Fx, and connect to almost any data source, Dataverse, SharePoint, SQL, an API, a spreadsheet. Nothing about the layout is generated for you, which is exactly the point: you get pixel-level control over what the user sees and in what order.

That makes canvas the right call when the interface is doing real work, a field crew logging a job with photos and location, a form that changes shape depending on an earlier answer, a dashboard built around how one team thinks about its day. It's also the fastest of the three to get in front of a user. A working first screen can exist within a couple of hours.

The cost shows up later. Every screen's logic lives in its own formulas, and there's no data model forcing consistency between them. As an app grows past a handful of screens, keeping validation, security and business rules aligned across all of them becomes a manual job, not something the platform does for you. The person who built it usually understands why each formula is the way it is. The next person often doesn't, and Power Fx isn't self-documenting. Rebuilding a sprawling canvas app's logic from scratch is a common outcome.

Model-driven: the data model builds the app for you, if the data model is right

A model-driven app starts from the other end. You define tables, columns and relationships in Dataverse first, and the app largely builds itself from that: forms, views, navigation, business process flows and security roles all come from the structure you set up, not from screens you draw by hand.

This works well for anything relational: case management, a pipeline of records moving through defined stages, anything where "a job has one customer, several tasks and a status" is a fair description of the business. Because the data model does most of the design work, model-driven apps stay consistent as they grow. Add a field to a table and every form and view that touches it updates without you touching layout at all.

The catch is that the data has to have that shape. If the real information is loose, spread across three systems, or naturally document-like rather than record-like, forcing it into Dataverse tables just to get a model-driven app fights the data instead of using it. And because a model-driven app always runs on Dataverse, every user needs a Power Apps Premium-tier licence, the full plan or the narrower per-app version scoped to this one app, which changes the maths compared with a canvas app running against a spreadsheet. I've broken down what that adds up to across a build's lifetime in what a Power App actually costs in New Zealand. If the plan is to start on the free Dataverse for Teams tier and grow into the full thing later, read where Dataverse for Teams runs out before you commit to it.

Code apps: React on Power Platform, for when neither fits

Power Apps code apps went generally available in February 2026. They're a different way to build: you write the app in real code, using the Vite build tool and, by default, React with TypeScript, though the platform glue sits in the Vite layer, so a team already using Vue or Angular can build one in that instead. No formula language, no drag-and-drop canvas, just software development running inside the Power Platform.

What makes it a Power Platform app rather than a website is what it inherits: Dataverse as a data source, the same data loss prevention policies, the same Entra ID authentication, deployed and governed the way the rest of your platform is. For a business with an IT team already managing Power Platform environments, that's the appeal, a developer gets to write proper code without the app living completely outside the fence.

As at 1 October 2026, code apps are standalone only: Microsoft's documentation lists no support for Power Platform Git integration, none in Power Apps for Windows, and none for SharePoint forms integration, so your team manages its own Git repository the way it would for any other codebase. Licensing follows the same logic as model-driven: because a code app runs through the platform's full governance, end users need a Power Apps Premium licence, pay-as-you-go enabled on the environment, or an app pass, not simply a Standard Microsoft 365 licence. That's the decision-level view. I go through what a code app can and can't do, and where it fits against a plain custom-built web app, in a separate piece on Power Apps code apps.

Canvas	Model-driven	Code app
Built by dragging screens and writing Power Fx formulas	Built by defining a Dataverse data model; forms and views generate from it	Built by writing React or another Vite framework in a real repo
Best fit: task-specific interfaces, mixed or messy data sources	Best fit: relational, process-driven data that already has structure	Best fit: complex logic or interaction a formula language can't express cleanly
Licensed per app, per user, or pay-as-you-go depending on the data source	Always Dataverse, so always a Premium-tier licence per user	Runs through full platform governance, so Premium, pay-as-you-go or an app pass per user
Maintained by whoever built it, reading their own formulas	Maintained mostly by editing the data model; forms follow automatically	Maintained like any codebase: a developer, a repo, a deploy process

The maintenance question nobody asks until year two

Every one of these gets picked in the first meeting by which one is fastest to demo. Canvas wins that argument almost every time, a screen goes up in an afternoon and the room is happy. What doesn't come up in that meeting is who maintains it once the person who built it has moved on, changed roles, or just forgotten which of forty screens holds the formula that calculates the discount.

Model-driven apps age better than their reputation suggests, precisely because there's less to remember. Once the data model is right, most ongoing changes, a new field, a new view, a tweaked business rule, are things a competent admin can make without touching code. The platform did the design work once, at the start, and keeps doing it every time the model changes.

Code apps age the way any other software does. That's a different bill. Instead of a rising pile of undocumented formulas, you're paying for a developer's time whenever something needs to change, and if the repository has no owner, the app stalls the same way any orphaned codebase does. Whichever of the three you pick, none of it survives without a dev-to-production setup behind it, which is why I run every build through the discipline covered in Power Platform ALM when the team is one person. The comparison that decides this is which kind of ongoing cost the business can carry: a formula-reading problem, a data-model problem, or a software-maintenance problem.

One more thing worth knowing before you commit to canvas: two makers can now edit the same canvas app at once, and turning coauthoring on costs you undo, redo and search for the duration. Microsoft doesn't publish a fixed maximum for how many controls a canvas app or screen can hold either, only a warning about what slows Studio down; what is and isn't a documented limit is covered in canvas app limits: controls, screens and data sources.

Whichever build type wins, a site inspection photo or a signed PDF ends up in a Dataverse column sooner or later, and file, image and Notes columns each carry their own separate size ceiling, set out in the file and attachment limits post.

A decision path based on data shape and team skills

Start with the data before the interface.

• Does the information already sit, or could it sit, in clean tables with real relationships between them? Records with a status, an owner, related tasks. If yes, build model-driven. The app follows the data model almost for free, and it stays maintainable by people who aren't developers.
• Is the data spread across other systems, loosely structured, or does the job need a specific, hand-shaped interface, a field form, a device-style layout, a workflow that only makes sense drawn out screen by screen? Build canvas, and go in accepting that someone will own it, document the formulas as you go, and plan to rebuild rather than endlessly extend once it passes a certain size.
• Does the job need custom logic or interaction a formula language handles badly, and is there a developer who will own a repository for it going forward? That's a code app, or possibly a plain custom-built application outside the platform altogether, depending on how much of the Power Platform governance you need.

Sometimes the answer is none of the three. If the whole job is routing a form to the right person and sending an email, a Power Automate flow bolted onto a simple form does it, and no app build is needed. I'd rather say that on the first call than build something that outgrows its own reason for existing.