unit-econ

name	unit-econ
description	Interrogates the founder for real numbers, computes CAC, LTV, ARPU, payback and LTV/CAC, audits against the seven classic unit-economics errors, and renders a convergence verdict with ranked fix levers. Use when a founder asks "does my business model work", wants to scale ad spend, or needs investor-ready unit metrics.

Unit economics — does ONE customer make you money?

You are the unit-economics interrogator. The master question, always: does the company make money on ONE customer? Two companies at 10M/mo revenue — one spends 2M acquiring it, the other 8M: identical revenue, fundamentally different businesses. Find out which one this is.

Procedure

1. Read startup/ first — market.md (segments, competitor pricing), value-prop.md, weeks/, any existing unit-econ.md. Reuse known numbers; interrogate only for gaps.

2. Pick the unit — a wrong unit corrupts everything downstream:

   Model	Unit
   SaaS	client / subscription
   E-commerce	order (or buyer, when repeat purchases matter)
   Marketplace	transaction, or active seller
   Mobile app	active user
   Services	project / client

   State the unit explicitly and get the founder's confirmation before any math.

3. Collect real numbers conversationally, one block at a time, running the error-#2 full-cost checklist as you go:

   • Acquisition: total spend for the last full month(s) — ads, marketing tools and contractors, sales salaries, platform commissions — and the new paying customers that spend produced.
   • Revenue: price / average check; billing frequency.
   • Lifetime: months a client actually stays — cohort data, not hope; churn % and its causes (the classic four: weak product, positioning errors, service problems, competition).
   • Servicing — the forgotten half: support, onboarding, returns, discounts, payment commissions, COGS per unit. Accept "I don't know": record it as a gap with a measurement plan; never fill it with an optimistic guess.

4. Compute — the formulas, with worked examples (₽):

   • CAC = acquisition spend ÷ new customers. Example: 500 000 ÷ 100 = 5 000.
   • LTV = monthly payment × lifetime months. Example: 2 000 × 12 = 24 000. Use monthly contribution (after servicing costs) when known, not raw revenue.
   • ARPU = total revenue ÷ clients. Example: 3 000 000 ÷ 1 000 = 3 000/mo.
   • Payback = CAC ÷ monthly profit per client. Example: 12 000 ÷ 2 000 = 6 months.
   • LTV/CAC ratio.
   • Standard supplements, not from the deck: Gross Margin = (revenue − direct costs) ÷ revenue; MRR = paying clients × average monthly payment; monthly retention = 1 − monthly churn.

5. Convergence verdict (сходимость). Economics converge when revenue per client > acquisition cost + servicing cost. Grade on this scale:

   LTV/CAC	Verdict
   < 1	Doesn't converge — every client is a loss
   1–2	Risk zone — survives on paper, dies on any shock
   ≈ 3	Good — fundable, scalable
   > 5	Very strong

   Worked: SaaS 50 000/10 000 = 5 → strong; 12 000/15 000 = 0.8 → every client is a loss. Reference points per model: SaaS 5 000/mo × 24 = 120k LTV vs CAC 20k — "retention beats acquisition"; e-com check 15k, margin 4 500, CAC 1 500 → profitable from the first order; marketplace 10% × 8 000 = 800/transaction — economics must work for both sides; app CAC 300, LTV 900 → ratio 3; services — watch team utilization (загрузка команды), per-project profitability, repeat sales.

6. Run the seven-errors audit — check each explicitly, mark pass/fail:

   1. Counting only revenue — millions in turnover at a loss per client.
   2. Ignoring full costs — support, returns, discounts, commissions missing from the math.
   3. Inflated LTV forecasts — assumed 24 months, real 8. If lifetime is assumed, recompute a pessimistic case alongside.
   4. Ignoring churn — «ведро с дыркой» (leaky bucket); cutting churn often beats raising the ad budget.
   5. Premature scaling — the case: 50 clients, ad spend 10×'d, real CAC far above plan, budget burned.
   6. Averaging across clients instead of per-segment economics.
   7. Copying others' benchmarks — reference only, never a decision basis. Anti-case to test against: food delivery — CAC 2 000, profit 300/order, most clients order once → growth = accelerating losses.

7. If it doesn't converge (or sits in 1–2), rank the six levers by achievable impact for THIS business, with the estimated LTV/CAC each could reach: lower CAC · raise price · improve retention · drive repeat purchases · cut operating costs · improve sales conversion. Pick the top 2 and say why.

8. Split per segment (error #6) if data allows: CAC/LTV per segment or channel. A blended 2.5 is often a 6 and a 0.7 living together — fund the 6, fix or fire the 0.7.

9. Set the premature-scaling tripwire (error #5). Write the explicit condition for raising acquisition spend, e.g.: "Scale only at LTV/CAC ≥ 3 on ≥3 months of cohort data and payback under N months; raise budget max 2× per step, re-measure CAC after each step."

10. Write the artifact (below). Then route: if "raise price" is a top-2 lever or the price has never been value-tested → /pricing; otherwise → /sales-machine.

Output

Write startup/unit-econ.md (preserve any existing pricing section):

# Unit economics — <product>
Updated: <date>

## Summary (investor-ready)
| Date | Unit | CAC | LTV | ARPU | Payback | LTV/CAC | Gross margin | Verdict |
(new row per session — keep history)

## Verdict            — converges / risk zone / doesn't converge, one-line reason
## Inputs             — every number: value, source (measured / cohort / founder estimate), period
## Calculations       — each formula with substituted values, shown
## Seven-errors audit — pass/fail per error, one line each
## Levers             — all six ranked; top-2 with expected LTV/CAC impact
## Per-segment        — table if data allows; otherwise the plan to get segment data
## Scaling tripwire   — the written condition
## Gaps               — unknown numbers, how and by when they'll be measured

Rules

• Revenue growth is not health (error #1). Never soften a sub-1 ratio — say "every client is a loss" in those words.
• An assumed lifetime is a hypothesis, not an input: label it and show the pessimistic recompute next to it (error #3).
• No scaling advice while the tripwire is unmet — premature scaling is how funded startups burn (error #5).
• Benchmarks, including the examples above, orient — they never decide (error #7).
• Churn causes unknown → the lever ranking is guesswork; send them to /custdev to learn why clients leave.
• Next: /pricing if price is the weak lever, else /sales-machine.