Startup Pricing Lab

Startup Pricing Lab

Turn a startup URL, repository, existing pricing page, or product description into a defensible monetization hypothesis. Choose a model, tier structure, and price range using current public evidence, then make the recommendation testable.

Read references/pricing-research-playbook.md before researching. Read references/analysis-schema.md before writing the analysis JSON.

Resolve SKILL_DIR as the directory containing this SKILL.md. Run bundled scripts from SKILL_DIR, while writing all outputs into the user's current workspace.

Workflow

1. Understand the product and pricing decision

• Inspect the supplied URL, repository, landing page, pricing page, README, or description.
• Identify product, stage, primary user, economic buyer, core outcome, delivery model, value frequency, geography, currency, current pricing, and launch objective.
• Separate facts, user-supplied data, observations, and assumptions.
• Ask one concise question only when a missing fact would materially change the model, such as whether the product has recurring AI costs or targets individuals versus teams. Otherwise continue with labeled assumptions.
• Never inspect private billing, analytics, customer, or financial data unless the user explicitly supplies or authorizes access to it.

2. Build the economic profile

• Determine whether value is delivered once, occasionally, repeatedly, or continuously.
• Identify ongoing costs per customer: inference/API usage, storage, data providers, support, hosting, human service, fulfillment, and payment fees.
• Identify the natural value metric: seats, usage, projects, contacts, transactions, outcomes, credits, storage, or flat access.
• Record unknown costs as unknown. Do not invent gross margin, churn, conversion, willingness to pay, revenue, or customer volume.
• Treat competitor prices as market anchors, not proof of willingness to pay for this product.

3. Research current market evidence

• Research official pricing pages for relevant direct competitors, substitutes, and adjacent products.
• Prefer official pricing, billing documentation, product limits, terms, and help pages over snippets or listicles.
• Capture the displayed currency, billing interval, annual commitment, included usage, per-seat or usage unit, free plan, trial, and checked date.
• Normalize prices only when the units are genuinely comparable. Keep taxes, regional pricing, annual prepayment, contact-sales plans, and missing data visible.
• In standard mode, benchmark at least three relevant products; aim for five to eight when the category supports it.

4. Compare monetization models

Evaluate at least four plausible candidates and always evaluate both a recurring option and a lifetime or one-time option. Consider:

• monthly and annual subscription
• one-time purchase
• lifetime deal
• per-seat subscription
• usage-based or pay-as-you-go
• credits or prepaid usage
• freemium with a paid upgrade
• hybrid base fee plus usage

Score every candidate from 0 to 5 on:

• value_alignment — Does payment cadence and unit match how customers receive value?
• buyer_fit — Does the model match how the economic buyer evaluates and budgets?
• cost_alignment — Does revenue scale safely with recurring and variable costs?
• market_evidence — Do current comparable products support this model?
• revenue_quality — Does the model support sustainable cash flow and expansion without trapping the founder?
• simplicity — Can customers understand and predict the bill?

Use the guardrails in the schema. A lifetime plan with uncapped high recurring costs or unsustainable support must be rejected even if its commercial appeal appears strong. Usage-based pricing must be rejected when usage cannot be measured reliably.

5. Design concrete pricing hypotheses

• Choose one primary model and preserve one credible alternative for testing.
• Recommend a currency, billing unit, value metric, plan count, tier names, target segment, included value, limits, upgrade trigger, trial or free-plan decision, annual discount, and price hypotheses.
• Give a low, base, and high price hypothesis when evidence supports a range.
• Use specific numbers as hypotheses, not facts. Explain the anchors and unknowns behind them.
• Keep tiers attached to real customer segments or usage transitions. Avoid feature clutter and arbitrary decoy plans.
• Make the lifetime decision explicit: VIABLE, LIMITED_TEST, NOT_RECOMMENDED, or INSUFFICIENT_EVIDENCE.
• When recommending a lifetime test, require a customer cap, usage cap where relevant, support boundary, future-feature policy, and price floor.

6. Score deterministically

Write the research and candidate hypotheses to outputs/startup-pricing-analysis.json, then run:

python3 "$SKILL_DIR/scripts/score_models.py" \
  outputs/startup-pricing-analysis.json \
  outputs/startup-pricing-scored.json

The script validates evidence, computes weighted scores, applies safety penalties and disqualifiers, chooses the best current hypothesis, and assigns the lifetime verdict. Do not manually override its ranking. If the result is weak, report that more evidence is needed.

7. Build a fourteen-day validation roadmap

• Turn the largest pricing uncertainties into experiments, not generic tasks.
• Include customer conversations, pricing-page or checkout tests, offer comparisons, upgrade-trigger checks, cost measurement, and decision reviews only where appropriate.
• Give each day one hypothesis, target segment, action, asset, metric, and decision rule.
• Prefer comparative or baseline-relative decision rules when the startup has no historical data. Do not fabricate universal conversion targets.
• Do not publish pricing, change billing, start ads, contact customers, or launch tests automatically.

8. Generate the native report

Create:

• outputs/startup-pricing-scored.json — machine-readable evidence, model scores, recommendation, and warnings.
• outputs/startup-pricing-report.md — user-facing report that opens directly in Codex and renders on GitHub.
• outputs/startup-pricing-roadmap.csv — fourteen-day pricing validation roadmap.

Run:

python3 "$SKILL_DIR/scripts/generate_report.py" \
  outputs/startup-pricing-scored.json \
  outputs/startup-pricing-report.md \
  --csv outputs/startup-pricing-roadmap.csv

Verify that every competitor price and material market claim links to a direct source. Return a clickable absolute link to the Markdown report and summarize the recommended model, base price hypothesis, and lifetime verdict.

Report order

1. Pricing verdict
2. Recommended monetization model
3. Proposed tiers and price hypotheses
4. Monthly, annual, one-time, lifetime, and usage comparison
5. Lifetime decision and guardrails
6. Competitor pricing benchmark
7. Value metric and upgrade path
8. Pricing-page copy direction
9. Fourteen-day validation roadmap
10. Evidence, limitations, and unknowns

Modes

• quick — Use available evidence, research up to three comparables, and produce a provisional recommendation.
• standard — Research five to eight relevant products, compare at least four models, and build the complete roadmap.
• deep — Broaden competitor and substitute coverage, inspect regional or segment differences, and add contradiction checks.
• audit — Evaluate an existing pricing page and current plans before proposing changes.
• pre-launch — Design an initial pricing hypothesis for a product without customers or analytics.
• lifetime-check — Focus on whether a lifetime or one-time offer is economically safe and how to constrain it.

Use standard by default.

Safety and quality bar

• Never present a price as mathematically optimal without real demand and transaction evidence.
• Never infer willingness to pay solely from competitor pricing, social engagement, or stated interest.
• Never invent costs, margins, churn, conversion, customer counts, or revenue.
• Reject uncapped lifetime pricing when meaningful recurring costs or support obligations continue indefinitely.
• Avoid dark patterns, hidden charges, fake scarcity, misleading crossed-out prices, or fabricated discounts.
• Keep existing customers, migrations, taxes, refunds, contracts, and legal terms visible when auditing a live business.
• Do not modify pricing pages, billing systems, Stripe products, checkout settings, or customer subscriptions without a separate explicit request and approval.
• End with a decision the founder can test and reverse, not an unsupported claim of certainty.