agentleFS
Sign inStart free
moasqmoasq/ios-dev-agent/.agents/skills/business-model/SKILL.md

business-model

Skill4 starsChanged 6 months agoMITView on GitHub

Use whenever deciding or revising subscription pricing, trial length, trial placement, free tier, paywall design, or any monetization tradeoff for an iOS subscription app. Covers a data-backed methodology: competitor audit, weekly-vs-monthly economics, trial strategy, Apple Review compliance, and paywall UX. Every recommendation must be cited; no guessing. Triggers: "what should our pricing be", "weekly vs monthly", "how long should the trial be", "where should the paywall live", "hard paywall vs soft paywall", "free trial", "subscription model", "IAP strategy", "choose a price point", any edit to metadata/subscriptions or metadata/iap.

13 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. 0 are common, 10 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 12 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when setting or revising the monetization model of an iOS subscription app.

    line 8
  2. Distinctive:

    Before creating the first subscription group in App Store Connect.

    line 21
  3. Distinctive:

    When changing a price point, trial length, trial placement, or free-tier scope.

    line 22
  4. Distinctive:

    When a competitor changes their pricing and the team wants to react.

    line 23
  5. Distinctive:

    When a revenue goal changes and you're re-examining LTV math.

    line 24
  6. Distinctive:

    Before running a paywall A/B test (choose the variants from the framework, not from intuition).

    line 25
  7. Distinctive:

    When App Review rejects the paywall under Guideline 3.1.2 / 3.1.3.

    line 26
  8. Very specific:

    Follow reference/competitor-audit.md.

    line 31
  9. Very specific:

    Follow reference/pricing-frameworks.md.

    line 34
  10. Very specific:

    Follow reference/trial-strategy.md.

    line 37
  11. Very specific:

    Follow reference/apple-compliance.md before shipping.

    line 40
  12. Distinctive:

    Every pricing decision should produce a project-local markdown note named after the app.

    line 44
  13. Distinctive:

    Keep worked decisions project-local.

    line 52
  14. Distinctive:

    No guessing: If a datapoint is not publicly verifiable, write "no public data found" and proceed on the next-best signal.

    line 56

“Common” is measured: kept by at least 6 in 10 of the 12 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Business model — subscription pricing, trials, paywall strategy

Use this skill when setting or revising the monetization model of an iOS subscription app. It turns "what should we charge?" into a repeatable, evidence-based decision.

Why this exists

Pricing and paywall decisions made by gut are usually wrong, and wrong pricing is the single highest-leverage mistake an indie founder can make. This skill forces the four things that make the decision defensible:

  1. Audit the real competitive set — actual prices, actual trials, actual free tiers. No vibes.
  2. Ground every claim in cited data — RevenueCat, Adapty, Superwall, Appfigures, Apple's own docs.
  3. Obey the Apple Review rules — weekly pricing is legal, but the paywall design that presents it is where rejections happen.
  4. Write the decision and the reasoning into a file that ships with the repo, so the next person (or future-you) can audit why the numbers are what they are.

When to use

  • Before creating the first subscription group in App Store Connect.
  • When changing a price point, trial length, trial placement, or free-tier scope.
  • When a competitor changes their pricing and the team wants to react.
  • When a revenue goal changes and you're re-examining LTV math.
  • Before running a paywall A/B test (choose the variants from the framework, not from intuition).
  • When App Review rejects the paywall under Guideline 3.1.2 / 3.1.3.

The four-phase workflow

Phase 1 — Competitor audit

Follow reference/competitor-audit.md. Every direct + adjacent competitor, every visible price, every trial, every free tier. Output: a markdown comparison table with citations.

Phase 2 — Economic sanity check

Follow reference/pricing-frameworks.md. Validate the weekly vs monthly vs yearly choice against published benchmark data for the target category. Calculate the "save X%" anchor between weekly and yearly — it's the strongest conversion lever on the paywall.

Phase 3 — Trial strategy

Follow reference/trial-strategy.md. Decide: trial on which plans, how long, offer mode (FREE_TRIAL vs PAY_AS_YOU_GO vs PAY_UP_FRONT), placement (hard paywall vs soft paywall), default plan pre-selection.

Phase 4 — Paywall compliance

Follow reference/apple-compliance.md before shipping. Apple's 2024–2026 crackdown on misleading subscription disclosure is the number-one rejection vector — the paywall must pass the disclosure checklist or the app will be rejected.

Decision artefact

Every pricing decision should produce a project-local markdown note named after the app. It captures:

  • Final prices per plan, period, trial length, offer mode
  • The competitive data that backed each choice
  • The benchmark citations that backed each choice
  • The Apple compliance checklist with each item ticked
  • The "what would change this decision" criteria (i.e. if weekly churn > X%, revisit)

Keep worked decisions project-local; do not bake app-specific pricing decisions into this reusable skill.

Non-negotiables

  • No guessing. If a datapoint is not publicly verifiable, write "no public data found" and proceed on the next-best signal. Fabricating a percentage is worse than omitting one.
  • No "on-device" / "offline" claims unless the app is genuinely on-device. Apple will reject and users will leave 1-star reviews.
  • No monthly-only plans for new entrants. Data is consistent: monthly-only is lower conversion and lower LTV than weekly+yearly. If monthly is included, it's a quiet third tier.
  • No horizontal toggle paywalls. RevenueCat declared the pattern dead in 2025; current winner is two stacked cards with yearly pre-selected.
  • No 14+ day trials. Public data does not support them; they add cancellations, not conversions.
  • No "Start Free Trial" buttons without the price adjacent. Guideline 3.1.2 rejection trigger.

Related skills

  • paywall — paywall UX construction (once the model is chosen by this skill)
  • asc-ppp-pricing — territory-specific pricing via the asc CLI
  • asc-revenuecat-catalog-sync — reconciling ASC subscriptions with RevenueCat offerings
  • asc-metadata-yaml — where the chosen prices live in the repo
  • onboarding — where the paywall lives in the new-user funnel

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free