Before you choose what to build, understand what you're choosing between. The business model you pick determines your pricing, your sales motion, your metrics, your funding options, your team, and how long you can survive without revenue. Almost every other decision in this book is downstream of it.
The concept
People think of software products as differing by category, a fitness app, a CRM, a marketplace. That's the wrong axis. What actually determines how your company works is how money reaches you, and there are only about six answers.
Two products in the same category with different models are completely different businesses. A fitness app charging $60/year and a fitness app taking 15% of personal-trainer bookings share a topic and nothing else: different customers, different metrics, different failure modes, different reasons to raise money or not.
So: pick the model consciously. Most first-time founders inherit one by imitation and only discover its constraints a year in.
The six models
| Model | You charge | Who decides to buy | The core problem |
|---|---|---|---|
| Consumer subscription | Individuals, recurring, $5-100/yr typically | One person, in seconds, emotionally | Retention. Churn is brutal and constant |
| B2B SaaS | Companies, recurring, $50-100k/yr | A committee, over weeks or months | Distribution. Reaching buyers is expensive |
| Marketplace | A cut of transactions (take rate 5-30%) | Both sides, independently | Liquidity. Neither side shows up without the other |
| Usage / transactional | Per API call, per unit, per transaction | A developer or an ops team | Margin. Your costs scale with revenue |
| Advertising | Advertisers; users pay nothing | Media buyers, on reach | Scale. Needs enormous volume to matter |
| One-time purchase | Individuals or companies, once | One person | Growth. Every month starts from zero |
How the model changes everything downstream
This table is the reason the chapter exists. Read it as "if I pick the row, I inherit the row."
| Consumer sub | B2B SaaS | Marketplace | Usage-based | |
|---|---|---|---|---|
| Price point | $5-100/yr | $500-100k/yr | take rate | cents per unit |
| Sales motion | Self-serve, store | Self-serve → sales-led | Self-serve both sides | Self-serve, docs-led |
| Time to first revenue | Days | Weeks-months | Months | Days |
| Customers needed for $10k MRR | ~2,000 | ~20 | thousands of txns | varies wildly |
| The metric that decides survival | D30 retention | Net revenue retention | Liquidity / match rate | Gross margin |
| Churn tolerance | 5-10%/mo is normal | >2%/mo is fatal | measured per cohort | per-account |
| Marketing | Content, social, ASO | Content, outbound, events | Supply-side first | Docs, dev community |
| Support cost | Low per user, high volume | High per account | Two-sided, disputes | Technical, low volume |
| Team you'll need | Product + growth | Sales + CS | Ops + trust/safety | Infra + DevRel |
| VC-fundable? | Only at scale | Yes, classic | Yes, if liquidity proven | Yes |
| Bootstrappable? | Yes | Yes | Hard | Yes |
The numbers in row 4 are the ones to internalise. $10k/month from a consumer app means roughly 2,000 paying subscribers, which, at a generous 3% free-to-paid conversion, means ~65,000 users. The same $10k from B2B SaaS means twenty customers at $500/month. Those are completely different companies. One is a distribution problem; the other is twenty conversations.
Unit economics: the only formula you must know
Every model reduces to the same question: does a customer earn you more than they cost to acquire?
LTV = ARPU × gross margin × average customer lifetime
CAC = total sales & marketing spend ÷ new customers acquired
Three rules of thumb, widely used and worth knowing:
- LTV : CAC ≥ 3 : 1. Below that, growth burns money faster than it creates value.
- CAC payback < 12 months (consumer: < 3 months). How long until a customer has repaid what you spent to get them.
- Gross margin > 70% for it to behave like software. Below ~40% you have a services or logistics business wearing a software costume.
The trap: organic acquisition makes CAC look like zero, so founders skip the math entirely. Your time is a cost. If a channel takes 20 hours a week and produces 40 customers a month, you have a CAC, you're just paying it in the one currency you can't raise more of.
Churn, and why consumer is harder than it looks
At 5% monthly churn, average customer lifetime is 1 / 0.05 = 20 months. At 10%, it's 10 months. Consumer subscription apps routinely see 6-12% monthly churn.
That means a consumer app must replace most of its customer base every year just to stay flat. This is why Chapter 09 (the core loop) and Chapter 50 (retention) are the highest-leverage chapters in this book for consumer products, and why "we'll figure out retention later" is the single most expensive sentence in consumer software.
B2B SaaS inverts it. Good B2B has net revenue retention above 100%, existing customers expand faster than others leave, so revenue grows without a single new logo. That property is why investors pay so much more for B2B revenue.
📐 Best practice
Choose the model before the feature set. Write one sentence: "[Who] pays [how much] [how often] for [what outcome]." If you can't fill it in, you don't have a business yet, you have a project.
Model your unit economics on a single page, early. Not a 40-tab spreadsheet. Price, expected conversion, expected churn, cost to serve, cost to acquire. It will be wrong. Its job is to reveal which assumption you're betting the company on.
Find the number that decides survival, and track it from day one. Consumer: D30 retention. B2B: net revenue retention. Marketplace: match rate and repeat rate. Usage: gross margin. Everything else is secondary.
Pick a model your distribution can support. This is the most-ignored rule. If you have no audience, no sales experience and no capital, a $50k/year enterprise product is a distribution problem you cannot currently solve, no matter how good the software is.
Prefer models where the customer and the user are the same person, at least for your first product. When the buyer and the user differ (enterprise, ad-supported, parents buying for children) you're solving for two parties and the feedback loop gets much slower and noisier.
💀 Common mistakes
Copying a model from a company at a different stage. Notion is freemium with a generous free tier, because it has enormous scale and a network of templates. Freemium with no distribution is just a free product. Copy models from companies at your stage, not your aspirational one.
Assuming freemium is the safe default. Free users cost money to serve and most never convert. Freemium works when free users create value for paid ones (network effects, content, virality, word of mouth). If yours don't, you've built a charity with a paid tier.
Believing "we'll add monetization later." Retrofitting payment into a product designed to be free changes the product, breaks trust with early users, and usually arrives after the runway does. Decide how money works before you build.
Ignoring the cost to serve. AI features especially: if each user costs you $2/month in inference and you charge $5, your gross margin is 60% before you've paid for anything else. That's not a software business, that's a reseller. (Chapter 23.)
Mistaking revenue for a business. $10k in one-time sales is not $10k MRR. One-time revenue resets to zero on the first of every month. It's a real model, but you must know which one you have.
Choosing "ads" without the scale for it. Consumer ad revenue is roughly $1-20 per thousand impressions depending on geography and vertical. To make $5k a month you need millions of monthly impressions. If you don't have a credible path to that, ads are a rounding error that also degrades your product.
Building a marketplace without a plan for the cold-start side. Every marketplace fails at the same place: no buyers because no sellers, no sellers because no buyers. You must decide which side you'll subsidise or fake first, and how, before you build anything.
The professional workflow
1. WRITE THE ONE SENTENCE
"[Who] pays [how much] [how often] for [what outcome]."
2. PICK THE MODEL, EXPLICITLY
Name it. Write down why the other five are wrong for you.
3. ONE-PAGE UNIT ECONOMICS
Price · conversion · churn · cost to serve · cost to acquire
→ LTV, CAC, payback, gross margin
4. FIND THE BREAKING ASSUMPTION
Which single number, if wrong by 2×, kills this?
That's what Part I is for validating.
5. SANITY-CHECK AGAINST YOUR DISTRIBUTION
Given the customers you need and the channels you can actually
run — is this reachable? If no, change the model, not the plan.
6. DEFINE YOUR SURVIVAL METRIC
One number. Instrument it before launch (Chapter 38).
7. RE-RUN AT EVERY MILESTONE
Real numbers replace assumptions. Most early models are wrong;
the point is to notice quickly.
Tools, websites & costs
| Need | Tool | Cost |
|---|---|---|
| Unit-economics modelling | A spreadsheet. Genuinely. | $0 |
| SaaS benchmarks | OpenView SaaS Benchmarks, ChartMogul reports | Free |
| Consumer subscription benchmarks | RevenueCat State of Subscription Apps | Free, best data available for mobile |
| App revenue estimates | Sensor Tower, Appfigures, AppBrain | Free tiers |
| Indie revenue reality | Indie Hackers, MicroConf | Free |
| Public SaaS metrics | Bessemer Cloud Index | Free |
| Subscription analytics | RevenueCat, Stripe Billing, Adapty | Free tiers |
| Financial modelling | Causal, Baremetrics | $0-100/mo |
Cost of this chapter's work: $0 and about a day. It's the highest-leverage day in the book.
Alternatives & trade-offs
Hybrid models are legitimate and common. Subscription + usage overage (most AI tools). Free tier + paid teams (Figma, Notion). Marketplace + SaaS for the supply side (Shopify). Hybrids are harder to explain and harder to price, earn them once the primary model works, don't start there.
Open source + paid hosting is real (Supabase, Cal.com, PostHog) but it's a distribution strategy more than a revenue model, and it requires a genuinely useful free product plus a real reason to pay for hosting.
Services-then-product is underrated for bootstrappers: consult in the space, discover the recurring problem, productise it. Slower, lower risk, and you're paid to do your customer research.
One-time purchase is often dismissed. It suits tools with high perceived value and low ongoing cost, utilities, developer tools, plugins. No churn to manage, but no compounding either.
Trade-off summary: consumer is easy to start and brutal to retain. B2B is hard to start and wonderful to retain. Marketplaces are hardest to start and strongest once they work. Usage-based is easy to start and needs constant margin discipline.
Checklist
- I can state the one sentence: who pays, how much, how often, for what outcome
- I have named my model and written why the alternatives don't fit
- I have a one-page unit-economics model
- I know my LTV : CAC and payback period, even as estimates
- I know my gross margin, including cost to serve
- I know how many customers I need for my first meaningful revenue milestone
- I have named the single assumption that kills this if it's wrong
- I have checked the model against distribution I can actually run
- I have chosen my survival metric and know how I'll measure it
- If freemium: I can explain how free users create value for paid ones
- If AI-powered: I have computed cost per user per month (Chapter 23)
📓 Case Study: choosing a model with no audience
Project: SOLIS, a Stoic self-improvement iOS app. Solo founder, no existing audience, no capital beyond a few hundred dollars.
The model chosen: consumer subscription. $9.99/month or $49.99/year with a 3-day trial, plus a genuinely usable free tier (first lesson every day forever, first seven days fully open).
Why that model, and why not the others, the reasoning is worth walking through because it's a bootstrapper's reasoning:
- B2B SaaS was off the table on distribution grounds. It's the strongest model in the table above, and it was unreachable: no network, no sales experience, no capital for outbound. The right model you cannot distribute is the wrong model.
- Marketplace, no second side to the product. Not applicable.
- Advertising, would need millions of monthly impressions to matter, and would wreck a product whose entire promise is "no feeds, no noise." The model would have contradicted the positioning.
- One-time purchase, plausible, and rejected because the product is a 90-day course with ongoing content. Recurring value justifies recurring price.
The arithmetic, made concrete. At $49.99/year, $10k MRR needs roughly 2,400 annual subscribers. At an optimistic 3% install-to-paid conversion that's ~80,000 installs. That number, 80,000, is the real business problem, and stating it early is what made it obvious that the hard part was never going to be the code.
⚠️ Where it deviated: the cost-to-serve advantage was accidental, not designed.
Best practice is to model cost-to-serve deliberately. SOLIS ended up with near-perfect economics, content bundled in the app, no AI at runtime, all state computed on-device, ~$0/month infrastructure at launch scale, but this fell out of an engineering preference for offline-first, not a business decision. It could easily have gone the other way: the product plan's Phase 2 was an AI Mentor replying to journal entries, which would have moved cost per user from ~$0 to a real per-message number.
To its credit, the plan did cost that out before building, model tiering, daily caps, premium-gating, landing at "well under $1/user/month against $4.17-9.99 revenue." That's the right analysis. It just should have been standard from chapter one rather than triggered by a feature that happened to be expensive.
🚩 Unvalidated. SOLIS never launched. The conversion rate, the churn, and therefore the entire model are untested. What the case study demonstrates is how to choose and stress-test a model, not that this one works.
Lessons
- The business model determines the company, not the category. Two fitness apps with different models are different businesses.
- Pick a model your distribution can support. The best model you can't reach is worse than a modest one you can.
- Do the customer-count arithmetic early. "2,000 subscribers" and "20 customers" are different lives. Knowing which you're signing up for changes what you build.
- Cost to serve is a business decision, not an implementation detail. Especially with AI. Compute it before you build the feature.
- Name the assumption that kills you. Then spend Part I attacking it.
- Consumer means retention; B2B means distribution. Know which fight you've chosen.
- Freemium needs free users to create value for paid ones. Otherwise it's just expensive generosity.
- Revenue that resets monthly is a different business from revenue that compounds. Both are valid; confusing them isn't.