Most teams treat unit economics as a set of formulas. That’s why their models break the moment the business changes: new pricing, new channels, a new cost structure, a new onboarding motion, or a new product line. A more durable approach is to treat unit economics as an architecture problem: you build modules, you define interfaces, you version assumptions, and you run "tests" before you deploy changes.
The structure here is a blueprint: components, interfaces, failure modes, and test suites. The goal is a unit economics system that stays accurate while your product evolves. The calculator is built as eight modules, each owning one part of the math and handing a defined output to the next. 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.
Defining the unit everything else plugs into
If your unit is unclear, every downstream metric becomes ambiguous. 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)
In a different industry, a field service scheduling platform, that interface fills in as follows:
- Unit ID: "active customer account-month"
- Create event: "first paid invoice"
- Terminate event: "subscription canceled"
- Revenue binding: plan price per month + add-on per technician
- Cost binding: SMS notifications per job + support tickets per month + mapping API calls per route
- Time index: onboarding costs front-loaded; variable messaging costs ongoing
Why this helps: it prevents arguments like "CAC is too high" when one person means per lead, another means per activated account, and a third means per paying customer.
Revenue as a deterministic spine rather than a guess
Revenue in unit economics should be built from a small number of deterministic drivers that can be measured and stress-tested, and three spine patterns cover most models.
Pattern A: Subscription spine
- Plan price
- Billing frequency mix (monthly vs annual)
- Discount rate distribution
- Add-on attach rate
- Expansion rate (upsells/seats)
Pattern B: Transaction spine
- Average order value (AOV) or average transaction value
- Take rate / commission
- Completion rate
- Refund rate (as negative revenue or leakage)
Pattern C: Usage spine
- Billable usage units per customer
- Price per unit
- Free tier and overage behavior
- Contracted commits vs pay-as-you-go mix
Consider a procurement SaaS with multi-tier packaging. A procurement platform sells to mid-market firms. It offers a base subscription plus usage-based fees for supplier verifications. The revenue spine is a base fee per account-month, verification volume per account-month, a tiered fee per verification, and expansion as new departments come online over time. Decision enabled: you can separate revenue that comes from predictable base fees from revenue tied to variable verifications, then decide whether to push sales toward accounts with high verification needs or toward accounts with broad departmental adoption.
Variable costs, where most models start lying
Most "unit economics" models fail by excluding costs that scale operationally, even if they’re not labeled variable in accounting. The variable costs that commonly matter, and how they attach, include:
- Payment processing: % + fixed fee, plus chargeback cost; attaches to transactions or billing events
- Refunds / disputes: negative revenue and operational cost; attaches to certain cohorts and channels
- Infrastructure: cost per event/call/minute/GB; attaches to usage
- Third-party vendors: per lookup, per message, per verification; attaches to specific actions
- Support and onboarding: tickets/hours per unit; attaches to lifecycle stage and complexity
- Risk losses: fraud and bad debt; attaches to specific segments and channels
Take identity verification in a fintech onboarding flow. A fintech app pays a vendor per identity check, and approval rates vary by channel. If you model verification cost per signup rather than per approved customer, you will misprice channels. The correct attachment is cost per verification times verifications per approved unit, accounting for the fact that some channels require multiple attempts and therefore a higher verification count. Decision enabled: channel guardrails become risk-adjusted and cost-adjusted, rather than "CAC-only" debates.
The margin engine and what it says about structural health
Your model’s central output should be contribution margin per unit, not revenue and not gross margin in isolation. The margin engine’s output set covers:
- Contribution margin per unit (absolute)
- Contribution margin percentage
- Margin by segment (channel × tier × usage band)
- Margin timing curve (when margin arrives vs when costs hit)
Take a B2B data enrichment platform. The platform sells subscriptions but pays per enrichment call to a data provider. High-usage customers can be less profitable than mid-usage customers, even at higher ARPA, if pricing is not aligned to the vendor cost curve. The margin logic is subscription revenue per account-month, minus enrichment vendor cost per account-month (calls × cost per call), minus infra cost per account-month, minus support cost per account-month. Decision enabled: you can introduce usage bands or "included credits," or renegotiate vendor contracts, because the margin engine makes the unit’s structural health visible.
Turning retention into something the model can compute
LTV is not a single number. It’s the sum of margin over time weighted by survival probability, and it rests on a few components:
- Cohort retention curve (survival function)
- Margin per period (which can change as customers mature)
- Expansion/contraction over time (optional but often critical in B2B)
Take a team productivity tool with "seasonal retention." It sees churn spikes after project completion cycles, so cohorts have periodic drop-offs and a simplistic churn model fails. A better approach models retention with cohort curves that reflect the project lifecycle, lets margin per period rise after onboarding as support cost declines, and computes LTV as discounted margin over survival. Decision enabled: the team can weigh features that encourage multi-project adoption, which stabilizes retention, against features that increase acquisition volume, which may churn after the first project.
Acquisition cost is an output, not an input
CAC is not just "ad spend divided by customers." It’s a system that depends on funnel conversion, channel mix, and sales effort, with a structure of its own:
- Spend per channel
- Conversion rates per funnel stage (visit → lead → activation → paying unit)
- Sales effort cost (if sales-assisted): SDR time, AE time, tools
- Payback boundary and allowable CAC output (computed from margin engine + lifetime model)
Consider a B2B compliance product with outbound plus inbound. Inbound produces smaller accounts with faster sales cycles, while outbound produces larger accounts with higher sales cost. Modeled correctly, CAC_inbound is not CAC_outbound, retention and expansion behavior differ by segment, and onboarding cost profiles diverge as well. Decision enabled: you can set separate allowable CAC ceilings and separate payback targets per motion, rather than forcing a blended number that misleads both teams.
Where the calculator starts telling you what to do
This is where you turn metrics into policy, through three rule types that prevent unprofitable scale. Rule 1, Allowable CAC ceilings: for each segment, CAC must stay below a ceiling derived from margin and target payback. Rule 2, Margin floors: contribution margin per unit must stay above a minimum threshold per tier or usage band. Rule 3, Cost-to-serve caps: support tickets per unit and infra cost per usage unit must remain within bounds; otherwise growth is paused until the driver 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.
The test suite almost nobody builds
If you treat unit economics as architecture, you also need tests, like software. Test A: Denominator consistency. The CAC denominator equals the unit create event, and the retention denominator equals the same unit. Test B: Segment invariance. If you change channel mix, blended metrics change, but segment metrics remain coherent. Test C: Shock tests. Push CAC +20%, refund/dispute rate +10%, support tickets per unit +15%, and vendor cost per call +25%. If any shock breaks margin floors or payback boundaries, your growth plan is fragile. Test D: Timing tests. Compare annual prepay against monthly billing, and onboarding cost front-loaded against spread. If payback timing changes enough, it warrants a pricing or packaging shift.
What breaks first, and how you spot it
Some failures surface before others, and each has a signature. The first is invisible variable costs: margin shrinks while revenue looks stable; you detect it when infra cost per unit, support cost per unit, and vendor cost per unit trend upward, and you fix it by modeling the driver and aligning pricing to the cost. The second is segment cross-subsidy: blended margin looks fine while one channel or tier is bleeding; segment contribution margin and payback show one cohort negative, and the fix is to impose channel guardrails, adjust packaging, or stop scaling the segment.
The third is the retention illusion: the churn metric looks stable but LTV collapses because early-life retention worsens (week-one or month-one) even as later stability holds; the response is to focus on time-to-value and redesign onboarding. The fourth is pricing leaking through discounting: planned payback assumes list price while reality shows long payback; the discount distribution shifts and renewals happen at lower price, so you set discount guardrails, redesign packaging, and tie discounts to term length.
Assembling the blocks in the right order
- 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
This approach scales: it works whether you’re early-stage or operating multiple products, because modules can be swapped as the business evolves.
Awkward questions about where the model stops
What makes this "architecture" approach better than a normal spreadsheet? It’s modular and testable. You define unit interfaces, attach costs and revenue deterministically, segment consistently, and run shock tests before scaling decisions.
How do I pick the right variable costs to model first? Start with the largest costs that scale with units: payment leakage, infra tied to usage, vendor per-action fees, and support/onboarding effort. Keep it to 3–6 drivers initially.
How do I keep teams from changing definitions and breaking comparability? Publish a unit spec and treat it as a contract. If the definition must change, version it and run historical reconciliation so you know what changed and why.
How do I stop unprofitable channels without killing growth? Use allowable CAC ceilings per segment. If a channel exceeds the ceiling, you either improve conversion, improve retention, improve margin, or pause spend. The model tells you which lever has the strongest impact.
Do I ever include fixed costs in unit economics? Not inside the unit margin engine. Fixed costs belong in separate break-even and runway layers. Unit economics is about scalable economics; mixing fixed costs blurs the signal.
What’s the most important output to show executives? Segmented contribution margin and payback boundaries, plus a small set of shock-test scenarios. That’s what prevents growth plans from being built on brittle assumptions.
Start with the unit interface and the rest follows
Unit economics becomes resilient when you treat it as architecture: define a unit interface, build deterministic revenue and variable cost blocks, compute contribution margin as the central health signal, model lifetime value from cohort behavior, and enforce decision rules with guardrails. Add a test suite (shock tests, denominator checks, timing checks) and you stop relying on static spreadsheets that quietly rot. The result is a model that stays usable as your business changes, and a growth process that scales only when the unit remains structurally profitable.