Shopify is moving app
billing onto its own
rails. Read the terms.

Eight plans instead of
four, and a pricing page
you no longer render.

On 2 July 2026 Shopify set out how App Pricing would roll forward: migration tooling in two phases, and an increase in supported public plans from four to eight. The plan-count change is straightforwardly good and had been asked for repeatedly. The rendering change is the one that generated fifty-odd replies of developer pushback across two threads.

The mechanism is the important part. Under the new model, plans are defined against Shopify's billing objects and merchants select them on a Shopify-rendered page. Previously, most serious apps sent merchants to a pricing page inside their own app, which they controlled and had usually spent years tuning.

So this is a change of ownership over a conversion surface rather than a billing migration, and it lands on the single page in an app funnel where money is decided.

The complaint is not
abstract. It is about a
specific page.

The pushback was unusually concrete, which is what makes it worth taking seriously rather than filing as change resistance. Two developers described the same problem within a day of each other.

One described a plans page carrying reviews, Built for Shopify signals and discount framing, and said replacing it with the platform page would reduce conversion. Another described merchants being redirected out to a pricing table showing all plans, adding a step to the funnel and disrupting onboarding.

Both are describing the same mechanic from different angles. An upgrade page that lives inside the app is a page you can test. A platform-rendered page is a page you inherit, identical to every competitor's, with no room for the social proof and framing that does a large share of the persuasion in app upgrades.

How much this costs depends entirely on where your revenue comes from. If most upgrades happen because a merchant hits a usage ceiling and needs the next tier, the page is close to a formality. If upgrades happen because a merchant is persuaded, the page was doing real work. The free-to-paid conversion analysis covers which of those two shapes an app has, and they behave very differently here.

There is a counter-argument worth stating, because the threads are naturally dominated by the people with most to lose. A standardised pricing page is more legible to merchants, who currently meet a different upgrade experience in every app they install. It is harder to use for dark patterns. It makes plan comparison across apps possible in a way it has never been. For the median merchant this is an improvement, and for the median app, which never optimised that page at all, it is neutral to positive. The loudest voices in a change thread are usually the ones who had built something on the thing being standardised, and that is a real cost without being the whole picture.

A cap of twenty breaks
the model serious apps
actually run.

The second substantive objection came from a developer describing a real pricing structure: one public usage-based plan, plus ten private plans covering fixed and annual options across five revenue tiers. Under a 20-merchant cap on private plans, that structure does not fit.

His reasoning for size-based pricing is worth quoting because it is the honest version of an argument usually made badly. Support cost, complexity and scale are materially larger for larger merchants, and he did not want to gate features to force upgrades. Charging larger merchants more for the same capability is the alternative to crippling the product, and it is the better alternative.

The multi-currency point came from a developer billing in euros because his audience is Spanish. That is not an edge case, it is the normal shape of a regional app business, and it is the kind of requirement that platform billing systems tend to reach late because the largest customers do not have it.

The plan-count change
fixes a constraint that
distorted app pricing.

Four public plans sounds like plenty until you try to price an app that serves both a two-person brand and a hundred-million-dollar merchant. That ceiling forces compromises that show up as revenue left on the table at the top and merchants priced out at the bottom, and the ecosystem has been living with those compromises long enough that they look like normal pricing rather than an artefact of a limit.

The most common distortion is a top tier that stops far below where the value does. An app whose highest public plan is $299 is not making a claim about value, it is running out of slots and putting everything above that into a custom conversation that most merchants never start. Eight slots let the ladder reach where the customers actually are.

Row two is the one worth dwelling on. Annual billing improves cash flow and reduces churn, and it is measurably harder to offer when it costs half your public plan slots. A great many apps have no annual option for that reason alone, which is a pricing decision nobody actually made.

So the honest summary of this change is mixed rather than negative. The constraint that most distorted app pricing is being removed. The surface that let strong operators outperform is being standardised. Which of those two matters more to you depends entirely on whether you had done the work on the second one, and most apps had not.

Four things worth doing
before the migration
reaches you.

Migration tooling arriving in phases means there is time, and time is only useful if it is spent on the right thing. The right thing is not the migration. It is understanding what your current page is worth so you can tell whether losing it matters.

1. Measure the current upgrade page properly. Sessions to the page, upgrades from it, and the split between usage-triggered and persuasion-triggered upgrades. Without that split you cannot size the risk.
2. Move persuasion upstream. If reviews and proof were doing work on the pricing page, they need a new home earlier in the flow, inside your app where you still control the surface.
3. Rationalise the plan list before you migrate. Eight public plans is permission, not instruction. A plan list a merchant has to study is a plan list that loses upgrades regardless of who renders it.
4. Raise the private-plan and currency constraints in the threads. Both were being actively discussed by Shopify staff. Specific, quantified feedback from a developer with a real structure moves these decisions more reliably than anything else available.

The third of those is the one most likely to pay for itself independent of the migration. Across the app businesses I have advised, plan lists tend to accumulate rather than get designed, and pruning is nearly always accretive. The pricing benchmark data covers what the market actually charges by category, which is the fastest way to see whether your ladder is coherent.

One more thing worth settling before the migration rather than during it: what happens to merchants on legacy plans. Every app that has been live for more than a year or two carries a tail of merchants on prices that no longer exist, and a platform billing migration is the moment that tail becomes visible to everyone including the merchants on it. Decide deliberately whether you are grandfathering those prices permanently, migrating them with notice, or using the change as the occasion to close them, and write the decision down before the tooling forces one. Discovering your grandfathering policy by accident, halfway through a migration, is how apps generate support load and one-star reviews in the same week.

The change most apps
should make here has
nothing to do with pages.

Buried under the funnel argument is an opportunity that the extra plan slots make practical for the first time, and it is worth more to most app businesses than the pricing page ever was.

Annual billing does three things at once. It pulls twelve months of cash forward, which for a bootstrapped app is the difference between hiring and not. It removes eleven monthly churn decisions, because a merchant who has paid for a year does not reconsider in month three. And it selects for the merchants who intend to stay, which improves every cohort metric you look at afterwards.

The usual objection is discount cost. A month or two free against twelve is a real concession, and it is smaller than it looks once you price the churn you avoid. Across the app businesses I have advised, annual cohorts retain materially better than monthly ones on the same product, and the gap is large enough that the discount is usually the cheaper half of the trade.

The reason more apps do not offer it has been structural rather than strategic: at four public plans, adding annual variants costs half your ladder. That constraint is going away. If you do one thing with the extra slots, this is the one with the clearest return, and the trial length analysis covers the adjacent decision about what happens before the first charge.

Monetisation is moving
onto platform rails, and
pricing power follows.

Step back from the specific complaints and the pattern is familiar. A platform standardises a layer that partners previously owned. The standardisation is genuinely better for most participants, particularly smaller ones who never optimised that layer anyway. It also moves control of that layer to the platform permanently.

That is not an accusation, it is a description of how platforms mature, and it usually improves the median experience while reducing the ceiling for the strongest operators. The developer with a tuned funnel loses more than the developer who sent merchants to a default page, because the tuned funnel was an advantage and standardisation removes advantages by definition.

The strategic question for an app founder is therefore not whether to comply. It is which of your remaining advantages are durable against the same treatment. Onboarding, activation, support quality and the product itself all sit inside your app and are not standardised. Pricing presentation just left that list.

This is the same structure as the revenue share and lifetime cap changes, and it is worth reading those together rather than separately. The lifetime cap analysis covers the economics, and the partner agreement breakdown covers the terms that sit underneath all of it.

Most of what decides an
app's revenue is not on
the pricing page.

It is worth ending with proportion, because threads select for the people most affected and the reading can get gloomier than the facts support.

For most apps, upgrade revenue is driven by whether the product delivered a result worth paying more for, and by whether the merchant noticed. Neither of those happens on the pricing page. Activation, time to first value and the moment a merchant sees the app working are all upstream, all still yours, and all worth more than the page being standardised.

Churn is the other half, and it is entirely untouched by this change. An app losing merchants at the ecosystem median will not be rescued by an upgrade funnel however well it converts. The churn benchmark covers what normal looks like by category, and the path from MVP to $1M ARR covers what actually moves the number at each stage.

So: rationalise the ladder, move your proof upstream, measure what the page was doing before you lose the ability to, and raise the private-plan and currency constraints while the design is still open. The plan-count increase is a real improvement and most apps will end up better off. The founders who lose are the ones who had built something on that page and find out afterwards what it was worth.

Questions app founders
ask about the move to
platform billing.