Startupblueprint

StartupBlueprint

Turn a startup URL, repository, or description into a decision-ready plan for how the product can acquire customers, charge, cover its costs, and reach a testable first version of sustainability.

Read references/research-playbook.md before researching. Read references/analysis-schema.md before creating the analysis JSON. Read references/financial-model.md before generating the workbook.

Resolve SKILL_DIR as the directory containing this SKILL.md. Run bundled scripts from SKILL_DIR. Write deliverables into the user's current workspace, normally under outputs/.

Workflow

1. Understand the startup

• Inspect the supplied URL, repository, landing page, pricing page, README, screenshots, or description.
• Identify the product, stage, geography, currency, primary user, economic buyer, painful job, promised outcome, delivery model, current free or paid offer, and founder's immediate objective.
• Distinguish verified product facts, public market evidence, user-supplied numbers, working assumptions, and unknowns.
• Ask one concise question only when the answer changes the economic model materially and cannot be represented safely as an editable assumption. Otherwise continue and label assumptions.
• Never inspect private analytics, billing, customer, or financial data unless the user explicitly supplies or authorizes it.

2. Research the market and business model

• Use current public evidence. Prefer official product, pricing, documentation, terms, and company pages.
• Research the current prices and packaging of at least three relevant competitors or substitutes in standard mode; aim for five to eight when the category supports it.
• Identify the most plausible customer segment, economic buyer, distribution channels, value metric, revenue streams, cost drivers, and defensible advantage.
• Treat competitor pricing as an anchor, not proof of willingness to pay.
• Link every material competitor price and market claim to a direct source with a checked date.
• Define a narrow initial ICP, buying trigger, qualification signals, anti-ICP, positioning, and the cheapest reachable distribution wedge.
• Build TAM, SAM, and a realistic 24-month SOM bottom-up only when eligible account counts and annual revenue per account are sourced or visibly labeled assumptions. Otherwise keep the values unknown and show the missing formula inputs.

3. Design monetization and pricing

• Compare at least four plausible monetization models. Always evaluate a recurring model and explicitly decide whether one-time or lifetime access is safe.
• Choose one primary model and one credible alternative to validate.
• Propose concrete tiers with target segment, monthly-equivalent price hypothesis, limits, included value, upgrade trigger, and expected paid-customer mix.
• Make free versus trial, annual discount, usage overage, and lifetime decisions explicit.
• Reject uncapped lifetime access when meaningful hosting, API, inference, data, support, or storage costs continue.
• Present prices as hypotheses until supported by transaction or customer evidence.

4. Build the financial inputs

• Capture opening free and paid users, monthly acquisition, free-to-paid conversion, direct paid acquisition, churn, variable costs, fixed costs, acquisition spend, setup revenue, and starting cash.
• Store every input as {value, status, confidence, basis, source_url} using the schema. Use status: user, public, assumption, or unknown.
• Never invent a hidden number. For a missing input, either use null with unknown or create a visible, conservative assumption and explain its basis.
• Create conservative, base, and optimistic scenarios by changing explicit drivers rather than pasting desired outputs.

5. Validate and score the plan

Write outputs/startupblueprint-analysis.json, then run:

python3 "$SKILL_DIR/scripts/prepare_plan.py" \
  outputs/startupblueprint-analysis.json \
  outputs/startupblueprint-prepared.json

The script validates evidence, ICP, market sizing, positioning, go-to-market, pricing mix, financial inputs, scenario coverage, and roadmap coverage; computes a deterministic readiness score and 12-month preview; assigns EVIDENCE_BACKED, PROVISIONAL, or INSUFFICIENT_DATA; and returns HEALTHY, FRAGILE, UNSUSTAINABLE, or INSUFFICIENT_DATA. Do not manually override its score, status, or verdict.