Power Apps vs Power Pages: who opens the screen decides which one you build

Power Apps vs Power Pages is not really a comparison of two products. It is an audience test with a licensing bill attached, and almost everyone who gets it wrong gets it wrong in the same direction: they build an internal app first, then try to let customers into it. This page is about making that call before anything is built, and about recognising quickly if it has already been made badly.

It is also not the build-versus-buy question. If you are still deciding whether to write software at all rather than licence a packaged product, start with Power Apps versus buying off-the-shelf software instead — that is a different axis, and it comes first.

It also assumes the portal belongs in the Microsoft stack at all. If you already own a WordPress site that ranks and someone has quoted a plugin build on top of it, the prior question is Power Pages versus WordPress for customer portals — which half of the website actually needs identity and records, and why the marketing pages usually should not move.

The audience test, in one question

Microsoft draws the line at the tenant boundary, and it draws it clearly. Its introduction to Power Pages (opens in new tab) describes the product as a platform “for creating, hosting, and administering modern external-facing business websites” — external-facing is the operative phrase, and it is in the first sentence. Microsoft’s Power Apps overview (opens in new tab) frames the other side as building “custom business apps” that people in your organisation run in a browser or on a phone.

So ask it plainly: does the person who needs this screen appear in your Microsoft 365 tenant as a member of staff? If yes, you want a Power App. If no — if they are a customer checking an order, a subcontractor uploading an insurance certificate, an applicant part-way through a form, a member of the public browsing before they ever identify themselves — you want a Power Pages site. The answer is rarely ambiguous once the question is asked out loud, which is why we ask it in the first scoping call rather than the third.

The reason it matters so much is that the two platforms do not merely suit different audiences. They count different things, and that determines what the thing costs to run for as long as you own it.

The licensing consequence is the expensive half

A Power App is licensed by the seat: a named person holds a plan, and that plan travels with them across the apps they are entitled to open. A Power Pages site is licensed by capacity, per website, per calendar month, and the capacity is bought in two separate currencies — authenticated users and anonymous users. Microsoft’s Power Platform licensing FAQ (opens in new tab) sets out the counting rules, and the mechanics are worth knowing before you commit to a shape, because they behave very differently as the audience grows.

Read the last row as the real difference. Seat licensing is a payroll-shaped cost and you can forecast it a year out. Website capacity is a traffic-shaped cost, which is excellent when your external audience is large and occasional, and awkward when it spikes without warning. We do not restate the Power Apps plan tiers here, because that belongs on one page rather than several: Power Apps licensing for small business covers what a Microsoft 365 seat already includes, what makes an app premium, and where the break-even between plans sits.

Both of them sit on the same Dataverse tables

The thing that makes this decision less frightening than it sounds is that the layer underneath is shared. Power Pages reads and writes Dataverse. A Power App can be built on the same tables. So the common pattern is not one or the other at all — it is a portal where a customer submits and tracks, and an internal app where your team works the identical records, with nothing to integrate because there is only one copy of the data.

The two front doors secure that data differently, though, and this is where portal projects go wrong. Inside an app, access is governed by Dataverse security roles and business units. On a site, it is governed by web roles and table permissions: Microsoft’s documentation on Power Pages table permissions (opens in new tab) is explicit that a permission has no effect at all until it is associated with a web role, and that access can be scoped globally, to the signed-in contact, to their account, or through a defined relationship. Those are two separate models over one set of records, and both have to be designed rather than discovered.

Because the data layer is the durable half, it is also the half worth getting right first. Where the tables, relationships and row-level rules are the substantial part of the job, we scope that on its own as Microsoft Dataverse consulting services and build whichever front door you need on top of it.

What the requirement sounds like, and where it belongs

Most scoping calls resolve the moment the requirement is said as a sentence instead of a preference. These are the sentences, and what each one actually implies.

You chose wrong if…

Four symptoms come up often enough to name. Each is recoverable, and each is cheaper to catch in week one than in year two.

You are adding customers to your tenant one at a time. This is the classic wrong turn. Canvas apps can be shared with Microsoft Entra B2B guests, and it genuinely works for a handful of long-term collaborators. But Microsoft is direct about the condition: to open an app that connects to Dataverse, a guest must hold a licence with Power Apps use rights matching the app’s capability, and per app plans are scoped to a single environment so they are not recognised across tenants. Practically, that means buying per user seats for people who do not work for you, plus a guest invitation for every one of them. At three suppliers, fine. At three hundred customers, you have built the wrong thing.

You are paying website capacity for people who already hold seats. The mirror-image mistake. An internal process put on a site because a portal felt more modern now bills against authenticated capacity. The rule that rescues it is worth knowing: a user who already holds a Power Apps per user licence is not counted against a site’s authenticated capacity, and a per app licence covers one Power Pages website. So an employee-facing site is not automatically an extra bill — but if nobody checked, you may be paying twice for the same people.

Someone has asked for a shareable link. If the request is “can you send them a URL that just opens”, no amount of app configuration will produce it. Anonymous access is a Power Pages capability and has no equivalent on the app side.

The app is fine, but the queue is still full. If the internal tool works and staff still spend the day answering the same external questions by hand, the problem was never the app. The missing piece is the outward-facing half, and that is a portal.

What it costs to change your mind

Honestly: the front door is a rebuild, the foundation usually is not. Screens, forms, business rules and the security model do not port between an app and a site — they are different runtimes with different permission systems, and anyone who tells you there is a converter is selling something. What survives is the data layer, provided it was modelled properly: tables, relationships, keys and the rules about who may see which row.

That is the practical argument for spending the extra day on data design at the start, even when the first version is small. A well-modelled Dataverse layer turns “we built the wrong thing” into a front-end project rather than a restart. A pile of loosely-related lists turns it into a restart.

Which page you want next

Once the audience test has pointed one way, the work is ordinary and we scope it as fixed-fee projects — senior US-based engineers, typically two to four weeks, 30 days of hypercare after go-live, and no rate card to negotiate against. If the answer was employees, our Power Apps consulting page covers canvas and model-driven builds for licensed staff, including the data layer and the release process behind them. If the answer was customers, partners or the public, our Power Pages development services page covers external sites secured with web roles and table permissions, and tested the way an attacker would test them. If the answer was both, we scope the pair together on one Dataverse foundation rather than as two disconnected projects. You can read how the fixed-fee process works before you speak to anyone.