Update to RevenueCat

{
  "name": "revenuecat-app-valuation",
  "description": "Use this skill when the user asks how much their app is worth, what they could sell their app for, how app valuations or acquisitions work, or how to prepare a subscription app for sale/exit.",
  "included_files": [],
  "skill_md_contents": "---\nname: revenuecat-app-valuation\ndescription:\n  Use this skill when the user asks how much their app is worth, what they could sell their app for,\n  how app valuations or acquisitions work, or how to prepare a subscription app for sale/exit.\n---\n\n# App valuation and selling\n\nHelp a founder understand what their app might be worth and how app acquisitions work. The\nframeworks below come from RevenueCat's guidance on selling apps, extended with how buyers\nreason about risk. Ground every estimate in the user's own RevenueCat data where you can, rather\nthan quoting the ranges in the abstract.\n\nTwo rules hold for this topic:\n\n- Always present valuation as a range with a confidence level, never a single guaranteed number.\n  An app is ultimately worth what a buyer will pay, and there is no guarantee a buyer exists at\n  any given price.\n- Treat this as general education, not financial, legal, or tax advice. For an appraisal, tax\n  treatment, or deal terms, tell the user to consult a broker, attorney, or tax professional.\n\n## The method\n\nA valuation is four decisions, in order. Work through them explicitly.\n\n1. Choose the profit base, and name it.\n2. Choose the band that base earns.\n3. Position the app within that band on the evidence.\n4. State the range, the confidence, and what would move it.\n\n## 1. Choose the profit base\n\nApps are valued as a multiple of profit, not revenue. Every multiple in this skill is a profit\nmultiple. Do not apply multiples directly to revenue metrics.\n\n| Base                     | Multiple                              |\n| ------------------------ | ------------------------------------- |\n| Monthly operating profit | 12x–36x (broad), 36x–60x (mature sub) |\n| Annual operating profit  | 1x–3x (broad), 3x–5x (mature sub)     |\n\nMRR and ARR still matter — they are the top line the profit is computed from, and the input to\nthe retention, growth, and concentration checks below. They are not a valuation base.\n\nWhen the user knows revenue but not costs, ask for costs. If they cannot give them, state the\nassumed margin as an explicit assumption and show the arithmetic in full — \"$200k ARR × 60%\nassumed margin = $120k profit × 3–5x = $360k–$600k\" — so the user can correct the assumption.\n\n### Owner earnings or post-hire profit\n\nThere are two defensible profit bases, and they are not interchangeable. Pick one, name it in the\nanswer, and apply the matching multiple.\n\n- Owner earnings — what a solo buyer who does the work themselves would take home. Proceeds minus\n  cash operating costs, plus one-off and non-recurring costs added back. Use for owner-operated\n  apps sold to individual buyers.\n- Post-hire operating profit — what the app earns after paying market rate for the work the\n  founder does for free today. Owner earnings minus the cost of replacing that work. Use when\n  the buyer is a studio or portfolio acquirer who will staff the app. Default to this.\n\nThe published 3x–5x band is a post-hire number: the acquirers quoting it are portfolio buyers who\ncarry the operating cost.\n\nTo size replacement cost, ask how many hours a week go into the app across engineering, support,\nmarketing, and admin; who is paid today and how much; and whether the founder intends to stay\nthrough a transition. A part-time maintenance load is a few thousand dollars a month of\nreplacement cost; a full-time founder doing engineering and user acquisition is a salary. Present\nit as a stated assumption, not a derived fact.\n\n### Computing the number\n\nStart from proceeds — revenue net of sales tax/VAT and store commissions — rather than gross\nrevenue, since App Store / Play Store fees are already removed. Request proceeds from\n`get-chart-data` on the `revenue` chart with the `revenue_type` selector set to `proceeds` (see\n`revenuecat-charts`). Then subtract the expenses that directly keep the app running: operational\ncosts (servers, customer support, licensing), marketing and user-acquisition spend, and ongoing\nmaintenance. Apply the add-backs above.\n\n- Do not subtract interest or corporate income tax — those reflect the seller's financing and tax\n  situation, which the buyer replaces with their own. The \"taxes\" already removed in proceeds is\n  sales tax/VAT; don't subtract income tax on top.\n- Development costs for building _new_ features are usually excluded — they fund future profit,\n  not the maintenance of existing profit. Every app differs, so note when some development cost\n  belongs in the number.\n- Use trailing-twelve-month (TTM) figures as the base.\n\nThen compute the last two full quarters annualized as a run-rate sensitivity. When it differs\nfrom the trailing-twelve-month base by more than about 20%, present both:\n\n> On trailing-twelve-month profit of $100k, the range is $300k–$500k. At the current run rate of\n> $140k, the same multiples give $420k–$700k. Buyers will anchor closer to the trailing figure\n> and ask you to prove the run rate holds — sustained growth is the argument for the top of the\n> range, not for a bigger base.\n\nThis applies in both directions: for a declining app, the run-rate number is the floor a buyer\nwill push toward and the trailing figure is what the seller defends. Show the gap either way. A\nrun-rate sensitivity is not license to annualize a spike — two or more quarters of consistent\nmovement is a trend, one strong month behind a launch or a seasonal peak is not. Check chart\n`annotations` before calling something a trend.\n\n## 2. Choose the band\n\nRevenueCat publishes two ranges, and they are not the same range — they describe different tiers\nof app:\n\n- Broad-market heuristic: apps typically sell for 12x–36x monthly operating profit (≈ 1x–3x\n  annual). This spans the whole market, including younger or higher-churn apps. Some sell for\n  many multiples more, and some do not sell at all.\n- Mature-subscription floor: for a proven, low-risk subscription business, disciplined buyers\n  anchor at 3x–5x annual operating profit (≈ 36x–60x monthly). Worked example: an app earning\n  $100k annual operating profit at 3–5x is worth roughly $300k–$500k.\n\nThese bands sit end-to-end, meeting only at 3x annual / 36x monthly. Do not average the two or\nclaim a single number reconciles them.\n\n### The mature-subscription band needs evidence, not age\n\nQualification is about whether a full renewal cycle is observable, which is usually visible well\nbefore an app's second birthday. Check all three:\n\n- Subscription-dominant revenue — roughly 70%+ of proceeds from subscriptions.\n- A completed renewal cycle for the dominant plan duration. Read `subscription_retention` or\n  `cohort_explorer`: an annual-dominant app needs cohorts observed past month 12, so the first\n  renewal is in the data. A monthly-dominant app needs cohorts observed well past the first-month\n  churn cliff — several renewal periods, not one. Check the annual-vs-monthly mix by revenue\n  first, since it decides which threshold applies. An 18-month-old annual-dominant app with\n  complete month-12 cohorts qualifies; a three-year-old app that just launched annual plans does\n  not.\n- A curve that has flattened. Retention should decay and then level off across at least two\n  consecutive cohorts. A curve still falling steeply at the last observed period is incomplete\n  evidence however long the history is.\n\nFail any check and the broad-market band applies. Say which check failed and what would clear it\n— usually a specific number of months.\n\nPast the gate, age is not a factor: the multiple is set by what the cohorts show.\n\n### Apps that are not subscription-dominant\n\nRevenueCat currently has no published or recommended valuation insights for apps that are not\npredominantly subscription apps. When the app you are asked about is not predominantly\nsubscription based, do not offer a valuation.\n\n## 3. Position within the band\n\nThe band is the starting point; these factors set where in it the app lands. Score each factor\nstrong, neutral, or weak, and say which evidence drove each call.\n\n| Factor                | Strong                                                       | Weak                                              | Where to look                                              |\n| --------------------- | ------------------------------------------------------------ | ------------------------------------------------- | ---------------------------------------------------------- |\n| Retention (2x weight) | Churn/retention in the top 30% of category peers, flat curve | Bottom 30%, or a still-falling curve              | `get-benchmarks` (monthly churn), `subscription_retention` |\n| Trajectory            | Growing 25%+ YoY, sustained two or more quarters             | Declining 10%+ YoY                                | `revenue` (proceeds), trailing twelve vs prior twelve      |\n| Monetization          | Realized LTV, trial and paying conversion in the top 30%     | Bottom 30%, or no pricing headroom left           | `get-benchmarks`, `conversion_to_paying`                   |\n| Distribution          | Compounding channels, healthy paid payback                   | Borrowed growth, or paid that does not pay back   | Ask the user                                               |\n| Concentration         | Diversified across store, geography and SKU                  | A single dependency past the thresholds below     | `revenue` segmented by `store`, `country`, `product_id`    |\n| Transferability       | Low ops burden, documented, transferable store account       | Founder-dependent, undocumented, transfer-blocked | Ask the user                                               |\n\nUse `get-benchmarks`' `percentile_bucket` directly: 70+ is strong, 30–70 neutral, under 30 weak.\nIt already accounts for reverse metrics, so a high percentile on churn means low churn. Rows with\n`is_eligible_for_benchmarking: false` are low-confidence — score them neutral and say so.\n\nThen position:\n\n- Net two or more strong, no weak — top third of the band.\n- Roughly balanced — middle third.\n- Net two or more weak — bottom third.\n\nAdditional factors that cap what a buyer is willing to pay: declining revenue, issues that might\nprevent transfer of the app, undocumented financials, concentration (see below). Mention any\nthat apply.\n\nShow the scorecard, not just the conclusion. \"Top-quartile retention and 30% year-over-year\ngrowth, but 90% of revenue from one country\" is the answer; the number summarizes it.\n\n### Reading the factors\n\n- Retention / subscriber stickiness — the strongest signal of product-market fit and future cash\n  flow, and the biggest lever on the multiple, which is why it carries double weight. What counts\n  as \"good\" is category-dependent: buyers cited healthy annual-subscription retention anywhere\n  from ~25% to ~70%. Benchmark against the app's category rather than a universal number, and be\n  ready to explain early churn (roughly 30% of subscriptions cancel in the first month) and show\n  that later cohorts stabilize.\n- Monetization headroom — under-monetization is a plus to buyers: proven monetization with clear\n  room to grow (pricing, offers, plan mix).\n- Distribution durability — treat acquisition channels as a quality tier, not a preference:\n  - Compounding (strongest): organic ASO, SEO, brand, and word of mouth.\n  - Rentable: paid user acquisition. Check payback period, not just volume.\n  - Borrowed (weakest): UGC, viral loops, influencer-driven and algorithm-driven growth, a\n    single creator, a store feature. Discount it heavily, and ask what happens to installs if it\n    stops tomorrow.\n\n  Buyers do differ on the organic/paid balance (cited preferences run from 100% organic through\n  50/50 to 75/25 paid/organic), so a defensible mix beats a dogmatic one.\n\n- Concentration — check the top segment's share of proceeds by `store`, `country` and\n  `product_id` over the trailing twelve months:\n  - Platform/store. Being iOS-only is common and only a mild discount on its own.\n  - Geography. One country above ~70% of revenue is a real cap.\n  - SKU / product. One product above ~70% of revenue means the business rests on one price point.\n  - Beyond the charts: a single traffic source, a single integration, and — for B2B-shaped apps\n    — a handful of accounts carrying revenue.\n\n- Technical infrastructure — clean architecture, low operating burden, and good documentation\n  reduce perceived risk and are most of the transferability score.\n\n### Outside the scorecard\n\nThese change the deal rather than the app's position in its band. Raise them, but do not bake\nthem into the range:\n\n- Strategic / portfolio fit — the best price often comes from the buyer who sees the most\n  synergy.\n- Founder involvement — most buyers view the founder staying through a transition as a positive.\n  Large studios with in-house teams are the exception.\n- Deal structure — offers come as cash (most common), equity, or earnouts. Roughly two-thirds of\n  offers are pure cash. Cash deals often pay ~50% at close and the remainder over the following\n  6–12 months.\n\n## 4. State the range and the confidence\n\nPresent the result as: named profit base × low-end multiple to × high-end multiple, the position\nwithin the band and why, then a confidence level.\n\nConfidence is low with thin or lumpy data, when the factors conflict, when several inputs are\nuser-supplied and unverifiable, or when a large share of revenue is non-recurring. It is higher\nwith 12+ clean months, low churn, a completed renewal cycle, and diversified revenue. A wide,\nhonest range beats a tight one you cannot defend.\n\n## Grounding an estimate in the user's RevenueCat data\n\nWhen the user wants an estimate for their own app, pull their real metrics first.\n\n- Use `revenuecat-charts` to fetch what the steps above need. Prioritize: proceeds (trailing\n  twelve months and by quarter), subscription retention by cohort, monthly churn, trial and\n  paying conversion, ARPU, annual-vs-monthly plan mix, realized LTV, and proceeds segmented by\n  store, country and product.\n- Compare against category benchmarks via `get-benchmarks` (realized LTV, trial conversion,\n  initial conversion, conversion to paying, monthly churn, refund rate). Read the percentiles\n  into the scorecard as described in step 3.\n- RevenueCat has no acquisition-cost data, so it cannot compute CAC, LTV/CAC, or payback period\n  on its own. Do not present a CAC-based number without user-supplied acquisition data.\n- Link the user to the relevant charts with `revenuecat-charts` (e.g. MRR, churn, subscription\n  retention) so they can see the inputs behind the estimate.\n\nSeveral inputs are not in RevenueCat at all. Ask for them together, once, rather than one at a\ntime:\n\n| Input                                           | Needed for                     |\n| ----------------------------------------------- | ------------------------------ |\n| Operating costs (servers, support, tooling, UA) | The profit base                |\n| Founder and team hours, and who is paid         | Add-backs and replacement cost |\n| Ad revenue, by network                          | Valuing non-recurring streams  |\n| Channel split, UA spend, payback period         | Distribution durability        |\n| Ops burden, documentation, transferability      | Transferability, and hard caps |\n\n## Preparing to sell, finding buyers, negotiating\n\nIf the user is moving toward an actual sale, summarize the relevant parts and point them to the\nfull posts for detail:\n\n- Can they even sell it? Most App Store apps can be transferred between developer accounts; a\n  few cannot (e.g. conflicting in-app-purchase product IDs, some sandboxed Mac apps, Apple Arcade\n  apps), in which case the whole developer account transfers instead. Direct them to Apple's\n  app-transfer criteria to confirm.\n- Prep before talking to buyers: clean, reconciled financials, a clear retention/growth story,\n  tidy metrics, low-friction product and infrastructure, and handover documentation.\n- Finding buyers: marketplaces and brokers (e.g. Flippa, AppFlip, App Business Brokers) and\n  direct acquirers exist; warm intros generally outperform cold outreach.\n- Negotiating: the first offer often lowballs. Recommend independent legal/financial advice for\n  the actual transaction.\n\n## Citing sources\n\nBase answers on RevenueCat's own material and cite it. The two primary posts are:\n\n- \"How to sell your mobile app\" — https://www.revenuecat.com/blog/growth/how-to-sell-an-app/\n- \"What app buyers really want: insights from 10 leading acquirers\" —\n  https://www.revenuecat.com/blog/growth/guide-to-selling-apps/\n\nAttribute the two published bands, the retention ranges, the channel-preference splits, and the\ndeal-structure figures to those posts. The factor scorecard, the concentration thresholds, the\nadd-back treatment, and the handling of non-recurring revenue are general market practice rather\nthan RevenueCat findings — present them as how a buyer reasons, and do not cite a RevenueCat post\nfor them.\n\nFor deeper or more current detail, fetch those posts or search the RevenueCat blog (selling and\nacquisition content) and the State of Subscription Apps report. To benchmark the user's app\nagainst its peers, use `get-benchmarks`.\n"
}