The Power Platform's licensing model is not unreasonable, but it is layered, and the layers interact with architectural decisions in ways that surprise organisations after the app has shipped. The pattern is consistent enough to describe: the pilot was effectively free under existing Microsoft 365 seats, the production rollout crossed a line nobody knew was there, and the first true invoice arrived as a finance escalation.
Every one of those lines is visible in advance if someone looks. The looking is the discipline.
The big one is standard versus premium. Apps that stay within standard connectors, SharePoint, Excel, Teams and their kin, are covered by most Microsoft 365 licences. The moment an app touches Dataverse, SQL, or nearly any third-party system, every user of that app needs a premium licence, per user per month or per app per month. An app built for 40 people that gets rolled out to 900 does not cost twenty times more; it changes category.
Dataverse capacity is the quieter one. Database, file and log capacity accrue with tenants and licences, and they are consumed by exactly the good practices we recommend: proper tables instead of SharePoint lists, audit trails, attachments. Growth is gradual and then suddenly a procurement conversation.
Then the accumulation problem: per-user plans cover a user for all apps, per-app plans cover one app cheaply. Choose per-app forty times and you have paid for per-user several times over. Nobody makes this mistake in a single decision; estates make it across three years of individually sensible choices.
The exercise we run before build starts is not sophisticated, it is just done. List the realistic user population at full rollout, not pilot size. Classify each planned app: standard or premium, and why. Price the two or three licensing shapes that could cover the estate, per-user, per-app, pay-as-you-go, against that population. Project Dataverse consumption from the data model, not from hope. The output is one page, and it regularly changes the architecture.
Changes it how? Sometimes a premium connector is doing a job a standard pattern could do, and removing it moves the whole app out of premium licensing. Sometimes the population maths says per-user plans beat the per-app accumulation the team was sleepwalking into. And sometimes the model says this should not be a Power App at all: at high volumes and high user counts, custom software with conventional hosting can cost less at year three than the licensing it replaces. That is not the common case, but it is common enough that the comparison belongs in the page.
Licensing is not a one-off decision, because Microsoft adjusts the scheme and estates grow. The centre of excellence that governs the platform, the one described in the governance post, owns the licensing model as a living document: reviewed when apps are proposed, and re-priced annually. Estates that do this treat licensing as a design input. Estates that do not treat it as weather.
Our Power Platform practice runs this modelling as part of every engagement, before the first release rather than after the first invoice.
Marcel Rizzolo is Director of Coder Trove.