Power Apps Canvas vs Model-Driven Apps - Which Do You Need
When a team comes to us asking for a Power App, about half the time they've already half-decided which type they want. They've watched a YouTube tutorial. They've seen a colleague's app. They've got an opinion. And about half of those opinions are wrong for what they're actually trying to build.
I run Team 400 and we've delivered Power Apps across mining, healthcare, financial services, retail, and government in Australia. The Canvas vs Model-Driven decision is one of the most consequential choices in a Power Platform project. Get it right and the app slots into your business with minimal pain. Get it wrong and you'll find yourself rebuilding eighteen months later, usually around the time the original developer leaves and nobody can work out why a button stops working when a list has more than 2,000 rows.
This post is for the person who has a real app to build, a budget that matters, and needs to make a confident call. I'll cover what each app type is actually good at, what they're terrible at, what they cost to build and run in Australia in 2026, and the decision framework we use with clients before we write a single line of Power Fx.
What Canvas Apps Actually Are
Canvas Apps give you a blank canvas. You drag controls onto a screen. You write Power Fx formulas to wire them up. You can connect to almost anything that has a connector, and Microsoft has built more than 1,200 of them. Your data can live in SharePoint, SQL Server, Dataverse, Excel on OneDrive, Snowflake, SAP, ServiceNow, or all of the above in the same app.
The UI is pixel-controlled. You decide where every button sits. You can make a Canvas App look like an iOS app, an industrial control panel, or a brochure. This is both the strength and the weakness, which we'll get to.
Canvas Apps run anywhere - phone, tablet, browser, embedded in Teams. You can build for a specific form factor and they'll work well. Try to build one app that works perfectly on phone and desktop and you're in for a fight.
What Model-Driven Apps Actually Are
Model-Driven Apps are the opposite philosophy. You don't design screens. You design data. You build entities (tables) in Dataverse, define relationships, write business rules, set up forms and views, and Microsoft generates the UI. The result looks like Dynamics 365, because under the hood it's the same engine.
Everything sits on Dataverse. You can't connect a Model-Driven App to SharePoint as its primary data source. You can't connect it to your SAP system directly. The data has to live in Dataverse, or be brought into Dataverse via Data Factory, dual-write, or virtual tables.
The UI is opinionated. Every Model-Driven App has the same navigation patterns, the same form layouts, the same view-grid-detail flow. Users who've used Dynamics will be instantly familiar. Users who haven't will need maybe ninety minutes of training.
The Decision Framework We Use
When a client briefs us on a new app, we run through six questions before recommending one architecture or the other. I'll share the framework so you can run it on your own project.
1. Is this app primarily about managing structured records, or about a specific task or process?
If users are creating, reading, updating, and finding records - customers, assets, work orders, applications, cases, contracts - that's record management. Model-Driven wins on speed of delivery and consistency. If users are doing a specific job - inspecting a piece of equipment, ordering parts, capturing a photo at a site, signing off on a delivery - Canvas wins because you can design the screen around the task.
2. How many entities will the app cover, and how related are they?
One or two simple tables: Canvas. Five or more tables with relationships, lookups, and rollups: Model-Driven, no question. We had a client build a Canvas App for vendor management with eight related tables. It worked for the first 500 vendors. By 3,000 it was unusable. We rebuilt it as Model-Driven in eleven days and it now handles 18,000 vendors with sub-second responses.
3. Who is going to use it and on what device?
If it's field workers on phones in poor signal areas, Canvas. Canvas has offline mode, which Model-Driven currently doesn't (Microsoft has been promising this for years, and Wave 1 2026 looks like it might finally deliver, but I'd never bet a project on a promised feature). If it's office workers on browsers all day, either works, but Model-Driven will be faster to build and easier to maintain.
4. How much customisation of the look will you need?
If your stakeholders care about pixel-perfect branding, custom layouts, or unusual interaction patterns, Canvas. If they're happy with "looks like Dynamics", Model-Driven. We've had clients reject Model-Driven on aesthetics alone, then spend triple the budget building a Canvas App that does the same thing.
5. What's your data already doing?
If you have business data in Dataverse already (Dynamics 365 Sales, Customer Service, Field Service, or anything else built on the platform), Model-Driven is a near-default. You'll get instant access to your existing data with proper security trimming. If your data is scattered across SQL, SharePoint, and Excel, Canvas might be the only realistic choice without an expensive data migration project first.
6. Who is going to maintain it after we leave?
This one nobody asks until it's too late. Canvas Apps require Power Fx skills and a strong understanding of delegation, formula performance, and how connectors handle pagination. Model-Driven Apps require Dataverse modelling skills, an understanding of security roles, and comfort with business rules and workflows. They are different skill sets. If your internal team has SQL and SharePoint background, they'll pick up Model-Driven faster. If they're more front-end oriented, Canvas will feel more natural.
A Side-By-Side Comparison
| Aspect | Canvas Apps | Model-Driven Apps |
|---|---|---|
| Best for | Task-specific apps, mobile, custom UI | Record management, complex data models |
| Data source | 1,200+ connectors, any combination | Dataverse only (primary) |
| UI control | Total - pixel by pixel | Limited - generated from data model |
| Offline capability | Yes, with config | No (as of May 2026) |
| Build time (typical) | 4-12 weeks for a real app | 2-8 weeks for a real app |
| Australian build cost | AUD $40,000 to $200,000 | AUD $25,000 to $120,000 |
| Per-user license cost | AUD $7.50/user/month (Premium) | AUD $30/user/month (Premium) plus Dataverse capacity |
| Performance ceiling | Hits delegation limits at large scale | Scales to millions of rows on Dataverse |
| Maintenance burden | High - depends on formula quality | Lower - more declarative |
| Skill availability in AU | Moderate - many "low-code" developers | Lower - fewer experienced Dataverse devs |
When Canvas Apps Are The Right Call
Pick Canvas when the app does one specific job, especially if that job involves a mobile device.
A mining client in WA needed an app for crew leaders to log shift handovers. Voice notes, photos, GPS coordinates, signatures, and three or four form fields. Used in remote sites with patchy 4G. Built as a Canvas App in three weeks. Total build cost about AUD $48,000. It runs on rugged Android tablets with offline sync and has been operational for two years with minimal maintenance.
Other good Canvas fits we've delivered:
- Inspection apps for facilities or assets
- Order capture for sales reps at trade events
- Photo and GPS capture for site reports
- Simple approval workflows where the user experience is critical
- Apps embedded into Teams for specific business processes
- Customer-facing apps where branding matters
If your app description sounds like "an app to do X", Canvas is often the answer. Where Canvas falls apart is "an app to manage Y" where Y is a complex domain with hundreds of attributes and many relationships.
When Model-Driven Apps Are The Right Call
Pick Model-Driven when you have a real data domain to manage and users who'll spend hours in the app, not minutes.
A professional services firm in Sydney needed a project portfolio system. Projects, resources, time entries, expenses, client billing, document management. Sixteen related tables, complex security model (project managers see their projects, partners see the firm). We built it as a Model-Driven App in six weeks for around AUD $72,000. It's still running unchanged 18 months later. Internal staff have made dozens of small customisations themselves because the platform is forgiving for that kind of evolution.
Other good Model-Driven fits:
- CRM-like systems (sales, vendor, partner, supplier management)
- Case management (insurance claims, legal matters, complaints)
- Asset registers and maintenance records
- Compliance and audit tracking
- HR processes (onboarding, performance, certifications)
- Anything that already lives in Dynamics 365 and needs extension
If you'd describe what you need as "a system for tracking X", Model-Driven is usually the right starting point.
The Hybrid Approach Most People Miss
This is the option that doesn't get talked about enough. You can have both. You can build a Model-Driven App for the main record management work, and embed Canvas Apps inside it for specific tasks. The Canvas App appears as a custom page or a control on a form. Users don't know they're in two different app types.
We've used this for clients who needed the structure and consistency of Model-Driven for their core data, but a specific interaction (often involving a visual interface, a map, or a calculator) that Model-Driven couldn't do gracefully. The build cost goes up by maybe 15-20% over a pure Model-Driven build, but you get the best of both worlds.
This pattern works best when you've committed to Dataverse as your data platform. If you're not on Dataverse, the hybrid approach doesn't apply and you're back to a binary choice.
What This Costs To Run
Licensing in Australia in 2026 looks roughly like this. Per user per app license: AUD $7.50/user/month. This covers Canvas Apps using standard connectors. Per user license: AUD $30/user/month. This is what most Model-Driven Apps need because they use Dataverse, which is a premium connector. Pay-as-you-go: variable, useful for occasional users or external participants.
Then there's Dataverse capacity. Each Model-Driven App will need Dataverse storage, which starts at 10GB included with the license and goes up at around AUD $66/GB/month. File storage is cheaper. For a properly built business app, expect to budget AUD $50-300/month in Dataverse costs depending on data volume.
There are also Power Platform request limits that kick in at scale, and AI Builder credits if you're using AI features. We've seen organisations get bill shock at month four when a Canvas App with 200 users hits the request cap. Plan capacity at design time, not after launch.
For a deeper look at delivery costs and engagement structures, see our Power Apps consultants page.
Common Objections We Hear
"Canvas Apps are easier to build, so they're cheaper."
Not always. Canvas Apps are easier to start. They're harder to maintain at scale. A naively built Canvas App with delegation issues will need a costly rewrite when the data grows. A Model-Driven App built on a sound data model handles growth without architectural changes.
"Model-Driven Apps look corporate and boring."
True, by design. If user adoption depends on a slick interface, Canvas. If user adoption depends on the app being fast, reliable, and consistent with other Microsoft tools they use, Model-Driven wins on adoption.
"We can't use Model-Driven because our data isn't in Dataverse."
Worth asking why. Moving the right data into Dataverse is often the right answer, especially if you're going to build multiple apps on the same data. The license costs and storage costs are usually outweighed by faster delivery, better security, and reuse across apps. We've helped clients migrate from SharePoint lists to Dataverse and it has paid for itself within a year in maintenance savings alone.
"Low-code means our citizen developers can build it themselves."
Sometimes, for very small apps. For anything that touches more than one data source, has any security requirements, or needs to scale beyond a single team, you'll want experienced developers either building it or reviewing what your citizen developers produce. We've cleaned up too many citizen-developer projects that worked for thirty days and then collapsed when used in production.
A Quick Decision Checklist
Walk through these questions in order. The first clear answer usually points you to the right architecture.
- Are users in the field with mobile devices and patchy connectivity? Canvas.
- Is the data already in Dataverse or Dynamics 365? Model-Driven.
- Are there more than five related tables of structured data? Model-Driven.
- Is the app doing one specific task or workflow? Canvas.
- Does the visual design matter to stakeholders or to adoption? Canvas.
- Will users live in the app for hours per day across many records? Model-Driven.
- Are you connecting to several non-Microsoft systems? Canvas (or hybrid).
If two answers conflict, the priorities of your project decide which wins. Usually data complexity beats UI requirements, but not always.
When To Get Help
If you're building a small app for one team and you have a confident developer on staff, you can probably make this decision yourself. If you're committing to a platform direction that will affect multiple apps over multiple years, get someone in the room who has built both at scale.
We've worked on Power Apps projects across Sydney, Melbourne, Brisbane, the Sunshine Coast, and remote sites across regional Australia. Many of them start with someone asking "Canvas or Model-Driven?" and finish with a different answer than they expected. The right call depends on details that don't show up in a vendor pitch.
If you want a second opinion before committing to an architecture, get in touch. For more on how we structure engagements and what to expect, our services page and our Microsoft AI consultants page have more detail on how we approach Power Platform work alongside the broader Microsoft AI stack.
The wrong app type is one of the most expensive mistakes you can make in Power Platform. The good news is that with a clear-eyed look at what you're actually building and who's actually using it, the right answer is usually obvious within an hour.