Power Apps sells two plans, and the choice between them is pure arithmetic that almost no one runs. The per app plan licenses a user to a defined set of applications at a low price each. The per user plan licenses a user to run every Power Apps application in the organization for a single higher fee. The per app plan looks cheaper and usually is, until a user is entitled to enough applications that the stacked per app fees pass the per user price, at which point the per user plan is both cheaper and simpler. Estates standardize on one plan for the whole population and lose money in both directions. A blanket per user policy overpays for the majority who use one or two apps, while a blanket per app policy quietly overpays for the power users who have accumulated entitlements past the breakeven. The correct position is per user math run per user, with each person on the plan that costs less for the apps they actually run.
The two plans price access differently, and the difference is the whole decision. One is bounded and cheap per unit, the other is unlimited and flat. Knowing exactly what each grants is the starting point for the breakeven that follows.
The per app plan licenses a user to run a specific set of applications, priced low for each one. It is the right choice for users who interact with a small, stable number of business applications, which describes most of a typical population. The cost is predictable as long as the number of apps per user stays small, and it is the cheapest path for the single app and two app users who dominate most estates.
The per user plan licenses a user to run every Power Apps application in the organization for one fixed fee, regardless of how many apps that is. It is the right choice for power users who work across many applications, and for populations where app breadth per user is high. Above the breakeven number of apps, it is cheaper than stacking per app licenses and removes the administrative work of tracking entitlements app by app.
The plan decision is not an estate wide policy. It is a per user calculation, because the right answer depends entirely on how many applications each individual runs. Three patterns cover most of a population, and each one points cleanly to a plan.
A user who runs one or two applications. Per app is decisively cheaper here, and this group is usually the majority of the population. Where these users sit on per user plans for uniformity, the overspend is large and recurring. Moving them to per app, scoped to the apps they actually run, is typically the biggest single saving in the Power Apps estate.
A user whose app count sits near the breakeven, where stacked per app fees roughly equal the per user price. Here the per user plan often wins on simplicity even at parity, because it removes entitlement tracking and absorbs the next app the user is given without a license change. We price both and choose deliberately rather than by default.
A user who runs many applications, often having accumulated entitlements over time without anyone re running the math. Per user is clearly cheaper here, yet these users are frequently the ones left on stacked per app licenses because the original choice was never revisited. Moving them up to per user both lowers cost and simplifies their licensing.
The correct position is a per user plan assignment driven by real app usage, refreshed regularly because users gain and shed applications over time. A choice made correctly at onboarding drifts wrong as the user's app footprint changes, so the discipline matters as much as the initial math.
We pull the actual application usage per user across the Power Apps estate and run the per app versus per user math for every individual against current pricing. Narrow users move to per app scoped to their real apps, broad users move to per user, and the line cases are decided on simplicity. Across a population provisioned uniformly on one plan, this per person reassignment is a direct recurring saving, and it usually surfaces a meaningful number of users overpaying on whichever plan the estate defaulted to.
App footprints are not static. A narrow per app user who picks up three more applications crosses into per user territory, and a per user who is now down to one app should step back to per app. We set a review cadence so plan assignments track real usage rather than freezing at the onboarding decision. This keeps the estate at the lowest cost position continuously, instead of saving once and then drifting back into overspend as usage evolves over the following year.
The breakeven app count at current pricing, the three usage patterns and their correct plan, and the review cadence that keeps assignments matched to a moving app footprint. Sent on request.
We map real application usage per user, run the per app versus per user math for every individual, move narrow users to scoped per app and broad users to per user, and set the review cadence that keeps assignments correct as app footprints move. The result is the lowest cost Power Apps position your usage supports.