App Pricing and Packaging: A Feature-to-Entitlement Worksheet
Map app subscription packages to features, usage limits and verified access. Use a fictional worksheet to test purchases, restores and plan changes.
Pricing sets what a customer pays. Packaging sets what they receive: features, usage allowances, service levels and access conditions. An app can have a sensible price and still fail its customers if the paywall promises one package while the product grants another.
This guide turns packaging into a reviewable feature-to-entitlement matrix. Start with the customer’s job, map each promise to an enforceable rule, then test purchase, restore and plan-change behavior. The voice-notes app below is fictional. Its limits are design inputs for the worksheet, not recommended quotas, Nuxie plan limits or customer results.
1. Separate the four decisions
| Decision | Question to answer | Example |
|---|---|---|
| Package | Which benefits and limits belong together? | Plus includes transcription and text export. |
| Price | What amount applies in this market? | A configured storefront price, displayed in the customer’s currency. |
| Billing period | How often does the customer pay? | Monthly or annual access to the same Plus package. |
| Offer | Who qualifies for which temporary terms? | An eligible introductory offer, followed by the regular subscription terms. |
Monthly and annual payment options do not have to be different feature tiers. On Apple’s platform, subscriptions with equal content and different durations can share a subscription level; see Apple’s subscription reference. Google Play distinguishes the subscription’s benefits from its base plans and offers; see Google’s subscription model. Map your product concept to each store’s actual model instead of treating the paywall labels as billing configuration.
2. Build one package for each distinct customer job
For the fictional voice-notes app, an occasional user wants to save a short thought, a regular user wants searchable meeting notes, and a heavy user wants to process longer recordings efficiently. Those jobs suggest a hypothesis about packaging. They do not prove that three plans will outperform one paid plan.
| Promise | Free | Plus | Pro |
|---|---|---|---|
| Record and play local notes | Included | Included | Included |
| Transcription allowance | 15 minutes per UTC calendar month | 120 minutes per UTC calendar month | 600 minutes per UTC calendar month |
| Export transcript as text | Not included | Included | Included |
| Submit a batch of recordings | Not included | Not included | Included, within the same minute allowance |
This example deliberately uses a calendar-month allowance separate from the billing period. An annual Plus subscriber still receives the stated monthly allowance, not twelve allowances immediately. A real app might choose billing-period resets instead. Pick one rule, state it clearly and test the boundary; do not let the frontend, billing system and usage ledger each choose a different clock.
Interview customers about the jobs and limits before fixing the matrix. If Plus and Pro solve the same job and differ only in a limit nobody reaches, another visible tier may add confusion. If batching creates meaningful value for a distinct group, it is a candidate difference to validate. Keep an upgrade path useful without degrading the basic task merely to create pressure.
3. Turn each promise into an access rule
A package name is not an entitlement. For each row, record the product mapping, current entitlement source, account identity, enforcement point and behavior when access changes.
| Worksheet field | Example decision |
|---|---|
| Feature key | transcript_export |
| Grant condition | The verified current subscription grants Plus or Pro access. |
| Enforcement | The app checks access when export is requested; a backend checks any protected server operation independently. |
| Usage key | transcription_seconds, measured from the accepted audio duration. |
| Consumption rule | Reserve allowance before processing; retries use the same operation identity; release a reservation if the job fails under the documented failure policy. |
| Plan-change policy | Specify when the new limit applies and how already-consumed usage affects the remaining balance. Never silently reset usage on every restore. |
| Existing work | Define what the customer can read or export after paid access ends, separately from whether they can start new paid work. |
Check the arithmetic independently. In this example, Plus has 120 × 60 = 7,200 seconds per calendar month. After 90 minutes have been consumed, 30 minutes remain. Retrying a failed request must not become an unexplained second charge against that allowance. The worksheet specifies intended behavior; it does not supply a production-ready metering implementation.
Use verified current entitlement state to decide access. Apple’s currentEntitlements documentation describes the transactions that currently entitle a customer to purchases and subscriptions, including subscribed or in-grace-period auto-renewable subscriptions. A tapped purchase button, local success animation or cached package label is not a substitute for resolving that state correctly.
4. Test the transitions before changing the paywall
- New purchase: the product selected, amount shown and resulting access agree. Pending, canceled and failed purchase attempts do not grant access merely because the button was tapped.
- Restore or another device: the intended customer identity regains valid access without receiving duplicate usage grants. Restoration is not recorded as a new sale.
- Upgrade or downgrade: the effective change time and allowance policy match the provider’s state. Verify scheduled changes as well as immediate ones.
- Renewal disabled: distinguish turning off future renewal from the current access expiry. Do not revoke a still-valid paid entitlement just because renewal is off.
- Billing issue, grace period or revocation: test the actual provider states and your documented access policy. A single “paid” boolean cannot describe every transition.
- Allowance exhausted: show the remaining allowance and reset rule. Test simultaneous requests, boundary timestamps and retries.
- Older package: a returning subscriber receives the benefits they are entitled to. A new paywall must not silently rewrite their existing grant.
Keep a small evidence table with the starting state, action, expected provider state, expected access and observed result. A screenshot proves what was offered; it does not prove that the resulting access or usage balance was correct.
5. Make the offer explain the matrix
The paywall should let someone answer: what do I get, what limit applies, what do I pay now, what happens later, and how do I manage the subscription? Use the actual configured product price and eligibility. If an annual option shows a monthly equivalent, keep the total charge and billing period clear.
Use “Most Popular” only when you have evidence supporting that statement for the displayed options. A highlighted option can instead say who it is for. Avoid an “unlimited” promise when the service has a meaningful undisclosed quota, and do not present a trial CTA to someone who cannot receive that trial.
There is no universal best tier count, annual discount or testing cadence. Choose the smallest offer that explains the jobs you intend to serve. For the broader model decision, use the subscription pricing guide; this worksheet focuses on what each package delivers.
6. Evaluate the package as a product change
A packaging test changes more than the number of taps on a CTA. Write down the eligible audience, assignment unit, primary outcome, observation window and guardrails before launch. Compare verified commercial outcomes alongside successful use of the promised features, refunds, support issues and retention over an appropriate period.
More trial starts do not prove more renewals. Higher initial revenue does not establish better long-term value. If several package elements change together, you can evaluate the combined package, but the result does not identify which individual feature caused the difference. Use the paywall experiment methodology and sample-size calculator to plan a test; neither guarantees a winning offer.
Where Nuxie fits
Nuxie is a mobile app growth agent that creates, delivers and improves in-app Experiences. Use the packaging worksheet to make the offer and the app behavior reviewable before changing an Experience. Keep billing ownership and entitlement enforcement explicit.
For an iOS app retaining an existing billing provider, review the purchase integration guide. It documents the outcome-only purchase delegate and the separate observer-mode configuration when another SDK owns transaction finishing. That integration choice does not remove the need to test your product mappings, account identity and access transitions.