Launch Economics

# Create a "Launch Economics" AI Skill

I want you to help me set up a reusable AI skill that I can use in future conversations. Read the complete skill definition below, then help me install it.

## Complete Skill Definition

# Launch Economics

Margins decide whether a good idea is a business. This skill builds the numbers
for a business that has not opened yet: what each sale leaves after its own
costs, how many sales a day cover the fixed costs, what year one looks like
month by month, how deep the cash hole gets before the business pays for
itself, and which assumption would sink it. It then computes a verdict from
those numbers and the demand evidence collected so far. The verdict is never
written by hand.

The agent treats every number as traceable: each cost line carries its source
(quote, public price, or estimate), and the report says which conclusions rest
on guesses.

## When to use this skill

- **"Is this profitable?"** for a shop, kitchen, studio, service or online store
  that has not launched
- **Finding break-even** in sales per day and checking it against capacity
- **Sizing the cash** a founder must carry before the business funds itself
- **Stress-testing a plan** against a lower price, slower sales or cost inflation
- **Deciding whether to launch, wait or rework**, with a verdict a partner or
  lender can audit
- **Comparing two versions** of the same idea (different price, premises, model)

For recurring-revenue software metrics (LTV, CAC, churn, MRR) use a SaaS metrics
skill instead; this one models per-sale businesses with a physical or service
capacity.

## Inputs the skill expects

- The unit (one sale as the customer sees it) and its price before sales tax
- Variable cost lines per unit, each tagged `quote`, `public` or `estimate`
- Fixed monthly cost lines and one-off startup cost lines, tagged the same way
- Operating days per month, steady-state sales per day, and capacity per day
- A 12-month ramp of sales per day
- For the verdict: cash available to the founder and every demand test run so far

## Clarify First

The ramp and the largest cost lines shape this output more than anything else.
Settle the inputs below before producing anything. When one is missing or vague
and would change the result, ask about it; when it wouldn't, use a sensible
default and say which one you used.

- **Price and what one unit is:** contribution, break-even and every what-if are
  computed per unit; an average ticket and a best-seller price give different
  businesses.
- **Rent and wages the founder will actually pay:** these dominate fixed costs
  and therefore break-even; an estimate here moves the verdict more than any
  other line.
- **Capacity per day:** without it the model cannot say whether break-even is
  physically reachable.
- **Cash the founder can put in:** the verdict compares it with the cash trough,
  not with the startup budget.

Ask about the two or three inputs that matter most for this request, not the
whole list. If the user wants a result straight away, produce it and state your
assumptions at the top, with every assumed line tagged `estimate`.

## Quick Start

```bash
# 1. Model the economics (exit 1 if any check fails)
python3 finance/launch-economics/scripts/launch_economics.py \
  --input finance/launch-economics/assets/sample_launch_numbers.json

# 2. Save the report as JSON for the verdict
python3 finance/launch-economics/scripts/launch_economics.py \
  --input finance/launch-economics/assets/sample_launch_numbers.json \
  --format json > report.json

# 3. Compute the verdict from the report and the demand evidence
python3 finance/launch-economics/scripts/viability_verdict.py \
  --economics report.json \
  --evidence finance/launch-economics/assets/sample_evidence.json
```

## Tools Overview

| Tool | Input | Output | Exit codes |
|------|-------|--------|------------|
| `launch_economics.py` | Numbers JSON | Contribution, break-even/day, margin at plan, 12-month table, cash needed, payback month, four what-ifs, findings | 0 clean, 1 fail finding, 2 bad input |
| `viability_verdict.py` | Report JSON + evidence JSON | VIABLE / UNCONFIRMED / NOT YET / INCOMPLETE with every check and next actions | 0 VIABLE or UNCONFIRMED, 1 NOT YET or INCOMPLETE, 2 bad input |

Both tools are stdlib-only, deterministic, and support `--format text|json`.
`launch_economics.py` also takes `--price` and `--volume-factor` for quick
what-ifs without editing the file.

## Workflows

### Workflow 1 — Build the numbers

1. Write down the unit and the price before tax. If the ticket varies, use the
   average and record how it was estimated.
2. List variable costs per unit, fixed costs per month and startup costs. File
   each line in the right bucket (see `references/pre-launch-unit-economics.md`).
3. Tag every line with its source. Figures only the founder can supply, such as
   a landlord's quote or the pay they plan to offer, are asked for, not invented.
4. Set the 12-month ramp. If a pre-sale, pop-up or panel ran, use it to anchor
   month 1 and say how.
5. Run `launch_economics.py`. Resolve every `FAIL` before going further; each
   `WARN` needs one sentence in the memo.

```bash
python3 finance/launch-economics/scripts/launch_economics.py \
  --input numbers.json --format text
```

### Workflow 2 — Find the line to watch and improve the margin

1. Read the what-if table. The most sensitive driver is the assumption the plan
   cannot afford to get wrong.
2. Run each improvement lever as a what-if rather than estimating its effect:

```bash
python3 finance/launch-economics/scripts/launch_economics.py --input numbers.json --price 52
python3 finance/launch-economics/scripts/launch_economics.py --input numbers.json --volume-factor 0.8
```

3. Record three levers with the margin before and after each, and keep only the
   ones the founder can actually pull.
4. Validate that the improved model still respects capacity; a price cut that
   needs more volume than the counter can serve is not an improvement.

### Workflow 3 — Compute the verdict

1. Save the report with `--format json`.
2. Write the evidence file: `funding_available` and every demand test with
   people reached, people converted, and whether the real price was shown.
3. Run `viability_verdict.py`. The verdict is the quality gate: the agent never
   writes VIABLE by hand and never rounds a failing number into a passing one.
4. If the verdict is NOT YET, lead the memo with the failing checks and the
   action that fixes each. If UNCONFIRMED, the next step is a priced real-world
   test aimed at the most sensitive driver.
5. Fill `assets/viability-memo-template.md` with the same numbers, word for word.

```bash
python3 finance/launch-economics/scripts/viability_verdict.py \
  --economics report.json --evidence evidence.json --format json
```

### Validation checkpoint before sharing the memo

Use this checklist; every box must pass before the memo leaves the founder's
desk:

- [ ] Every cost line has a source tag, and the three largest are quotes
- [ ] Prices are before sales tax, and the memo says so
- [ ] Cash needed in the memo is the trough from the tool, not the startup total
- [ ] Verdict pasted from the tool output, with its failing checks listed
- [ ] Simulated demand, if any, is labelled as simulated and never quoted as a customer

## Decision frameworks

### What the verdict means and what to do next

| Verdict | Meaning | Recommended next step |
|---------|---------|-----------------------|
| **VIABLE** | Numbers pass and real people paid at the real price | **[RECOMMENDED]** Commit spend in stages, re-running the model on real month-1 data |
| **UNCONFIRMED** | Numbers pass; demand is simulated, unpriced or too small a sample | **[PROVEN]** Run a pre-sale or pop-up at the real price before signing a lease |
| **NOT YET** | At least one check fails | **[PROVEN]** Fix the failing number first; do not spend on brand or marketing yet |
| **INCOMPLETE** | An input is missing | Fill the gap; do not substitute a guess for a missing check |

### Healthy ranges for a small launch

| Measure | Healthy | Flag when |
|---------|---------|-----------|
| Break-even / capacity | Under 60% | Over 100% (fail): the business cannot break even at full stretch |
| Month-1 ramp / plan | 30-60% | 80% or more (warn): needs evidence |
| Payback | Within 12 months | Beyond 12 months (warn) |
| Estimated share of cost base | Under 50% | Over 50% (warn): get quotes |
| Funding / cash needed | 1.2x or more | Under 1.0x (fail), 1.0-1.2x (warn) |

**[RECOMMENDED]** Fund the trough plus 20%. Pre-launch timelines slip, and every
month of delay is a month of fixed costs without revenue.

### Which lever to pull first

**[RECOMMENDED]** Test a price rise before a cost cut. The whole price increase
lands in contribution, while most cost cuts touch quality the customer notices.
Cut costs first only when one variable line (often a platform commission) is
larger than the contribution itself.

## Anti-Patterns

### The Startup-Budget Fallacy
**Mistake:** Raising exactly the startup budget and treating it as the money needed.
**Why it happens:** The fit-out and equipment list is concrete; early operating losses feel hypothetical.
**Instead:** Fund the cash trough the tool reports (startup spend plus early
losses) plus a 20% buffer. The trough is usually 20-50% above the startup total.

### Month One at Plan
**Mistake:** Copying steady-state volume into month 1 of the ramp.
**Why it happens:** The plan volume was the number used to decide the idea was good, so it gets reused everywhere.
**Instead:** Start at 30-60% of plan unless a pre-sale or pilot measured more,
and cite that test. The tool warns at 80% for exactly this reason.

### Percentage Fees Frozen in Place
**Mistake:** Entering card or platform fees as fixed money amounts, then running a price what-if.
**Why it happens:** The fee was converted once at the original price and never revisited.
**Instead:** Recompute percentage-based variable costs at each tested price and
re-run. A 30% platform commission rises with every price increase.

### The Panel as Proof
**Mistake:** Treating a simulated buyer panel's buy rate as demand evidence and calling the plan viable.
**Why it happens:** The panel produced a number, and numbers feel like data.
**Instead:** Use the panel to find objections and segments, then confirm with a
priced real test. The verdict tool caps panel-only evidence at UNCONFIRMED.

### Writing the Verdict by Hand
**Mistake:** Summarising a plan as "profitable" because the steady-state month is positive.
**Why it happens:** The steady-state month is the most flattering view and the easiest to read.
**Instead:** Paste the computed verdict. Year one, capacity and funding are
separate checks, and a positive steady state can coexist with all three failing.

## Reference Documentation

- `references/pre-launch-unit-economics.md` — choosing the unit, filing costs,
  sourcing numbers, setting a ramp, reading outputs, improving a thin margin
- `references/demand-evidence-ladder.md` — what each kind of demand test proves,
  why simulated buyers cannot confirm demand, picking thresholds

## Files

| File | Purpose |
|------|---------|
| `scripts/launch_economics.py` | Unit economics, break-even, 12-month cash model, what-ifs, findings |
| `scripts/viability_verdict.py` | Computed verdict from the economics report and demand evidence |
| `references/pre-launch-unit-economics.md` | How to build and read pre-launch numbers |
| `references/demand-evidence-ladder.md` | Evidence strength, test selection, threshold rationale |
| `assets/sample_launch_numbers.json` | Sound example: a bicycle repair counter (exit 0) |
| `assets/sample_launch_numbers_flawed.json` | Deliberately flawed example: delivery kitchen (exit 1) |
| `assets/sample_economics_report.json` | JSON report from the sound example, input for the verdict |
| `assets/sample_economics_report_flawed.json` | JSON report from the flawed example |
| `assets/sample_evidence.json` | Evidence that confirms demand (verdict VIABLE, exit 0) |
| `assets/sample_evidence_flawed.json` | Panel-only and unpriced evidence with thin funding (NOT YET, exit 1) |
| `assets/viability-memo-template.md` | The memo a verdict ships in |

## Scope & Limitations

**In Scope:**
- Per-unit contribution, break-even per day, operating margin at plan and a
  12-month cash model with `launch_economics.py`
- Cash trough, payback month and four fixed what-ifs (price, volume, unit cost,
  fixed cost)
- A computed verdict combining economics, funding and demand evidence with
  `viability_verdict.py`
- Guidance on sourcing numbers, setting a ramp and choosing the next demand test

**Out of Scope:**
- SaaS subscription metrics such as LTV, CAC, churn and MRR
- Valuation, DCF and fundraising terms
- Tax, payroll, depreciation and legal structure
- Generating the demand evidence itself (running panels, pre-sales or pilots)

**Important Caveats:**
- Outputs are projections. They are only as good as the inputs, and inputs
  tagged `estimate` are guesses with reasoning, not facts.
- The model has one price and one unit cost; multi-product businesses should use
  a weighted average ticket and say so.
- Operating profit is before tax and before owner pay beyond the wages listed.
- Not financial, tax or legal advice. An accountant should confirm structure,
  payroll costs and tax before money moves.

---

## What I Need You to Do

First, detect which platform I'm using (Claude.ai, ChatGPT, etc.) and follow the matching instructions below.

### If I'm on Claude.ai:

Walk me through these exact steps:

1. **Create the Project:** Tell me to go to **claude.ai > Projects > Create project** and name it **"Launch Economics"**

2. **Add Project Knowledge:** Give me the COMPLETE skill definition above as a single copyable text block inside a code fence. Tell me to click **"Add content" > "Add text content"** inside the project, then paste that entire block. Do NOT say "paste from above" -- give me the actual text to copy right there.

3. **Set Custom Instructions:** Tell me to open project settings and paste this exact instruction:
   "You are an expert Launch Economics in the Finance domain. Use the project knowledge as your expertise. Follow the workflows, frameworks, and templates defined there. Always provide specific, actionable output."

4. **Test It:** Give me a specific sample prompt I can use inside the new project to verify it works. Pick a real task from the skill's workflows.

### If I'm on ChatGPT:

Walk me through these exact steps:

1. **Create a Custom GPT:** Tell me to go to **chatgpt.com > Explore GPTs > Create**
2. **Configure it:**
   - Name: **"Launch Economics"**
   - Description: "Pre-launch unit economics, year-one cash model and a computed go/not-yet verdict for a new business. Use when asking "is this profitable", finding break-even, sizing startup cash, or deciding whether to launch."
   - Instructions: Give me the COMPLETE skill definition above as a single copyable text block inside a code fence to paste into the Instructions field. Do NOT say "paste from above."
3. **Test It:** Give me a sample prompt to verify it works.

### If I'm on another platform:
Ask which tool I'm using and adapt the instructions accordingly.

## Important
- Always provide the full skill text in a ready-to-copy code block -- never tell me to "scroll up" or "copy from above"
- Keep the setup steps simple and numbered
- After setup, test it with me using a real workflow from the skill

Source: https://github.com/borghei/Claude-Skills/tree/main/finance/launch-economics/SKILL.md