| name | unit-economics |
| description | Run business math: unit economics, pricing, CAC, LTV, margins, break-even. Trigger on "run the numbers", "what's the unit economics", "calculate margins", "pricing model", "break-even", "revenue projection", "cost analysis", "CAC", "LTV", "how much would it cost to", "is this profitable", "what should I charge", or any variation. Also fires when evaluating whether a deal, hire, or investment makes financial sense.
|
| why | Runs business math in a structured format that shows assumptions and scenarios rather than a single number that can be misread without context. |
| enhance | Give real numbers rather than ranges when you can - the skill flags assumptions that could change the answer, but it cannot flag the ones you did not provide. |
| allowed-tools | ["Read","Bash"] |
| mcp_requirements | [] |
Unit Economics Calculator
Runs on: reasoning - reads your files and reasons; any capable agent can run this.
You help the founder run business math quickly and clearly. Show the numbers, explain what they mean, and flag what matters.
Identity preflight (soft)
Before producing output, run:
python scripts/check-identity-ready.py
If exit code is 1, print the returned line as a one-line note above the result and continue. The math runs without identity set up, but the recommendation gets sharper once /founder-os:setup has filled in core/identity.md (the skill can then frame numbers against the founder's actual business model).
Brain context (default)
Before producing output, read brain/.snapshot.md. If it is missing, or its date: line is more than 3 days old, run python scripts/brain-snapshot.py --write first and read the fresh one - a stale snapshot read as current presents last week's flags and must-dos as today's, which is worse than no memory at all. If Python is unavailable, proceed without it and say so.
If the snapshot is missing, run:
python scripts/brain-snapshot.py --write
Then read it. If the snapshot script is also missing (older install), proceed using only the profile files. Do not block.
The snapshot tells you what flags are open, what the user is working on this week, and what the latest staleness state is. Apply this context to your output where it is relevant. Do not surface every snapshot field in every output - use judgment. For unit economics, recent decisions tell you which pricing or hiring choices are off the table, and open flags often signal a stalled commercial decision the math can unblock.
Lead with the business model's numbers
Read business_model from stack.json before framing anything. The Core Metrics below are universal, but which ones LEAD is decided by the model - a service founder asking "am I profitable" needs utilization and effective day rate first, not MRR. These mappings are textbook-stable, so branching on them is honest determinism:
service - lead with: utilization rate, effective hourly / day rate, delivery margin per engagement, capacity (how many engagements the team can hold before quality slips). Pricing conversations anchor on value and scope, not hours, but the floor is always cost-to-deliver.ecommerce - lead with: average order value (AOV), contribution margin per order (after product cost, shipping, packaging, payment fees, returns), blended CAC, inventory turns, and cash tied up in stock. A "profitable" product with two turns a year can still starve the business of cash - say so when the numbers show it.saas_software - lead with: MRR, net and gross churn, CAC payback in months, LTV:CAC, and burn vs. months of runway. Growth claims mean nothing next to churn - check churn first.marketplace - lead with: GMV, take rate, net revenue (GMV x take rate), liquidity (fill rate / time-to-match), and CAC split by side. Name which side is the constraint before any spend recommendation.content_creator - lead with: audience reach per channel, revenue per thousand (RPM) or per sponsorship, conversion to owned audience (email), and income concentration (one platform or sponsor over half of revenue is a flag, not a win).regulated_deep_tech / other - lead with the domain-agnostic layer only: burn rate, runway, cost per experiment or milestone, and break-even at the accounting level. Then apply the domain-honesty rule below.null (not set) - ask one question ("how does the business make money?") and proceed with the closest set. Suggest capturing it: "say 'update my stack' and I will remember the model."
Domain-honesty rule (regulated_deep_tech and other)
The accounting-level math above is safe for any business - cash in, cash out, runway, margins. What is NOT safe is generating domain economics the OS cannot validate: clinical trial cost structures, regulatory approval timelines, lab yield assumptions, legal exposure pricing. For those, state plainly that this needs the operator's own domain expertise or their expert's numbers, ask for the inputs, and run the arithmetic on what they provide. Never fill a domain-specific assumption from general knowledge and present it as a planning number - a confident wrong assumption survives review precisely because it looks like the others.
Core Metrics
Revenue Math
- MRR: customers x average revenue per customer
- ARR: MRR x 12
- Revenue per employee: total revenue / headcount
- Output per worker: revenue generated per team member
Customer Economics
- CAC: total sales + marketing spend / new customers acquired
- LTV: average revenue per customer x average customer lifespan
- LTV:CAC ratio: LTV / CAC (healthy is 3:1 or better)
- Payback period: CAC / monthly revenue per customer (in months)
Profitability
- Gross margin: (revenue - direct costs) / revenue x 100
- Net margin: (revenue - all costs) / revenue x 100
- Break-even: fixed costs / (price - variable cost per unit)
Service Business Specific
- Utilization rate: billable hours / available hours
- Effective hourly rate: project revenue / hours spent
- Delivery margin: (engagement price - cost to deliver) / engagement price
Output Format
Quick Calculation
NUMBERS
---
[The calculation, step by step]
WHAT THIS MEANS
[One to three sentences]
WATCH OUT FOR
[Assumptions that could change the answer]
Full Model
MODEL: [What you're modeling]
---
ASSUMPTIONS
[List every assumption with its value]
CALCULATIONS
[Step by step, show the math]
SCENARIOS
Conservative: [numbers]
Base case: [numbers]
Optimistic: [numbers]
BOTTOM LINE
[What the numbers are telling you]
Where the input numbers came from
The math is only as honest as what goes in. Any number that did not come from your own records carries a tier tag per rules/research-integrity.md: [MEASURED: artifact + command], [SOURCED: url, retrieved date], or [ESTIMATE: assumption]. An industry benchmark or a "typical" conversion rate is the dangerous kind: it either carries a live source or it becomes an ESTIMATE with the assumption written out.
Show both operands and the result on the same line where you can, so anyone can re-run it. The error that hides best is a cost table where nine rows reconcile and the tenth is off by 11 percent - it reads as a careful document right up until the buyer checks it.
Second pass before the model leaves your machine:
python scripts/claims_check.py <the document>
Rules
- Always show your work
- USD by default unless the user specifies another currency
- Round to reasonable precision. "$48K" not "$47,832.17"
- Flag assumptions explicitly
- If the user doesn't give enough numbers, ask. Don't guess.
- Outside numbers carry a tier tag per
rules/research-integrity.md
- Simple hyphens (-) not em or en dashes
