startup-design

# Startup Design

A structured, multi-phase skill that takes a startup idea from raw concept to validated design. It produces a complete set of markdown documents organized by domain, with built-in progress tracking so work survives session interruptions.

## How It Works

The process has 8 numbered phases executed sequentially, plus a Pre-Flight Check (Phase 0.5) and a Customer Discovery gate (Phase 3.7). Each phase produces output files and updates the progress tracker. If a session is interrupted, resume from the last completed checkpoint.

```
PRE-FLIGHT → INTAKE → BRAINSTORM → RESEARCH → [Research Gate] → CUSTOMER DISCOVERY → [Interview Gate] → STRATEGY → BRAND → PRODUCT → FINANCIAL → VALIDATION
```

### Modes

**Full Mode (default):** Execute all phases in order, including Pre-Flight and Customer Discovery. Best for thoroughly designing a startup from scratch.

**Fast Track Mode:** When the user says they want a "quick validation," "rapid assessment," or similar, or when time/budget is clearly limited, run a compressed version:
1. Phase 0.5 (Pre-Flight Check) — always run, takes 5 minutes
2. Phase 1 (Intake) — shortened to 1 round of questions; capture any prior customer conversations
3. Phase 2 (Brainstorm) — 3 variations instead of 5-8
4. Phase 3 (Research) — Wave 1 + Wave 2 only (skip customer voice and distribution deep-dives)
5. Phase 3.5 (Research Gate) — go/no-go checkpoint
6. Phase 3.7 (Customer Discovery) — if founder has 5+ prior conversations, document them; if not, run at least 3 interviews before proceeding
7. Phase 4 (Strategy) — Lean Canvas only
8. Skip Phase 5 (Brand) and Phase 6 (Product)
9. Phase 7 (Financial) — Revenue model only, Stage A (assumption-based), no full projections
10. Phase 8 (Validation) — Scorecard + top 3 experiments only

Fast Track produces fewer files but still gives the founder a clear go/no-go signal with evidence. Note in PROGRESS.md that Fast Track mode was used, so a future session can expand to full mode if the idea passes validation.

### Language

Default output language is **English**. If the user writes in another language or explicitly requests one, use that language for all outputs instead.

---

> **Reference:** Read `references/output-guidelines.md` once at the start. It defines the standard file header/footer (title, date, phase, confidence, flags), cross-phase referencing format, quality examples of good vs. bad output, and how to handle mid-process pivots.

## Phase 0: Resume Check

Before anything else, check if a `PROGRESS.md` file exists in the working directory (or a project subdirectory). If it does, read it and resume from the last incomplete phase. Tell the user: "I found progress from a previous session. You completed [phases]. Picking up from [next phase]."

If no progress file exists, start from Phase 1.

---

## Phase 0.5: Pre-Flight Check

Before investing time in the full process, run a fast sanity check — 2-3 targeted searches, 5 minutes maximum. The goal is to surface any immediately disqualifying signals so the founder knows them upfront.

**Run these three checks:**

**1. Dominant solution check** — Does a well-funded, widely-adopted solution to this exact problem already exist? Search: `"{problem domain} software"`, `"{problem} tool site:producthunt.com"`, `"{problem} app reviews"`. If a clear market leader with 10k+ customers exists, flag it immediately — this is not a reason to stop, but the founder needs to know the competitive reality before starting.

**2. Precedent failure check** — Has a company tried this exact idea and failed publicly? Search: `"{startup idea} startup failed"`, `"{problem} startup shutdown"`, `"why {product category} failed"`. Prior failures are not disqualifying — they're learnings. But unknown prior failures are landmines.

**3. Regulatory/legal instant kill** — Is there an obvious legal reason this idea cannot exist? (E.g., specific financial regulations, data privacy laws in the target geography, licensing requirements.) A quick search prevents building toward a wall.

**Output:** A short message to the founder (3-5 bullet points max) with what was found. Use this format:

```
## Pre-Flight Check

✅ No dominant incumbent found — space appears open.
⚠️  [CompanyX] tried a similar approach in 2021 and shut down in 2023.
    Key reason: [one sentence]. Worth understanding before proceeding.
✅ No obvious regulatory blockers identified for [target market].

→ Ready to proceed to intake. The above is context, not a verdict.
```

Keep it brief. This is a heads-up, not a full analysis. The project directory and PROGRESS.md don't exist yet at this point — present the findings in the conversation, then save them to `{project-name}/00-intake/preflight.md` during the Phase 1 output step, once the project directory is created.

---

## Phase 1: Intake Interview

The quality of everything downstream depends on how much context you extract now. Don't rush this — a thorough intake saves hours of misdirection later.

> **Reference:** Read `references/intake-questions.md` for the full question set (idea, founders, market, business, constraints), the hard questions that surface blind spots, and interviewing technique.

Cover all five question areas plus the hard questions — they set the tone for the entire process and signal that this is an honest assessment, not a cheerleading session. Ask 3-5 questions at a time in a conversational flow, probe vague answers, and after 2-3 rounds summarize what you've understood and ask the user to confirm or correct.

### Output

Save the consolidated intake to `{project-name}/00-intake/brief.md` with all captured information organized clearly. The project name should be derived from the startup idea (kebab-case, e.g., `pet-health-tracker`).

Create `PROGRESS.md` at the project root with: project name, start date, language, a checklist of all phases including Pre-Flight (0.5) and Customer Discovery (3.7) — mark Pre-Flight and Phase 1 complete — and a Notes secti