The same $50 of monthly contribution margin can justify a $600 acquisition budget or a $278 one. Nothing about the customer changes between those numbers; only the way the model chains margin, lifetime and payback does. That is why unit economics built as a loose set of formulas breaks the moment the business changes: new pricing, a new channel, a new vendor contract. A sturdier approach treats the calculator as an architecture problem, with modules, interfaces, versioned assumptions and tests that run before anyone moves budget.
The calculator below has eight modules. Modules 0 to 5 assemble the unit itself, Module 6 turns it into decision rules, and Module 7 tests whether the whole thing holds under pressure. Each module owns one part of the math and hands a defined output to the next.
Defining the unit everything else plugs into
Module 0 defines the unit. Leave it vague and every downstream metric inherits the vagueness. Build a "Unit Interface" as if other teams must integrate with it, because they do, with these required fields:
- Unit ID: the entity you evaluate (e.g., "paid account-month," "fulfilled order," "approved transaction," "1,000 billable requests")
- Create Event: the event that instantiates the unit (first charge succeeds, order ships, contract starts, request billed)
- Terminate Event: the event that ends the unit (churn, cancellation, inactivity threshold, contract end)
- Revenue Binding: how revenue attaches to the unit (subscription fee, take rate, AOV net of refunds, usage price)
- Cost Binding: how variable costs attach (payment fees, support hours, infra per usage, vendor fees)
- Time Index: when value and costs accrue (immediate, monthly, after onboarding, after delivery)
Take a hypothetical field service scheduling platform. Its unit is the "active customer account-month," created by the first paid invoice and terminated when the subscription is canceled. Revenue binds as the plan price plus an add-on per technician. Costs bind as SMS notifications per job, support tickets per month and mapping API calls per route, with onboarding costs front-loaded and messaging costs ongoing.
The payoff is practical. Without the interface, "CAC is too high" means three things in one meeting: one person divides by leads, another by activated accounts, a third by paying customers. The numbers differ by a factor of five, and the argument is about definitions while everyone thinks it is about spend.
Build revenue from explicit drivers and test their uncertainty
Revenue should come from a small number of deterministic drivers that can be measured and stress-tested. Three spine patterns cover most models.
- Subscription: plan price, the split between monthly and annual billing, how discounts are spread, how many customers buy add-ons and growth from upsells or extra seats.
- Transactions: average order value, the fee you take on each order, the share of started orders that actually complete and the refund rate, counted either as negative revenue or as leakage.
- Usage: billable units times price per unit. Two things bend it: how the free tier and overage charges work, and how much usage is committed by contract versus pay-as-you-go. Both decide how much modeled usage becomes real revenue.
Hybrids are common. Consider a procurement platform that sells to mid-market firms: a base fee per account-month plus a tiered fee per supplier verification, with expansion as new departments come online. Splitting the spine shows how much revenue is predictable base fee and how much rides on verification volume. That split decides where sales should push: toward accounts with heavy verification needs, or toward accounts likely to spread across departments.
Variable costs, where most models start lying
Most "unit economics" models go wrong here. They leave out costs that scale with operations because accounting doesn't label them variable. The ones that usually matter, and where they attach:
- Payment processing: percentage plus fixed fee, plus chargeback cost; attaches to transactions or billing events
- Refunds and disputes: negative revenue plus operational cost; concentrates in certain cohorts and channels
- Infrastructure and vendors: cost per call, message, lookup or GB; attaches to specific actions
- Support and onboarding: tickets or hours per unit; attaches to lifecycle stage and complexity
- Risk losses: fraud and bad debt; attaches to specific segments and channels
Attachment matters as much as amount. A fintech app pays a vendor per identity check, and approval rates vary by channel. Model verification cost per signup and you will misprice channels. The right attachment is cost per check times checks per approved customer, because some channels need several attempts per approval. Say a check costs $1.50: a channel that needs 1.2 checks per approval costs $1.80 per approved customer, while one that needs 3 checks costs $4.50. A CAC-only debate never sees that difference.
The category is growing. Andreessen Horowitz partners Martin Casado and Matt Bornstein argued in February 2020 that AI companies often run 50-60% gross margins against 60-80% or more for comparable SaaS, largely because inference and data costs scale with every unit served. Any product with a model or a data vendor inside it should expect variable costs to be the module that moves most.
The margin engine and what it says about structural health
The model's main output is contribution margin per unit: what each unit leaves after the costs it causes. Revenue alone ignores the cost to serve. Gross margin on its own often misses payment, support and vendor costs that grow with every unit. The engine gives four outputs:
- margin per unit;
- margin as a percentage;
- margin by segment (channel, plan tier, usage band);
- a timing curve showing when margin arrives compared with when costs hit.
The segment view is where the surprises are. Take a B2B data enrichment platform that sells subscriptions but pays a data provider for every lookup. Heavy users can earn less than medium users, even though they pay more per account (ARPA), if pricing ignores the vendor's per-call cost. The margin is subscription revenue per account-month, minus vendor cost (calls times cost per call), minus infrastructure and support per account-month. Once that is visible, the fixes are concrete: usage bands, "included credits" or a better vendor contract.
Blended margin can also move against every segment underneath it. Channel A carries 60% of units at $50 margin, channel B 40% at minus $5, for a blended $28. Next quarter both improve, A to $52 and B to minus $3, but the mix flips to 30/70. Blended margin falls to 0.3 × 52 + 0.7 × (minus 3) = $13.50. Statisticians know the pattern as Simpson's paradox: every segment improved and only the mix moved. A team watching only the blended line would cut the channel strategy that is working.
Turning retention into something the model can compute
A unit lives across many periods, so LTV cannot be read off a single month. It is the sum of margin over time weighted by survival probability, and it rests on three components: the cohort retention curve, margin per period (which can change as customers mature), and expansion or contraction over time, which is often decisive in B2B.
Simple churn math is a starting point. At a constant 5% monthly churn, average life is about 20 months. Discounting matters too: at a 1% monthly discount rate, $50 of monthly margin is worth $50 / (0.05 + 0.01) ≈ $833 rather than the undiscounted $1,000. That $167 gap becomes real money once it is multiplied into a CAC ceiling.
Assuming churn stays constant is also where many models fail. A team productivity tool might lose customers in waves after projects end. A single churn rate then misleads. A better model uses cohort curves shaped by the project cycle. It also lets margin per month rise after onboarding, as support costs fall. That helps with a real choice: features that get customers onto a second project (which flattens the curve) versus features that bring more sign-ups who may leave after the first project.
Acquisition cost comes out of the model too. Lifetime value caps what you can afford to pay for a unit. "Ad spend divided by customers" understates what you really pay. CAC depends on three things: spend per channel, conversion at each funnel step (visit, lead, activation, paying unit) and sales effort where sales is involved, meaning the time of sales development reps (SDRs) and account executives (AEs) plus their tools. The allowed CAC is then calculated from the margin engine and the lifetime model. Nobody picks it by feel.
Motions differ enough to need separate numbers. A B2B compliance product with both outbound and inbound sales will see inbound produce smaller accounts with faster cycles, and outbound larger accounts with higher sales cost. Retention, expansion and onboarding cost diverge as well. Set separate allowable CAC ceilings and payback targets per motion; a blended number misleads both teams.
Decision rules: ceilings, floors and caps
Once margin, lifetime and CAC describe the same unit, three kinds of rules turn the numbers into policy:
- CAC ceilings. In each segment, CAC stays below a limit calculated from margin and the target payback period.
- Margin floors. Contribution margin per unit stays above a minimum for each plan tier or usage band.
- Cost-to-serve caps. Support tickets per unit and infrastructure cost per usage unit stay within limits. If not, growth in that segment pauses until the cause is fixed.
Rebuilding a spreadsheet for every change is what kills these rules in practice, so it is worth structuring the model in a unit economics calculator that lets you swap assumptions and re-run scenario comparisons in place.
A worked example: from contribution margin to an allowable CAC
Take one unit, a paid account-month, and follow it through the chain. Revenue binding: ARPA $80 per month. Variable costs: payment fees $3, usage infra $6, support $8 and vendor calls $13, $30 in total. Contribution margin is $80 minus $30, or $50 per month, a 62.5% margin.
Now the lifetime block. At 5% monthly churn, undiscounted LTV is $50 × 20 = $1,000. A 12-month payback target allows a CAC of 12 × $50 = $600, but that leaves LTV/CAC at about 1.7. A stricter rule, LTV of at least three times CAC, caps CAC near $333, which pays back in about 6.7 months. Use the discounted LTV of $833 instead, and the 3x ceiling drops to about $278.
So one unit yields three defensible budgets, $600, $333 and $278, depending on which rule governs. The gap appears only because margin, lifetime and acquisition were computed as one chain. Pick the governing rule before the quarter starts, write it into the model, and the budget conversation becomes a lookup.
The test suite almost nobody builds
Software without tests would not ship, and a model whose rules gate real spend deserves the same standard.
Test A: Same denominator. CAC is divided by newly acquired units. Retention should be measured on that same unit.
Test B: Segments stay stable. When the channel mix changes, blended numbers change too. Segment numbers should not. If they move as well, a definition has leaked somewhere.
Test C: Timing. Compare annual prepayment with monthly billing, and onboarding costs paid up front with costs spread out. If payback timing shifts a lot, that is a reason to change pricing or packaging.
Test D: Shocks deserves its own arithmetic. Push CAC up 20%, refund and dispute rates up 10%, support tickets per unit up 15% and vendor cost per call up 25%. Run just two of those on the worked example. Vendor cost goes from $13 to $16.25, so margin falls to $46.75 and undiscounted LTV to $935. CAC goes from $333 to $400. LTV/CAC drops from 3.0 to about 2.3, below the line the plan was built on. Two plausible shocks break the rule, which means the growth plan is fragile, and the test tells you that before the budget is spent.
Beyond the tests, four failures tend to surface first, each with a recognizable signature.
Invisible variable costs: margin shrinks while revenue looks stable. You see it when infra, support and vendor cost per unit trend upward together. The fix is to model the driver and align pricing to the cost.
Segment cross-subsidy: blended margin looks fine while one channel or tier bleeds. Segment contribution margin and payback show one cohort negative. Impose channel guardrails, adjust packaging, or stop scaling the segment.
Retention illusion: the headline churn rate looks stable but LTV collapses because early-life retention, in week one or month one, worsens while later stability holds. The response is time-to-value work and an onboarding redesign.
Discount leakage: planned payback assumes list price while actual payback runs long. The discount distribution shifts and renewals happen at the lower price. Set discount guardrails, redesign packaging, and tie discounts to term length.
A spreadsheet is enough for the first 40 customers
Early-stage founders have a fair complaint about all of this. With 40 customers and three monthly cohorts, a retention curve is mostly noise, and a modular calculator with shock tests produces false precision: decimals stacked on guesses. A single sheet with price, three cost lines and a gut-check payback is faster and no less accurate, and the hours saved are better spent talking to customers.
They are right about the lifetime and acquisition modules, which need data the company does not yet have. Module 0 and the margin engine are a different matter. A unit definition costs an afternoon, and a margin that is negative per unit is negative at 40 customers and at 4,000. The modules that need history can wait; the ones that need only arithmetic cannot.
A workable rule: build the Unit Interface and margin engine on day one. Add cohort-based lifetime modeling once you have about six monthly cohorts of 50 or more units each (a threshold to tune; there is no industry standard). Add channel-level CAC modeling once any single channel carries more than a quarter of spend.
Assembling the blocks in the right order
Build in this order, so each module has its inputs before anything depends on it:
- Publish the Unit Interface (unit spec) and enforce it in reporting
- Build the margin engine with 3-6 dominant variable drivers
- Add lifetime modeling using cohort retention curves
- Add acquisition modeling with channel-specific conversion and sales effort
- Generate decision rules: allowable CAC, margin floors, cost caps
- Run the test suite monthly and after major changes
- Version assumptions and document changes
Fixed costs stay out of the unit margin engine. They belong in separate break-even and runway layers; mixing them in blurs the signal the unit is meant to give. And when a definition must change, version it and reconcile history, so last quarter's numbers stay comparable with this quarter's.
Of everything here, the Unit Interface is the part teams most want to skip, because it looks like a definitions exercise. Until finance, growth and product agree on the same Create and Terminate events, the margin engine produces three versions of the same number, and the shock tests mostly show whose version breaks first. Once the interface holds, a shock that pushes a segment below its margin floor points straight at that segment's spend plan, and the decision rules become the gate for a growth process that scales only when the unit remains structurally profitable.
For executives, the useful output is small: segmented contribution margin, the payback boundary per motion, and the result of the two worst shock scenarios. A team that cannot produce that page does not have unit economics yet, only formulas.