Lifetime Deals and AppSumo for B2B SaaS: The Real Math Before You Launch One

1. Blog
2. Conversion & Pricing

By Saroj Jha · October 24, 2026 · 29 min read

A lifetime deal can raise cash and bring in users quickly, and it can leave a company serving every active account for as long as the product exists on money it received once. Whether it pays comes down to two numbers for each code: what you keep, and what that code costs to serve every month it stays active. This post gives the method, the terms AppSumo publishes, the contract and cash points to settle before you launch, and the alternatives I would try first.

A lifetime deal is cash now against service owed later. A code pays for itself only while the months it stays active, multiplied by its monthly cost to serve, stay below what you keep from it. In the fictional Example Co. case, an AI product loses $23.50 per code over 18 months, and a usage cap turns that into a small gain. Every Example Co. figure is fictional.

Running case: Example Co. Fictional

Example Co. is a seed-stage B2B SaaS company with an AI proposal writer for freelancers and small agencies. The Pro plan costs $49 a month. Each AI draft costs about $0.02 in model inference, and a typical active user creates about 120 drafts a month. The team has 300 paying subscribers, a long list of feature requests and eight months of runway. A lifetime deal on AppSumo looks like a fast way to raise cash and collect reviews. Example Co. and every number in this post are illustrative.

Step 1: Understand what a lifetime deal is and how AppSumo works

A lifetime deal (LTD) is a one-time payment for continuing access to a software product, instead of a subscription. On a marketplace such as AppSumo the marketplace takes payment, runs the listing and its audience, and passes a share of the revenue to the seller.

The word “lifetime” means the product’s life, not the buyer’s. AppSumo’s Terms of Use say lifetime deals “give you access to the Product for the lifetime of the Product, so not necessarily until you die”^[1]. That is the promise you make: access for as long as the product exists.

What AppSumo’s own documents say

I read four AppSumo documents on October 24, 2026: the Partner Terms (effective June 15, 2026), which govern sellers; the Terms of Use (last modified February 11, 2025), which govern buyers; the Partner Payments Policy (updated November 21, 2025); and the seller pages at sell.appsumo.com. Here is what they say on the points founders ask about most.

• Revenue share. AppSumo’s published seller page says: “Earn 95% of revenue from new buyers you bring to AppSumo”, minus a 5% processing fee, and lists 70% for returning AppSumo customers that AppSumo sends to a partner^[2]. Its seller FAQ says: “Revenue share rates are negotiated based on your product category and expected performance”^[3], and a November 2024 AppSumo post says it negotiates a split with each partner and that the split evolves with the marketing and exposure AppSumo drives^[6]. The Partner Terms say the Revenue Share is subject to the calculation, deductions, offsets and other terms in the applicable Promotion Agreement and state no percentage (Section 1.7)^[4]. I found no page that states a rate for new buyers AppSumo brings to your product.
• What the share is a share of. The Payments Policy defines Net Revenue as the gross amount less the 10% discount AppSumo gives members of its Plus program, where they bought your product, and less revenue lost to returns. It adds that if you earn affiliate revenue through an AppSumo affiliate program, AppSumo may reduce your Revenue Share payments to offset it^[5].
• Payout timing. Partners are paid “on a Net 60 end-of-month basis”: AppSumo says it will initiate payment “during the first week of each month that occurs two full months following sales”^[5]. The seller page says the same in other words: “all payments are processed 60 days after the end of each month”^[2]. Sales in March are paid in early June.
• Refund window. Buyers’ lifetime deals “typically have a 60-day refund period that begins the day you purchase the Product”; some have 30 days, and the Terms tell buyers to check each listing^[1]. The Payments Policy gives a full refund “for any reason (or no reason)” in that window and says refunds may reduce current or future payments to you^[5].
• Refunds after you are paid. AppSumo “may issue refunds, store credits, account credits, or other reasonable customer remediation” and can recover the cost from you by offsetting payouts or recouping amounts already paid (Section 1.3). Section 6.2 limits what you must reimburse to remediation issued under AppSumo’s refund policy, its “We Got Your Back Guarantee” or other listed circumstances^[4].
• Tax forms. The Payments Policy says each partner must submit the appropriate IRS tax forms before any payment is made^[5].
• Getting listed. Listing authority “is granted by AppSumo, is non-exclusive and revocable, and is subject to AppSumo’s approval” (Section 1.1), and AppSumo may decline to list, continue or relaunch a product (Section 1.4)^[4]. The seller page says applying costs nothing up front, that a product should be a working product and not a beta or coming-soon concept, that the partner’s audience should overlap with small-business owners, marketers, creators and agencies, and that the partner will respond to reviews and support customers^[3].
• Delivering what you sold. You “must provide AppSumo Customers with the Product exactly as described in the Product Listing”. You may not remove, materially limit or degrade included features unless the change applies to all users, is not exclusive to AppSumo customers, does not materially reduce the output or value of the product as promoted, and is communicated to AppSumo under Section 5.4.6 (Section 5.4.1, listed as a “Severe Breach” section)^[4].
• Redemption and support. Buyers must have “at least 60 days from purchase to redeem”, and codes or licensing endpoints must stay available for at least three months after you stop offering the product on the marketplace (Section 5.4.2). You must “Respond to all support requests within four (4) days” and “Resolve support requests within fourteen (14) days” (Section 5.4.3)^[4].
• Ending or relaunching. If you discontinue, sunset or materially degrade the product and you, an affiliate or a successor launch a “Substantially Similar Product” within 24 months after AppSumo’s last sale, AppSumo customers must keep access on terms at least as favourable as those in the listing (Section 5.4.4). Material changes, such as price or feature changes, need at least 30 days’ prior written notice to AppSumo (Section 5.4.6)^[4].

Two of these bind for a long time. Under Section 5.4.1 the limits you set on day one are the limits you live with, and under Section 5.4.4 a pivot to a similar product does not end the obligation. Terms change: these are the versions I opened on October 24, 2026. Ask AppSumo for your revenue share, payout dates and refund netting in writing before you sign.

This is general information, not legal, financial or tax advice. Check with a qualified professional.

Step 2: List what a lifetime deal gets you, and what it costs

A lifetime deal trades value now for obligations later. Write both columns down before you look at any revenue figure.

What an LTD gives you. Cash that is revenue, not equity, paid once. A large number of new accounts in a short window. Each account can surface bugs, requests and edge cases you would not otherwise see. Reviews on the listing; AppSumo’s seller page says a partner will respond to reviews^[3].

What an LTD costs you.

• Support load. Thousands of accounts arrive at once, and AppSumo’s terms set response times (Step 1).
• Servicing cost, forever. Every active code costs hosting, storage and support each month and, for AI products, inference on every action. The cost runs while the user is active; the revenue arrived once.
• Buyers who may never become recurring revenue. A code has no renewal date, so nothing prompts a later payment unless you sell an add-on or an upgrade (Step 9).
• A visible one-time price. Existing subscribers and prospects can see it, so decide what you will say when they ask why they pay monthly.
• Roadmap requests with no renewal to weigh them against. Lifetime accounts keep asking for features, and there is no renewal conversation to set those requests against.
• Reviews from buyers outside your customer profile, if the marketplace audience differs from yours (Step 5).
• Cannibalised customers. Any buyer who would have subscribed pays once instead.
• Cash that arrives late. Money for March sales arrives in June (Step 7), while the support work starts on launch day.

The costs arrive month by month for as long as codes stay active, while the cash arrives once, about two months after the sales month (Step 1).

Step 3: Work out what you keep and what each code costs to serve

The core of the decision is one comparison per code: what you keep, against what it costs to serve that code for as long as it stays active. The formulas are short.

Kept per code = code price × your revenue share. Total received = codes sold × (1 − refund rate) × code price × your revenue share. Lifetime cost to serve = cost to serve per active code per month × expected active months. Break-even active months = kept per code ÷ monthly cost to serve.

Use your own figures. The revenue share is in your Promotion Agreement (Step 1), and the refund rate is an assumption until you have run a deal, so model a range. Cost to serve includes hosting, storage, third-party services, email and support time, plus inference if your product calls a model. AAJ’s AI Inference Cost Modeler works out the inference part per user per month, and the report AI Product Unit Economics in 2026 explains what drives it. If a refunded buyer loses access, a refunded code costs you nothing further, which is why the break-even uses kept codes only.

Example Co., step 3 Fictional

The base model. Every figure is an assumption for illustration. None is AppSumo’s rate or anyone’s benchmark.

• Code price $79. Codes sold: 2,000. Gross sales: $158,000.
• Assumed refund rate 15%, so 1,700 codes are kept and net sales are $134,300.
• Assumed revenue share: 50%. I picked it as an input to work with; it is not a rate AppSumo quotes for new buyers. Example Co. receives $67,150, or $39.50 per kept code. The 10% Plus discount, which lowers Net Revenue on Plus members’ purchases, is left out of this model; it would lower these figures.
• Cost to serve per active code per month: inference 120 drafts × $0.02 = $2.40; hosting, storage and email $0.60; support time $0.50. Total $3.50.
• Break-even: $39.50 ÷ $3.50 = 11.3 active months. After that, each month a code stays active loses $3.50.

If the average kept code stays active for 18 months, its cost to serve is $3.50 × 18 = $63.00 against $39.50 received: a loss of $23.50 per code, or $39,950 across 1,700 codes. The $67,150 arrives once. The $107,100 of cost to serve arrives over 18 months, at $5,950 a month while every code is active.

How sensitive is this to the revenue share and to AI cost?

The share you keep is the largest unknown, and AppSumo publishes figures for only some buyers. The table runs the same deal at four shares of your own choosing, then removes the AI feature. None of the four is an AppSumo rate.

At a 65% share the AI version still loses money over 18 months. It turns positive in this table only at the 90% input, or when the feature is removed or capped. Without inference, the same deal covers its cost to serve over 18 months at a share of 26% or more, because $1.10 × 18 is $19.80 and $19.80 ÷ $79 is 25.1%. Your own share is set in your Promotion Agreement; replace all four with it.

What happens when buyers stack codes?

Some lifetime deals let a buyer buy more than one code to unlock a higher tier. Stacking is only safe if each extra code adds no more cost to serve than it adds revenue.

Example Co., step 3 Fictional

Stacking. Suppose two stacked codes ($158) unlock 360 drafts a month, three times the single-code allowance, for twice the price.

• Kept per stacked account at the 50% base: $158 × 0.50 = $79.00 (no refunds).
• Cost per active month if the account uses the full allowance: 360 × $0.02 = $7.20 inference + $1.10 other = $8.30.
• Break-even: $79.00 ÷ $8.30 = 9.5 months, shorter than a single code’s 11.3.

In this example, three times the usage for twice the price makes the heaviest accounts the least profitable. When you set tiers, check that usage rises no faster than price.

How does one code compare with one subscriber?

I ran a $49-a-month subscriber through AAJ’s unit-economics engine, using a gross margin of 92.9% (the $49 price less the $3.50 cost to serve), an assumed 4% monthly churn and an assumed $300 paid CAC. It returns a gross-margin LTV of $1,138, an LTV:CAC of 3.8:1 and a CAC payback of 6.6 months. In plain terms, one retained subscriber’s lifetime gross profit is about the size of the whole receipts of 29 kept codes. The comparison is rough, because it sets a margin figure against a revenue figure and rests on a churn assumption, but it shows why a small share of buyers moving to a recurring plan matters more than the headline count of codes sold. The Unit Economics Calculator runs the same arithmetic on your numbers.

Free tool

Check the break-even on your own numbers

The free Unit Economics Calculator sets what a code brings in beside the LTV and payback of a subscription.

This is general information, not legal, financial or tax advice. Check with a qualified professional.

Step 4: Compare the deal with acquiring the same users another way

A lifetime deal can look like cheap acquisition. Test that on the same basis as your other channels: cost per paying recurring customer, not per signup.

1. Net cost of the deal = lifetime cost to serve all kept codes − what you received, plus the team time to run it.
2. Recurring customers it produces = kept codes × the share who later buy a subscription, add-on or upgrade. This is an assumption until you measure it; run the math at several conversion rates.
3. Effective cost per recurring customer = (1) ÷ (2). Compare it with your CAC from other channels.

Then count cannibalisation: buyers who would have subscribed anyway.

Example Co., step 4 Fictional

From Step 3, the deal’s net cost over 18 months is $107,100 − $67,150 = $39,950, before team time. Example Co. assumes 3% of the 1,700 kept codes, 51 accounts, later buy a recurring add-on. Effective cost per recurring customer: $39,950 ÷ 51 = about $780. Its paid channels bring a $49-a-month subscriber for an assumed CAC of $300.

Cannibalisation adds to the bill. If 100 of the 1,700 buyers would otherwise have subscribed at $49 a month for 14 months, Example Co. has given up 100 × $49 × 14 = $68,600 of subscription revenue.

On these assumptions the deal is not cheap acquisition: about $780 per recurring customer against $300 for the paid channel, before the $68,600 of cannibalisation. It pays only if the cash or the feedback is worth more than that margin.

The Churn and Retention Calculator and the Cohort Retention Curve Builder help you estimate expected active months from your own retention data instead of guessing. The post My LTV:CAC Is Below 3:1. Which Number Should I Fix First? shows how to read the result.

Step 5: Decide whether a lifetime deal fits your product

The arithmetic in Step 3 sets the test: a lifetime deal can fit only when break-even months are longer than the active months you expect. The checks below test the inputs to that comparison and the terms in Step 1. They are not research findings.

If your customer profile is small businesses and solopreneurs, check that the marketplace’s buyers look like them. AppSumo’s own seller page says it looks for partners whose audience overlaps with small-business owners, marketers, creators and agencies^[3], so a product sold to an enterprise buying committee does not match the audience it describes. The post Product-Market Fit: How to Tell If You Have It helps you judge where you are before you decide.

Example Co., step 5 Fictional

Two checks point toward a fit: the customer profile is small freelancers and agencies, and the team wants feedback at volume. Two point away: every draft costs inference, and break-even is 11.3 months. The team will run a deal only if the Step 6 design pushes break-even past its expected active months.

Step 6: Design the deal and write the terms to limit the damage

If you go ahead, the deal design is where you control cost. Under AppSumo’s Partner Terms you must deliver the product “exactly as described in the Product Listing” and may not later degrade included features for AppSumo customers alone (Section 5.4.1)^[4]. So write the limits into the listing before launch; you may not be able to add them afterwards.

• Cap usage, not just features. Put a monthly allowance on the costly action: AI generations, credits, storage, contacts or emails. Set it so a fully used code still breaks even within your expected active months.
• Cap seats. One code, one workspace, a stated number of users.
• Check that allowances rise no faster than price. In the Step 3 example, two codes cost twice as much and unlock three times the usage, which made the account less profitable.
• Cap stacking. Set a maximum number of codes per account.
• Limit quantity. Decide in advance how many codes you can support, and stop there. The Partner Terms set a four-day reply and a fourteen-day resolution for every request (Section 5.4.3).
• Separate add-ons. Sell heavy usage, premium models or new modules as paid add-ons, and say in the listing which future products are not included. The Partner Terms refer to an “Add-on Revenue Share”, so check how add-ons sold to these customers are treated in your Promotion Agreement.
• Be precise about future features. State which plan the code maps to and whether future features on that plan are included. Under Section 5.4.1 the listing is what you must deliver, so a vague promise such as “all future updates” is a promise you may have to keep.
• Sunset promotional extras. If you include a time-limited bonus, such as extra launch credits, say when it ends.

Define “lifetime” in your own terms

AppSumo’s Terms of Use define “lifetime” for its buyers (Step 1). Whether your own terms of service and plan page need to say more is a question for a lawyer. Points I would raise: that lifetime means the life of the product, not the buyer’s; which plan the code maps to and whether it moves if you rename or restructure plans; a fair-use limit for shared or resold accounts; what notice you will give if you end the product or an integration; and that the refund window in your terms matches the listing. This is orientation, not a template, and I am not giving legal advice.

Example Co., step 6 Fictional

The team redesigns the deal: one code gives 40 drafts a month, one workspace and two users; two stacked codes give 80 drafts and five users; no more than two codes per account; 1,000 codes in total. Extra drafts and a premium model are a paid monthly add-on, and the listing says that new modules are not included. At 40 drafts, the cost to serve a fully used code falls to 40 × $0.02 + $1.10 = $1.90 a month, so break-even rises from 11.3 to $39.50 ÷ $1.90 = 20.8 months, beyond the 18-month assumption. At 18 months a code now earns $5.30 more than it costs, and 1,000 codes sold, 850 kept, receive $33,575 against $29,070 of cost to serve. The add-on gives heavy users a path to recurring revenue. All figures are illustrative.

This is general information, not legal, financial or tax advice. Check with a qualified professional.

Step 7: Plan the cash, the paperwork and the books

A lifetime deal changes your cash flow in a way a subscription does not: the work starts at launch and the money arrives after the refund window closes.

Cash timing. Under the Payments Policy, March sales are paid in the first week of June (Step 1). For Example Co., with eight months of runway, the cash arrives about two months after the sales month, while the support and inference costs begin at once. Refunds inside the window reduce what is paid, and AppSumo can offset or recoup later (Partner Terms, Section 1.3). Keep a reserve for the refund window rather than spending against the headline sales figure.

Paperwork. AppSumo requires IRS tax forms before it pays (Payments Policy). Complete them before launch, not after your first payout date.

Books. Receiving $79 once while owing service for as long as the product exists raises an accounting question: is each code a sale on the day it is paid for, or a service delivered over time? US accounting rules say an entity recognizes revenue “when (or as) the entity satisfies a performance obligation”, and list receiving and consuming the benefits as the entity performs as one test for revenue recognised over time^[7]. How that applies to a lifetime code is a judgment for your accountant, and it can change when revenue shows in your statements. Ask before you report the result to investors or lenders.

Reporting. A lifetime receipt is a one-time payment, and a one-time payment does not recur, so I would keep lifetime receipts out of monthly recurring revenue, report them as one-time cash, and track lifetime accounts as their own cohort with their own cost to serve. Mixing them into recurring metrics blurs the churn and margin of your subscribers.

This is general information, not legal, financial or tax advice. Check with a qualified professional.

Step 8: Run the launch: onboarding, support and reviews

Running a lifetime deal is a launch compressed into days. Plan it like one; the Product Launch Playbook and the Launch Readiness Planner cover the general work.

Onboarding. Before launch, build a self-serve path to first value: a welcome email sequence, an in-product checklist and short videos. Every question onboarding answers is a ticket you do not get. See the Customer Onboarding and Retention Playbook.

Support plan. AppSumo’s Partner Terms require you to respond within four days and resolve within fourteen (Section 5.4.3). Estimate the peak from your own ticket rate per new account, staff for it, pre-write answers to predictable questions, and keep a public changelog so you do not answer “is X coming?” one by one.

Reviews. AppSumo’s seller page says a partner will respond to reviews^[3], and the rules on how you ask for them apply in full. This is orientation, not legal advice.

• The FTC’s consumer reviews rule, 16 CFR Part 465, published in August 2024. Section 465.4 makes it an unfair or deceptive practice “for a business to provide compensation or other incentives in exchange for” consumer reviews “expressing a particular sentiment, whether positive or negative”. Section 465.1 defines buying a review as providing “something of value, such as money, gift certificates, products, services, discounts,” and similar, “in exchange for a consumer review”^[8]. In practice, you can ask every buyer for an honest review; you should not offer extra credits, codes or features only for positive ones.
• Insider reviews. Section 465.5 covers reviews or testimonials written by an officer or manager about their own business without a clear and conspicuous disclosure of the relationship^[8]. Founders and staff should not post reviews of their own product without disclosure.
• The FTC’s Endorsement Guides, 16 CFR Part 255. Section 255.5 says material connections “can include monetary payment or the provision of free or discounted products”, including “early access to a product”, and that such a connection “must be disclosed clearly and conspicuously” where the audience would not expect it^[9]. An incentive for an honest review is still a connection that may need disclosing.
• Platform rules. Marketplaces and review sites set their own review policies, which may be stricter. AppSumo’s Terms of Use make buyers responsible for their reviews and bar content that is “false and misleading or uses the Services in a manner that is fraudulent or deceptive” (Section 6). I found no mention of incentivised reviews in the Terms of Use or the Partner Terms^[1]. Check the current policy of every platform where you ask. The post Review Sites for Startups: How to Earn Honest G2 and Capterra Reviews covers the review-site side.

Reply to critical reviews calmly and specifically. The Partner Terms include a non-disparagement clause covering AppSumo, the marketplace and AppSumo customers (Section 5.5), so keep replies factual.

Example Co., step 8 Fictional

The founder and one support hire block out the first two weeks for tickets. The welcome sequence asks every buyer, on day 14, for an honest review, with no reward attached. The team agrees that no staff member reviews the product, and keeps the review request separate from any upgrade offer.

This is general information, not legal, financial or tax advice. Check with a qualified professional.

Step 9: Convert lifetime users to recurring revenue, and track them as a cohort

Whether a lifetime deal pays back depends on how many buyers later pay you something recurring (Step 4). Plan the path before launch, not after.

• Sell what grows with use. Extra usage, more seats, more workspaces, premium models or integrations, as monthly add-ons.
• Make the upgrade visible at the limit. When a user hits their allowance, show the add-on at that moment, with the price.
• Release new modules outside the deal, if your listing says so (Step 6), and offer them to lifetime buyers at a fair price.
• Tell your existing subscribers first. Subscribers can see a one-time price for the same product. Decide before launch what you will offer them, such as an annual plan at a lower price, and say so.
• Interview your heaviest lifetime users to learn who they are and where to find more like them, with the Customer Interview Kit.

Tag every lifetime account in your CRM and product analytics, and measure the cohort separately from subscribers. These are the numbers I would track:

Step 10: Consider the alternatives first

Each option below gives you part of what a lifetime deal does and keeps a recurring relationship with the customer.

• Founding-member annual plans. Sell a limited number of annual plans at a discount to early customers, with the price locked for as long as they renew. You get cash up front, and the customer still renews each year.
• Beta or early-access pricing. A lower monthly price for a stated period, in exchange for feedback calls. You keep the subscription relationship.
• A Product Hunt launch, a different route to early users. The post How to Launch on Product Hunt Without Wasting the Day covers it.
• A free plan or trial for volume at zero price, with paid limits. See Free Trial, Freemium or Demo?.
• Annual prepayment for existing customers. A discount for paying twelve months up front brings cash forward without a permanent promise.

For setting any of these prices, the SaaS Pricing and Packaging Playbook and The Pricing Mistakes That Quietly Kill Startup Growth go deeper.

What if you need to change or end the product?

Plan the ending before the beginning. Under the Partner Terms, codes or licensing endpoints must stay available for at least three months after you stop offering the product on the marketplace (Section 5.4.2), a similar product launched within 24 months after AppSumo’s last sale must give AppSumo customers access on terms at least as favourable as those in the listing (Section 5.4.4), and material changes need 30 days’ prior written notice to AppSumo (Section 5.4.6)^[4]. So the real question is not “can I stop?” but “what do I owe if I do?” Write down, before you sign, what service level you will keep, what you will give buyers if you retire a feature, and who is responsible if you sell the company. If your company is sold, Section 5.4.5 requires you to obtain the successor’s written assumption of your obligations before closing, and failing to do so is a Severe Breach as of closing, so read it before any sale or merger.

What changes by stage?

• Pre-seed — With no subscribers yet, the cannibalisation line in Step 4 is zero, so the open questions are break-even and support capacity. If every action calls a model, run Step 3 with and without the AI feature before deciding.
• Seed — You have a paying base and a price, so both the cannibalisation line in Step 4 and the visible one-time price (Step 2) apply. Run Steps 3 and 4 on your real retention and cost data, and compare founding-member plans (Step 10).
• Series A–B — If a sales team sells annual contracts, the cannibalisation line is the one to price first. Track any earlier lifetime users as a separate cohort, report their cost to serve, and keep their terms visible to whoever owns support.

What mistakes should I avoid?

• Modelling revenue but not cost to serve. The cost runs for as long as the user stays active.
• Ignoring inference. In the Example Co. base case, inference is $2.40 of the $3.50 monthly cost to serve.
• Assuming the revenue share. The published rates cover only buyers you bring and returning AppSumo customers. Get your figure, payout timing and refund netting in writing.
• Unlimited usage or generous stacking. In the Step 3 example, usage rose faster than price and the account became less profitable.
• Vague promises about future features. Under AppSumo’s terms, what you list is what you deliver.
• No quantity cap. Sell only as many codes as you can support.
• Spending against sales, not payouts. Cash arrives about two months after the sales month, net of refunds.
• Rewarding positive reviews, or staff reviews without disclosure. Both run into the FTC’s consumer reviews rule.
• No path to recurring revenue. Without add-ons or upgrades, every code is a one-time payment against a permanent cost.

Method and limits

I opened every AppSumo, FTC and FASB page named here on October 24, 2026, through a web-page reading tool, so check short quotations against the live pages. AppSumo publishes revenue share only for some buyers, so every share in the Example Co. model is an input of my own choosing, not an AppSumo rate. The unit-economics figures come from AAJ’s engine with assumed churn and CAC. All Example Co. numbers, the 15% refund rate, the 3% conversion rate and the 18-month active life are illustrative. This is general information, not legal, financial or tax advice.