Power Platform licensing costs are predictable if you model them before the first release. Three things change the bill: premium connectors, Dataverse capacity, and per-user or per-app plans priced against the full rollout population, which is usually many times the pilot.
The licensing model is layered, and the layers interact with architecture decisions in ways that surprise organisations after the app has shipped. The pattern is consistent. The pilot ran at no extra cost under existing Microsoft 365 seats, the production rollout crossed a line nobody knew was there, and the first full invoice arrived as a finance escalation. Each of those lines is visible in advance if someone looks.
The biggest line is standard versus premium. Apps that stay within standard connectors, such as SharePoint, Excel and Teams, are covered by most Microsoft 365 licences. Once an app touches Dataverse, SQL or nearly any third-party system, every user of that app needs a premium licence, either per user per month or per app per month. An app built for 40 people that is rolled out to 900 changes licensing category, and the bill changes with it.
Dataverse capacity is the quieter one. Database, file and log capacity accrue with tenants and licences, and they are consumed by the good practices we recommend: proper tables in place of SharePoint lists, audit trails, attachments. Consumption grows gradually until it becomes a procurement conversation.
Then there is accumulation. Per-user plans cover a user for all apps, while 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 simple. List the realistic user population at full rollout. Classify each planned app as standard or premium, and record why. Price the two or three licensing options that could cover the estate (per-user, per-app, pay-as-you-go) against that population. Project Dataverse consumption from the data model. The output is one page, and it regularly changes the architecture.
Sometimes a premium connector is doing a job a standard pattern could do, and removing it takes the whole app out of premium licensing. Sometimes the population maths shows per-user plans beat the per-app accumulation the team was drifting into. And sometimes the model says this should not be a Power App at all: at high volumes and user counts, custom software with conventional hosting can cost less by year three than the licensing it replaces. That outcome is less common, but common enough that the comparison belongs on the page.
Microsoft adjusts the licensing scheme and estates grow, so the model needs maintaining. The Centre of Excellence that governs the platform, described in our post on Power Platform governance, should own the licensing model as a living document: reviewed when new apps are proposed, and re-priced annually.
Our Power Platform practice runs this modelling as part of every engagement, before the first release.
Apps that use only standard connectors such as SharePoint, Excel and Teams are covered by most Microsoft 365 licences. An app that uses Dataverse, SQL or most third-party connectors needs a premium licence for every user of it.
Per-app plans cost less when a user needs a single premium app. As the number of premium apps per user grows, per-user plans usually come out ahead, so price both against the whole estate.
Tables, audit logs and file attachments consume database, log and file capacity. Capacity comes with your tenant and licences, and going beyond it means buying more.
At high volumes and high user counts, custom software with conventional hosting can cost less by year three than the licensing it replaces. A licensing model built before development shows whether an app is in that range.
Marcel Rizzolo is Director of Coder Trove.