diff --git a/.claude/agents/semble-search.md b/.claude/agents/semble-search.md new file mode 100644 index 000000000..cb0243f59 --- /dev/null +++ b/.claude/agents/semble-search.md @@ -0,0 +1,28 @@ +--- +name: semble-search +description: Code search agent for exploring any codebase. Use for finding code by intent, locating implementations, understanding how something works, or discovering related code. Prefer over Grep/Glob/Read for any semantic or exploratory question. +tools: mcp__semble__search, mcp__semble__find_related, Read +--- + +Use the semble MCP tools only — do **not** invoke the `semble` CLI via Bash. + +## Tools + +- `mcp__semble__search(query, repo, top_k?, mode?)` — natural-language or symbol query against a codebase. `repo` is a local path or `https://` git URL; the index is cached for the session. +- `mcp__semble__find_related(file_path, line, repo, top_k?)` — nearest-neighbor expansion from a known hit. Pass `file_path` and `line` exactly as returned by a prior `search`. +- `Read` — open returned files when the chunk lacks enough context. + +`mode` defaults to `hybrid` (best for most queries). Use `semantic` for pure intent search; `bm25` for keyword/symbol-heavy queries. + +## Workflow + +1. Call `mcp__semble__search` with a natural-language description of intent ("save model to disk", "authentication flow") or a symbol name. Always pass `repo` — the absolute path of the project root, or a git URL. +2. Read full files only when the returned chunk is insufficient. +3. Optionally call `mcp__semble__find_related` with a promising hit's `file_path` and `line` to discover related implementations and callers. +4. If `mcp__semble__search` returns no relevant hits after 2-3 query variations, return the empty result rather than substituting another search tool - the agent has only the semble + Read tools by design. + +## Rules + +- MCP only. The `semble` CLI is off-limits in this agent. +- Always pass `repo` explicitly; do not rely on a default index. +- Report results as `file_path:line` so the caller can navigate. diff --git a/.claude/rules/lean-ctx.md b/.claude/rules/lean-ctx.md deleted file mode 100644 index a11724947..000000000 --- a/.claude/rules/lean-ctx.md +++ /dev/null @@ -1,34 +0,0 @@ -# lean-ctx — Context Engineering Layer - - -PREFER lean-ctx MCP tools over native equivalents for token savings: - -## Tool preference: -| PREFER | OVER | Why | -|--------|------|-----| -| `ctx_read(path, mode)` | `Read` / `cat` | Cached, 10 read modes, re-reads ~13 tokens | -| `ctx_shell(command)` | `Shell` / `bash` | Pattern compression for git/npm/cargo output | -| `ctx_search(pattern, path)` | `Grep` / `rg` | Compact, token-efficient results | -| `ctx_tree(path, depth)` | `ls` / `find` | Compact directory maps | -| `ctx_edit(path, old_string, new_string)` | `Edit` (when Read unavailable) | Search-and-replace without native Read | - -## ctx_read modes: -- `auto` — auto-select optimal mode (recommended default) -- `full` — cached read (files you edit) -- `map` — deps + exports (context-only files) -- `signatures` — API surface only -- `diff` — changed lines after edits -- `aggressive` — maximum compression (context only) -- `entropy` — highlight high-entropy fragments -- `task` — IB-filtered (task relevant) -- `reference` — quote-friendly minimal excerpts -- `lines:N-M` — specific range - -## File editing: -Use native Edit/StrReplace if available. If Edit requires Read and Read is unavailable, use ctx_edit. -Write, Delete, Glob → use normally. NEVER loop on Edit failures — switch to ctx_edit immediately. - -## Proactive (use without being asked): -- `ctx_overview(task)` at session start -- `ctx_compress` when context grows large - \ No newline at end of file diff --git a/.github/actions/setup-hugo/action.yml b/.github/actions/setup-hugo/action.yml index 44c7c9695..5d017aad2 100644 --- a/.github/actions/setup-hugo/action.yml +++ b/.github/actions/setup-hugo/action.yml @@ -60,6 +60,17 @@ runs: ${{ runner.os }}-hugo-${{ inputs.environment }}- ${{ runner.os }}-hugo- + # Runs after cache restore so stale-cache clearance isn't reverted. + - name: Check Node runtime for PostCSS compatibility + shell: bash + run: | + bin/check-node-runtime + case $? in + 0) echo "✓ Node runtime OK — continuing with cache restore" ;; + 1) echo "⚠️ bun detected — asset cache cleared, PATH adjusted" ;; + 2) echo "❌ bun detected but real Node.js not found — build may fail" ;; + esac + - name: Build Hugo site run: PATH="./node_modules/.bin:$PATH" bin/hugo-build shell: bash diff --git a/.github/workflows/_hugo.yml b/.github/workflows/_hugo.yml index 5294ac98f..0bd5b959c 100644 --- a/.github/workflows/_hugo.yml +++ b/.github/workflows/_hugo.yml @@ -73,6 +73,19 @@ jobs: restore-keys: | ${{ runner.os }}-hugo-assets- + # Verify node runtime and clear stale cache if bun→node symlink is active. + # Runs after cache restore so the stale-cache clearance isn't reverted. + # Prevents PostCSS failures when production plugins (PurgeCSS, cssnano) + # encounter bun, which can also corrupt the asset cache with broken output. + - name: Check Node runtime for PostCSS compatibility + run: | + bin/check-node-runtime + case $? in + 0) echo "✓ Node runtime OK — continuing with cache restore" ;; + 1) echo "⚠️ bun detected — asset cache cleared, PATH adjusted" ;; + 2) echo "❌ bun detected but real Node.js not found — build may fail" ;; + esac + - name: Build with Hugo run: | PATH="./node_modules/.bin:app/bin:$PATH" hugo \ diff --git a/.gitignore b/.gitignore index 89d5f897c..fcad1ceb2 100644 --- a/.gitignore +++ b/.gitignore @@ -112,3 +112,4 @@ docs/projects/**/sprint-*-coordinator-report.md docs/projects/**/sprint-*-verification-report.md docs/projects/**/*-coordinator-report.md docs/projects/**/*-verification-report.md +.grepai/ diff --git a/.skills/course-lesson-review-sam/SKILL.md b/.skills/course-lesson-review-sam/SKILL.md new file mode 100644 index 000000000..95fc613c4 --- /dev/null +++ b/.skills/course-lesson-review-sam/SKILL.md @@ -0,0 +1,156 @@ +--- +name: course-lesson-review-sam +description: Run a Sam-perspective customer-research review on a draft course lesson. Use this skill whenever the user asks to review a lesson from Sam's perspective, check a lesson for ICP fit, validate that a lesson works for non-technical founders, or mentions `/course-lesson-review-sam`. Triggers on phrases like "Sam review", "review this lesson", "check this for Sam", "ICP review", "customer lens review", or any request to validate a course lesson against the target audience. +--- + +# Course Lesson Sam-Review + +Run a Sam-perspective customer-research review on a draft lesson. Channels Sam beat-by-beat with verbatim reactions, friction points, glossing gaps. + +## Pre-loaded context + +### Project docs (what we're reviewing against) + +1. **PRD** — `.agent/prd/PRD.md` — formal product requirements: 5-module architecture, 15 quality gates, artifact chain, Sam ICP. Every lesson must advance Sam toward the course promise. +2. **5-Sam Validation Pilot** — Planned but NOT YET EXECUTED. The current simulation learnings (40.11) are imputed, not field-validated. Real Sams may stall where the simulation didn't predict. Be aware that all simulation findings are provisional — do not treat them as proven. + +### Canonical spec (what the lesson SHOULD match) + +1. **30.03 §2 — 8-part template** — `docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.03-course-format-requirements-for-creators.md` §2 (the non-negotiable 8-part template: Hook → Outcome → Concept → Visual → Do-Now → Error → Reflection → Bridge) +2. **30.03 §1 — design principles** — §1.1-1.6 (single outcome, time cap, microlearning structure, self-paced, mobile-friendly, word count bands) +3. **30.03 §5 — content spec** — §5.1-5.3 (course-level elements, per-lesson elements, micro-copy constraints, NN/g F-pattern rules) +4. **30.03 §4 — engagement** — §4.1-4.8 (immediate win, attention cycle, B=MAP, Zeigarnik, progress visibility, language, navigation) + +### Sam profile (who we're reviewing FOR) + +5. **Sam profile (course ICP)** — `docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.06-sam-customer-journey-report-2026-06.md` (first-time non-technical founder, no PM background, no burn history, 2-4 hr/week, ~$20K savings, reads on phone, intimidation + first-timer enthusiasm) +6. **Sam simulation learnings** — `docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.11-sam-simulation-pilot-lessons-2026-06.md` (5 themes from beat-by-beat simulation: "I don't have to write code" trust gate, catalogue-my-mistake pattern, measurable success criterion, UI-cue gap, decision-aid-in-one-sentence) +7. **Voice guide** — `docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md` (banned words, anti-AI structural patterns, the "who"/"show"/"coffee" tests) + +### Canonical v2 examples (what a passing lesson looks like) + +8. **Pilot Lesson 1.2a** — `content/course/tech-for-non-technical-founders-2026/smoke-test-build-page/index.md` (~870w, agnostic-tool framing, Mixo as worked example) +9. **Pilot Lesson 1.2b** — `content/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/index.md` (~640w, heavy gloss pass) + +**DO NOT reference v1 long-form chapters as style examples.** v1 chapters are 2,000-4,500 words and do NOT follow the 8-part template. Only the 2 pilot lessons are canonical v2 examples. + +### Sam's profile card (quick reference) + +| Attribute | Detail | +|---|---| +| **Role** | Founder & CEO, B2B SaaS | +| **Age** | 38 | +| **Tech literacy** | Can read a Stripe invoice, cannot read a GitHub commit | +| **Burn history** | NONE — this is Sam's FIRST venture. No prior devshop experience. | +| **PM background** | NONE — never worked in product management | +| **Current state** | Has runway, has an idea, has NOT validated anything yet | +| **Emotional load** | Intimidation ("everyone seems to know things I don't"), first-timer enthusiasm ("this course will finally make it clear"), fear ("what if I pick wrong?") | +| **Reading mode** | Skim-first, time-poor. Reads H2 headings on phone during commute before committing. Wants specific numbers, not vague promises. | +| **Trust trigger** | "This person knows I'm coming in cold and doesn't judge me for it." | +| **Trust killer** | Jargon without explanation. Too many choices. Being told to "figure it out." | + +## The 6 tests + +Run all 6 tests on the draft lesson. For each test, produce: +- A verdict (PASS / PARTIAL / FAIL) +- The specific line or section that triggered the verdict +- A Sam-character verbatim reaction (how Sam would actually react in his head) +- A priority fix (HIGH / MEDIUM / LOW) + +### Test 1: 3-second hook test + +Can Sam tell what this lesson does and why he should care within the first 2 sentences? + +- Read the hook (first 1-3 sentences after the course-frame callout) +- If the hook is a narrative vignette longer than 3 sentences, it FAILS +- If the hook uses "we" language without naming Sam's pain, it FAILS +- If Sam can't picture what tangible thing he'll walk away with after reading the hook, it FAILS + +Sam's likely reaction to a bad hook: opens lesson, scrolls past 4 paragraphs, thinks "I don't know what this is for," closes tab. + +### Test 2: Glossing audit + +Every term Sam doesn't know — decoded at first mention? + +Scan the entire lesson body. Flag every technical term and check: +- Is it glossed at first mention with a one-sentence plain-English definition? +- Is the gloss in parentheses right next to the term, not in a footnote or sidebar? +- Filter for: MVP, PMF, ICP, CTA, DPA, ARR, MRR, SOC2, HIPAA, API, RLS, JWT, OAuth, SDK, CI/CD, CMS, DNS, SSL, JSON, CSV, HTML, CSS, JS, SQL, CRUD, REST, GraphQL, webhook, endpoint, deploy, staging, production, migration, ORM, framework, runtime, SDK, hero section, incognito mode, headless CMS, CDN, reverse proxy + +For each unglossed term, Sam's reaction: "I keep nodding but I don't know what half of these mean." + +### Test 3: Progressive disclosure + +First 30% orients Sam; thresholds/metrics arrive only when Sam acts on them. + +- Does the first 30% of the lesson body (after the course-frame callout, before the "Do this now") ONLY orient Sam? +- Do thresholds, decision numbers, scoring rubrics appear only in or after the action section? +- If a scoring table or decision threshold appears in the first 30%, it FAILS + +Sam's reaction to bad progressive disclosure: "There's a 40% threshold and a 7/10 score and a $300 budget and I haven't even been told what I'm building yet." + +### Test 4: Tool-paralysis check + +Single golden path or named alternatives? + +- Does the lesson recommend ONE primary tool with exactly ONE named fallback? +- If there's a comparison table with 4+ options, it FAILS +- If Sam has to make a tool choice before the action steps, it FAILS + +Sam's reaction to tool paralysis: "Mixo vs Carrd vs Lovable vs Framer — which one? What if I pick wrong? I'll come back to this later." (Never comes back.) + +### Test 5: Confidence-to-act check + +Sam knows what to do next with no remaining ambiguity? + +- After reading the entire lesson, can Sam name the next step without re-reading? +- Is there an observable success check? +- Is there a concrete "If blocked" escape valve? +- If any of these three is missing or vague, it FAILS + +Sam's reaction to ambiguity: "OK... I think I'm supposed to build something? With what? How do I know if it worked?" + +### Test 6: Off-ICP drift check + +Any sentence that reads as written for a developer, PM, or scarred founder? + +Scan every sentence and ask: +- Would a first-time founder who's never hired a devshop understand this? +- Would someone with zero PM background follow this? +- Does any sentence assume the reader has been burned before? +- Does any sentence use "your devshop" or "your last agency" or "the team you fired"? + +For each sentence that fails, Sam's reaction: "This is written for someone who's been through this before. I haven't." + +## Output format + +Always produce this exact output structure: + +``` +## Sam Review — [Lesson Slug] + +### Overall: [PASS / PARTIAL / FAIL] ([N]/6 tests passed) + +### Beat-by-beat + +| # | Test | Verdict | What triggered it | Sam's reaction | Fix priority | +|---|---|---|---|---|---| +| 1 | 3-second hook | PASS/FAIL | "exact quote from lesson" | "Sam's verbatim reaction" | HIGH/MED/LOW | +| ... | ... | ... | ... | ... | ... | + +### Priority fix list + +1. **[HIGH/MED/LOW]** [specific fix instruction] +2. ... + +### Verbatim Sam quotes + +- "[what Sam would actually say to a friend about this lesson if it were a draft]" +``` + +## What NOT to do + +- Do NOT critique the lesson as a technical reviewer — ONLY channel Sam +- Do NOT suggest structural rewrites that serve SEO or "best practices" — Sam doesn't care about those +- Do NOT use "the learner would benefit from" language — say "Sam wouldn't understand this" +- Do NOT grade on word count alone — a 700-word lesson that passes all 6 tests is fine for Sam diff --git a/.skills/course-lesson-validate/SKILL.md b/.skills/course-lesson-validate/SKILL.md new file mode 100644 index 000000000..91bc9cc8c --- /dev/null +++ b/.skills/course-lesson-validate/SKILL.md @@ -0,0 +1,184 @@ +--- +name: course-lesson-validate +description: Run pre-commit mechanical QA on a course lesson. Use this skill whenever the user asks to validate a lesson, check a lesson before commit, run course validation, or mentions `/course-lesson-validate`. Triggers on phrases like "validate the lesson", "run the checks", "pre-commit check", "QA the lesson", "check for errors before I commit", or any request to mechanically verify course lesson quality. +--- + +# Course Lesson Validator + +Pre-commit mechanical QA. Fast, scriptable, deterministic. Run this before every lesson commit. + +## Pre-loaded context + +- **PRD**: `.agent/prd/PRD.md` — 5-module architecture, 15 quality gates, artifact chain. Validator enforces the mechanical gates; the PRD defines what we're building. +- **30.03 §7 QA Checklist**: `docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.03-course-format-requirements-for-creators.md` §7 — the canonical QA spec this validator is derived from. +- **Tasks**: `.agent/tasks.json` — 34 trackable tasks. Validator is the mechanical gate for every TASK-2 through TASK-26. + +## Checks (run all 7) + +Each check produces a PASS/FAIL verdict + an actionable fix for failures. + +### Check 1: Hugo build clean + +Run `bin/hugo-build`. Must exit 0 with no error output. + +``` +Command: bin/hugo-build +FAIL if: non-zero exit code OR error lines in output +Fix: read the error output, fix the Hugo syntax issue, re-run +``` + +### Check 2: validate-course 7/7 pass + +Run `bin/validate-course`. All 7 checks must pass. + +``` +Command: bin/validate-course +FAIL if: any of the 7 checks fail +Fix: read the failure output, fix the specified issue, re-run +``` + +Note: These 7 scripted checks cover mechanical gates (chapter-number, title-yaml, internal-links, table-width, etc.). The full 30.03 §7 QA checklist (21 items across Per Lesson, Per Module, Per Course) is for human QA review — see `30.03-course-format-requirements-for-creators.md` §7. + +### Check 3: Em-dash grep + +Zero em dashes (`—`) in the lesson body. + +``` +Command: grep -n '—' content/course/tech-for-non-technical-founders-2026//index.md +FAIL if: any lines returned (unless inside frontmatter YAML or code blocks) +Fix: replace each em dash with a regular dash (-) +``` + +### Check 4: Word count band + +Count words in the lesson body (everything from the first `>` callout after frontmatter to the `*Built by*` footer, excluding code blocks and blockquotes). + +``` +Command: count body words +Bands: +- Agnostic-tool lessons (tool featured as worked example): 500-900 words +- Pure-concept lessons (no specific tool featured, no action section): 400-600 words +FAIL if: outside the applicable band +Fix: if under — expand the concept block or error anticipation; if over — tighten prose, move tangents to further reading +``` + +To count words, extract the body text between the frontmatter closing `---` and the `*Built by*` line, strip Markdown syntax, and count. + +### Check 5: Template-label H2 grep + +Forbid template-label H2s. These specific H2 strings must NOT appear: + +``` +## Why this matters +## Do this now +## If this fails +## What to do tomorrow +## What you'll get +## The problem +## The solution +## How it works +## Step by step +``` + +``` +Command: grep -n '^## \(Why this matters\|Do this now\|If this fails\|What to do tomorrow\|What you.ll get\|The problem\|The solution\|How it works\|Step by step\)' content/course/tech-for-non-technical-founders-2026//index.md +FAIL if: any matches +Fix: replace with a descriptive, content-specific H2 +``` + +### Check 6: Internal link existence + +Every internal link in the lesson must point to a file that exists. + +``` +Command: extract all /course/tech-for-non-technical-founders-2026/*/ links +For each link: check that content/course/tech-for-non-technical-founders-2026//index.md exists +FAIL if: any link target doesn't exist +Fix: correct the slug to match an existing lesson +``` + +Internal link pattern: `](/course/tech-for-non-technical-founders-2026//)` + +### Check 7: SVG file presence + +Every SVG referenced in the lesson must exist. + +``` +Command: extract all .svg references from image tags and markdown images +For each reference: check that the SVG file exists in the lesson's directory +FAIL if: any referenced SVG doesn't exist +Fix: create the SVG or remove the reference +``` + +SVG reference patterns: +- `![alt text](filename.svg)` +- `*`\[\]()!]//g' | wc -w | xargs echo "Word count:" + +# Check 5: Template-label H2s (should return nothing) +grep -n '^## \(Why this matters\|Do this now\|If this fails\|What to do tomorrow\|What you.ll get\|The problem\|The solution\|How it works\|Step by step\)' "$LESSON_DIR/index.md" || echo "PASS: no template H2s" + +# Check 6: Internal link existence +grep -oP '/course/tech-for-non-technical-founders-2026/\K[^/) ]+' "$LESSON_DIR/index.md" | sort -u | while read target; do + if [ ! -f "content/course/tech-for-non-technical-founders-2026/$target/index.md" ]; then + echo "FAIL: linked slug not found: $target" + fi +done + +# Check 7: SVG file presence +grep -oP '[a-zA-Z0-9_-]+\.svg' "$LESSON_DIR/index.md" | sort -u | while read svg; do + if [ ! -f "$LESSON_DIR/$svg" ]; then + echo "FAIL: referenced SVG not found: $svg" + fi +done +``` + +## What NOT to do + +- Do NOT modify the lesson content — only report failures +- Do NOT skip checks because "the file looks clean" +- Do NOT interpret partial passes — each check is binary PASS/FAIL diff --git a/.skills/course-lesson-write/SKILL.md b/.skills/course-lesson-write/SKILL.md new file mode 100644 index 000000000..83e3b2c02 --- /dev/null +++ b/.skills/course-lesson-write/SKILL.md @@ -0,0 +1,299 @@ +--- +name: course-lesson-write +description: Draft a complete 8-part micro-lesson (index.md) from a topic brief. Use this skill whenever the user asks to write a course lesson, draft a micro-lesson, create a lesson from a topic, or mentions `/course-lesson-write`. Triggers on phrases like "write a lesson", "draft a course chapter", "create a micro-lesson", "write lesson X.Y", or any course content creation task for the Tech for Non-Technical Founders course. +--- + +# Course Lesson Writer + +Draft a complete 8-part micro-lesson from a topic brief. Enforces every spec gate at write time, not after. + +## Pre-loaded context (read these before writing) + +### Project docs (what we're building) + +1. **PRD** — `.agent/prd/PRD.md` — formal product requirements: 5-module architecture, 15 canonical quality gates, artifact carry-forward chain, v1→v2 pivot, Sam ICP, risks, metrics +2. **Tasks** — `.agent/tasks.json` — 34 trackable tasks. Know which TASK-ID you're fulfilling before writing. Each task maps to a specific module + chapter. +3. **Roadmap** — `docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.11-course-migration-roadmap.md` — Now/Next/Later schedule with dependency graph + +**Current progress (2026-06-10):** +- ✅ Phase 1: 2 pilot lessons shipped (1.2a smoke-test-build-page, 1.2b smoke-test-wire-tracking) +- 🔲 Phase 2: M1-M5 migration pending (TASK-2 through TASK-26) +- 🔲 5-Sam Validation Pilot: planned before Phase 2 fan-out +- Do NOT rewrite pilot lessons (1.2a, 1.2b) — they're already v2 micro-lessons + +### Canonical spec (MANDATORY first reads) + +1. **30.03 §2 — 8-part template** — `docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.03-course-format-requirements-for-creators.md` §2 (the non-negotiable 8-part template: Hook → Outcome → Concept → Visual → Do-Now → Error → Reflection → Bridge) +2. **30.03 Appendix A — worked example** — same doc, Appendix A. The canonical micro-lesson (Lesson 1.1 hypothesis Mad Libs). Study the structure, tone, and compression technique. +3. **30.03 §1 — design principles** — §1.1-1.6 (single outcome, time cap, microlearning structure, self-paced, mobile-friendly, word count bands) +4. **30.03 §3 — module-level requirements** — §3.1-3.4 (structure, entry/exit, module map, core/optional tagging, minimum viable path) +5. **30.03 §4 — engagement for low-motivation learners** — §4.1-4.8 (immediate win, attention cycle, B=MAP, Zeigarnik, progress visibility, language, frictionless navigation, no heavy assessments) +6. **30.03 §5 — content spec** — §5.1-5.3 (course-level elements, per-lesson elements, micro-copy constraints, NN/g F-pattern rules) +7. **30.03 §6 — motivation, stickiness, shareability** — §6.1-6.6 (emotional acknowledgment, story of progress, built-in celebrations, viral loop, social proof, completion reward) + +### ICP and voice + +8. **Sam profile (course ICP)** — `docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.06-sam-customer-journey-report-2026-06.md` (first-time non-technical founder, no PM background, no burn history, 2-4 hr/week, ~$20K savings, reads on phone, intimidation + first-timer enthusiasm) +9. **Sam simulation learnings** — `docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.11-sam-simulation-pilot-lessons-2026-06.md` (5 themes from beat-by-beat simulation: "I don't have to write code" trust gate, catalogue-my-mistake pattern, measurable success criterion, UI-cue gap, decision-aid-in-one-sentence) +10. **Voice guide** — `docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md` (banned words, anti-AI structural patterns, the "who"/"show"/"coffee" tests) + +### Canonical v2 examples (ONLY these are micro-lessons) + +11. **Pilot Lesson 1.2a** — `content/course/tech-for-non-technical-founders-2026/smoke-test-build-page/index.md` (~870w, agnostic-tool framing, Mixo as worked example, deliberate Sam-glossing over 800w ceiling) +12. **Pilot Lesson 1.2b** — `content/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/index.md` (~640w, heavy gloss pass, tracking snippet/head tag/heatmap/session recording/pixel/GA4/incognito) +13. **30.03 Appendix A** — same doc as #2 above, but study it as an actual lesson example (not just spec). This is the canonical pattern for pure-concept lessons (no tool worked example). + +**DO NOT reference v1 long-form chapters as style examples.** The v1 chapters (form-your-founding-hypothesis, stop-specifying-features, vibe-coding-ceiling-signals, smoke-test-build-landing-page, etc.) are 2,000-4,500 words and do NOT follow the 8-part template. They are anti-patterns for micro-lesson writing. Only the 2 pilot lessons + 30.03 Appendix A are canonical v2 examples. + +## Inputs expected + +- **Chapter topic** — the specific micro-outcome (e.g., "write a founding hypothesis sentence") +- **Input artifact** — what Sam brings from the previous lesson +- **Output artifact** — what Sam walks away with +- **Optional tool to feature as worked example** — agnostic framing, not pinned in title/slug + +## Output format + +Complete `index.md` with Hugo frontmatter + 8-part body, ready for review + validation. Place in `content/course/tech-for-non-technical-founders-2026//index.md`. + +### Hugo frontmatter template + +```yaml +--- +title: "X.Y · Lesson Title" +aliases: ["/blog/slug/"] +description: "One-sentence description using Sam's language, no jargon" +date: YYYY-MM-DD +draft: true +course_chapter: true +author: "JetThoughts Team" +slug: lesson-slug +keywords: + - keyword1 + - keyword2 +tags: + - founders + - non-technical-founder + - course-companion +categories: ["Founders"] +cover_image: cover.png +metatags: + image: cover.png + og_title: "X.Y · Lesson Title" + og_description: "Same as description" +cover_image_alt: "Alt text describing the cover image content" +canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/slug/" +related_posts: false +--- +``` + +### 8-part body structure (MANDATORY — every part required except #4 visual) + +``` +> **Module X · Lesson N of M** · [Course link] + +> **Input:** [what Sam brings] + +> **Output:** [what Sam walks away with] + +> **TL;DR:** [one sentence — the what and why in Sam's language] + +[8 PARTS BELOW — DO NOT NUMBER THEM VISIBLY, DO NOT USE TEMPLATE LABELS AS H2s] + +## [DESCRIPTIVE H2 — never "Do this now", "If this fails", "Why this matters"] + +... + +## [DESCRIPTIVE H2 — next part] + +... + +> **Done when:** [observable success check] + +> **Next click:** [link to next lesson] + +> **If blocked:** [one common failure + fix] +``` + +## The 8 parts (structural rules, NOT visible labels) + +### Part 1: Hook (1-3 sentences) + +Start with a very specific pain sentence plus the immediate win. Maximum 3 sentences. Must contain: (a) the pain in Sam's language, (b) the immediate win from completing this lesson. + +Example: "You have an idea. You've told five people about it. They all said 'that sounds great' — which told you nothing. In this lesson you'll turn that idea into a single sentence you can actually test." + +### Part 2: One-Sentence Outcome + +"After this lesson you will be able to: **[single, observable action]**." + +Must be observable and verifiable — not "understand X" but "create X" or "configure X" or "decide X." + +### Part 3: Minimal Concept Block (150-300 words) + +Only what Sam needs to execute the step. Nothing more. + +Constraints: +- Max 3 new terms per lesson; each defined in one sentence at first mention +- Use bullets instead of long paragraphs where possible +- No abstract theory. Extremely concrete language +- If a concept needs more than 300 words, split into two lessons + +### Part 4: Visual Micro-Aid (Optional but Recommended) + +One compact diagram, tiny flow, or before/after example image. If explaining takes more than 4-5 sentences, consider a small SVG. + +Reference SVGs inline: `![alt text describing content](filename.svg)` + +### Part 5: Step-by-Step "Do This Now" + +Numbered list, 3-7 steps. Each step executable in under 3 minutes, written as an imperative action. Include "success check" after the last step: "You know it worked if you see X / have Y / can do Z." + +### Part 6: Error Anticipation + +Format: +> **If this fails:** [most common symptom]. **Why:** [root cause in one sentence]. **Fix:** [recovery action in 1-2 steps]. + +Every lesson must include at least one error anticipation block. + +### Part 7: Micro-Reflection (60-90 seconds) + +A single reflective question the student answers for themselves. Not a quiz — a moment to process. + +### Part 8: Bridge to Next Lesson + +1-2 sentences: "Next, we'll use what you just built to achieve [very specific next benefit]." Must name the specific dependency: what from this lesson the next lesson needs. + +## Hard Gates (NON-NEGOTIABLE — zero tolerance) + +### Anti-patterns to NEVER produce + +1. **Template-label H2s leaking** — NEVER use `## Do this now`, `## If this fails`, `## Why this matters`, `## What to do tomorrow` or any template-label as an H2. Every H2 must be descriptive and content-specific. + +2. **Inline-header bold-cap bullet pattern** — NEVER write `**Speed:** fast. **Quality:** good.` Use prose. Mix sentence lengths. + +3. **Slogany "X works. Y doesn't." flips** — NEVER write "It's not about X. It's about Y." or "The hypothesis hadn't been wrong — the questions had been." State the cause and effect in normal order; let the reader supply the contrast. + +4. **Definitional cadence** — NEVER open with "X is Y" definition. Open with tension, conflict, or a concrete scenario. + +5. **Tool-pinning in title/slug** — NEVER put tool names (Lovable, Mixo, Carrd, Stripe) in the title or slug. Use agnostic framing: "smoke-test-build-page" not "build-with-mixo." + +6. **Missing glosses** — Every technical term must be glossed at first mention: "CTO (Chief Technology Officer — the senior-most technical leader)" or "RLS (Row-Level Security — the rule that says Coach A can only read Coach A's rows)." Never assume Sam knows: MVP, PMF, ICP, CTA, DPA, ARR, MRR, SOC2, HIPAA, API, RLS, JWT, OAuth, SDK, CI/CD, CMS, DNS, SSL, hero section, incognito mode, staging, production, deployment, ORM, framework, runtime, webhook. + +### Voice rules (from 90.11) + +1. **Banned words** — unlock, harness, leverage, seamless, robust, supercharge, revolutionize, cutting-edge, world-class, best-in-class, state-of-the-art, innovative, synergy, holistic, game-changer, deep dive, empower, transform, embark, delve, navigate (metaphorical) +2. **Banned openings** — "In today's...", "When it comes to...", "It's worth noting..." +3. **Banned structural patterns** — Rule of three, triple rhetorical questions, signposting, negative parallelism, slogany closings, therapist voice, copula avoidance, anaphora pairs, sustained staccato, "The..." opener density >20%, "We..." opener density +4. **Punctuation** — Use regular dashes (`-`) not em dashes (`—`). NEVER use em dashes anywhere. +5. **Word count** — 500-900 words for agnostic-tool lessons (tool featured as worked example). 400-600 words for pure-concept lessons (no specific tool featured, no action section). + +### Design principles (from 30.03 — these drive every writing decision) + +6. **Action Mapping** (30.03 §1.3) — Design from measurable behaviors, not information. If a piece of content does not directly dictate how Sam executes the required behavior, REMOVE IT. No theory without immediate application. No "nice to know." +7. **Minimalist Instruction** (30.03 §1.3) — Every lesson must be self-contained. Never require Sam to recall a concept from 5 lessons ago. Error recovery is mandatory (Part 6), not optional. +8. **B=MAP** (30.03 §4.3) — When motivation is low, increase Ability. Make the lesson completable on Sam's worst, most unmotivated day. The first action must be completable in under 1 minute. +9. **Zeigarnik Effect** (30.03 §4.4) — End every lesson with a curiosity loop in the bridge. Unfinished cognitive tension drives completion. Pattern: Immediate Initiation → Strategic Delay → Continuous Chaining → Final Satisfaction. +10. **Dual Coding + Cognitive Load** (30.03 §2.4) — 1 visual per lesson maximum. No decorative graphics, stock photos, or multi-layered infographics. Each visual illustrates ONE concept. Mobile-legible at 375px. +11. **NN/g F-pattern** (30.03 §5.3) — 79% scan, 16% read. Inverted pyramid: conclusion + critical action at the top. Meaningful subheadings (not clever/cryptic). Bold important concepts (≤20-30% of text). One idea per paragraph. Sentences under 20 words. +12. **Micro-copy constraints** (30.03 §5.3) — Active voice. Short paragraphs (2-3 sentences). 40-60 characters per line target. No multi-step instructions in one sentence — always split into separate numbered steps. + +### Module-level requirements (from 30.03 §3 + §6) + +13. **Module first lesson — emotional acknowledgment** (30.03 §6.1) — Every module's first lesson must include an emotional acknowledgment in the hook or concept block: "You're busy and probably tired of this problem. This module focuses only on what moves the needle now." +14. **Module last lesson — win recap + share prompt** (30.03 §6.3) — End the module's final lesson with: "You now have [artifact]. If this module saved you at least an hour, you probably know someone else wrestling with this — send them this free course page." +15. **Progress visibility** (30.03 §4.5) — At the top of each lesson, include: "You are on Lesson X of Y in Module N. Results so far: [list artifacts completed]." +16. **Core/optional tagging** (30.03 §3.4) — Every lesson must be tagged [CORE] or [OPTIONAL] in the module map. Core path alone must produce the module's milestone outcome. Optional lessons must not be prerequisites for core lessons in later modules. + +### Glossing discipline (from 30.03 §2.3) + +17. **Max 3 new terms per lesson** — cap at 3 newly introduced technical terms. Each defined in one sentence at first mention. Excess terms move to a per-module "Terms you'll need" sidebar referenced from the lesson. +18. **Gloss format** — "CTA (Call to Action — the button you want the visitor to click)" or "RLS (Row-Level Security — the rule that says Coach A can only read Coach A's rows)." Gloss at first mention only. + +### Sam-first rules (from 40.06 and 40.07) + +1. **Every term glossed at first mention** — if Sam doesn't know it, define it inline +2. **No "developer" or "PM" assumptions** — never assume Sam knows product management or engineering terminology +3. **First 30% orients** — thresholds and metrics arrive only when Sam acts on them +4. **Single golden path** — one primary tool recommendation with a named fallback, not a comparison table of 6 options +5. **Confidence-to-act** — Sam must know what to do next with no remaining ambiguity after reading + +### Case study placement + +Case studies live at the END OF EACH MODULE as a single coherent walkthrough page (`module-N-walkthrough-`), NOT inside individual lessons. Do NOT include case study narratives inside lesson bodies. The lesson body stays tightly focused on its single algorithm. + +However, each lesson footer should include a case study CTA line at the END of the lesson (after the bridge) ONLY IF the module's walkthrough page already exists: + +``` +> **See it in action:** [Module N walkthrough · Founder](/course/tech-for-non-technical-founders-2026/module-N-walkthrough-founder/) +``` + +Do NOT add this line before the walkthrough page is published. + +### Footer block (after bridge line) + +```markdown +> **Done when:** [observable success check] +> **Founder OS · Artifact #N of 6:** [artifact name]. [where to save it]. +> **Next click:** [X.Y · Next Lesson Title](/course/tech-for-non-technical-founders-2026/next-slug/) +> **If blocked:** [one common failure + fix] + +> **See it in action:** [optional, only if walkthrough page exists] + +> **Share:** Know someone wrestling with this? [Send them this free lesson.](/course/tech-for-non-technical-founders-2026/lesson-slug/) + +--- + +*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.* +``` + +## 30.03 §7 QA Self-Checklist (run before outputting) + +### Per Lesson + +- [ ] Does the lesson have exactly one clearly stated outcome? (Part 2) +- [ ] Does it end with an observable success check? (Part 5, final step) +- [ ] Total reading: ≤10 minutes (~400-600 words for concept, 500-900 for tool)? +- [ ] Total implementation: ≤15 minutes for Sam? +- [ ] Is there any theory/content that does not directly support a concrete action? If yes → REMOVE. +- [ ] Can Sam see a tangible benefit within the first 10 minutes? +- [ ] Can Sam progress without asking anyone for help? +- [ ] Is the 8-part template followed exactly and in order? (Hook → Outcome → Concept → Visual → Do-Now → Error → Reflection → Bridge) +- [ ] Max 3 new terms introduced? Each glossed at first mention? + +**Additional writer-only checks:** + +- [ ] Em dashes: ZERO. +- [ ] Template-label H2s: ZERO. + +### Per Module (when writing module-start or module-end lessons) + +- [ ] Does the module have exactly one milestone outcome? (30.03 §3.1) +- [ ] Are entry conditions and success definitions clear? (30.03 §3.2) +- [ ] Module first lesson: emotional acknowledgment present? +- [ ] Module last lesson: win recap + share prompt present? +- [ ] Progress visibility: "Lesson X of Y in Module N" tag present? +- [ ] Core/optional tag present in module map? +- [ ] Core path alone produces the milestone outcome? + +### Per Course (when writing lessons that affect course-level structure) + +- [ ] Quickstart page still accurate? +- [ ] FAQ page covers common blockers from this lesson? +- [ ] "What not to learn" section still accurate? +- [ ] Skim-reading check: does a scanner instantly know "What do I get?", "What exactly do I do?", "How do I know it's done?" in under 3 seconds? (30.03 §7) +- [ ] Is the navigation and structure identical across all lessons? (30.03 §4.7) +- [ ] Tables ≤3 columns and mobile-friendly? +- [ ] Does the page pass the 375px viewport test (no horizontal scroll, SVG legible)? + +## Workflow + +1. Read `30.03-course-format-requirements-for-creators.md` §2 (the 8-part template) + Appendix A (worked example) +2. Read `90.11-voice-guide.md` (banned words, structural patterns) +3. Read `40.06-sam-customer-journey-report-2026-06.md` (Sam's perspective) +4. Read `40.11-sam-simulation-pilot-lessons-2026-06.md` (Sam simulation learnings — 5 themes) +5. Read BOTH pilot lessons as canonical v2 examples: `smoke-test-build-page/index.md` (tool-agnostic) + `smoke-test-wire-tracking/index.md` (gloss-heavy). Also study 30.03 Appendix A. +6. Draft the lesson frontmatter + 8-part body +7. Self-check against all hard gates above +8. Self-check against the 30.03 §7 QA checklist (below) +9. Output the complete `index.md` diff --git a/.skills/course-skills-map.md b/.skills/course-skills-map.md new file mode 100644 index 000000000..aaee354d7 --- /dev/null +++ b/.skills/course-skills-map.md @@ -0,0 +1,144 @@ +# Course Skills Map — From Idea to Ideal Released Course + +**Purpose:** Maps global Codebuff skills to the 7 phases of taking the Tech for Non-Technical Founders course from current state to the ideal released product that Sam loves and promotes. + +**Global skills live at:** `~/.agents/skills//` +**Local skills live at:** `.skills//` + +**Foundational docs (read first):** +- **PRD**: `.agent/prd/PRD.md` — formal product requirements, 5-module architecture, 15 canonical quality gates, migration phases +- **Tasks**: `.agent/tasks.json` — 34 trackable tasks (TASK-1 through TASK-34) for the v2 migration +- **Roadmap**: `docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.11-course-migration-roadmap.md` — Now/Next/Later dependency-aware schedule +- **Task Tracker**: `docs/projects/2605-tech-for-non-technical-founders/TASK-TRACKER.md` — single source of truth for all post-ship improvements + +**Current progress (2026-06-10):** +- ✅ Phase 1 (Pilot): Complete — 2 v2 micro-lessons shipped (1.2a, 1.2b) +- 🔲 Phase 0 (Mechanical quick wins): Deferred +- 🔲 Phase 2 (Module-by-module migration): Not started — M1-M5 pending +- 🔲 Phase 3 (Cross-cutting polish): Not started +- 🔲 5-Sam Validation Pilot: Planned — before Phase 2 fan-out + +--- + +## Phase 1: Course Design & Architecture (NOW — migration prep) + +**Status:** ✅ Pilot complete. Phase 2 pending 5-Sam validation gate. + +| Skill | Why | When to use | +|---|---|---| +| **course-designer** (global) | Learning objectives, Bloom's taxonomy, assessment rubrics, syllabi | Designing module-level outcomes, ensuring lesson sequences build correctly, writing assessment gates | +| **customer-research** (global) | Validate what Sam actually needs, mine Reddit/G2/reviews for pain language | Before creating new lessons, when unsure if a topic belongs in the course | +| **customer-journey-map** (global) | Map Sam's emotional arc through all 5 modules, identify friction points | Auditing the full course flow, finding gaps in the trust curve (see 40.06) | +| **problem-statement** (global) | Frame "who is blocked, what they're trying to do, why it matters" | Sharpening the course promise, Quickstart page, module intros | +| **course-lesson-write** (local) | Draft 8-part micro-lessons from topic briefs. References PRD, tasks.json, 30.03 spec. | Every new Phase 2 lesson — core workflow. Maps to TASK-2 through TASK-26. | +| **course-lesson-review-sam** (local) | Sam-perspective review with 6 tests. References PRD, 30.03 spec, 40.11 simulation. | Before every lesson commit | +| **course-lesson-validate** (local) | Mechanical QA: build, validate, em-dash, word count, links, SVGs. References PRD, 30.03 §7. | Before every lesson commit | +| **course-svg-draft** (local) | JT-brand hand-drawn SVG illustrations. References PRD, pilot SVGs. | When a lesson needs a visual micro-aid | +| **task-breakdown** (global) | Break overwhelming tasks into manageable steps | Migrating modules one-by-one, planning the Phase 2 schedule | +| **product-marketing-context** (global) | Creates reusable context doc — course product, ICP (Sam), positioning — that every marketing skill references | BEFORE any copywriting, SEO, or landing page work. Foundational. Creates `.agents/product-marketing-context.md`. | +| **senior-pm** (global) | Portfolio mgmt, quantitative risk analysis, resource optimization, stakeholder alignment, executive reporting | Organizing project artifacts, auditing doc health, tracking milestones across phases. See 40.10 health report. | +| **prd-creator** (global) | Creates structured PRDs + generates implementation task lists in JSON | Already invoked — PRD at `.agent/prd/PRD.md`, tasks at `.agent/tasks.json`. Re-invoke if scope changes. | +| **roadmap-planning** (global) | Strategic roadmap, prioritization, epic definition, sequencing | Already invoked — roadmap at `20.11-course-migration-roadmap.md`. Re-invoke if schedule changes. | + +## Phase 2: Content Creation & Voice (NOW — gated behind 5-Sam pilot) + +| Skill | Why | When to use | +|---|---|---| +| **copy-editing** (global) | Edit, review, improve existing copy | Polishing existing v1 chapters during migration, refreshing lesson bodies | +| **copywriting** (global) | Write marketing copy for any page | Course landing page hero, module intros, CTA copy | +| **humanizer** (global) | Remove AI-generated writing signs from text | Final polish pass on every lesson before publish — catches AI tells the voice guide misses | +| **slop-detector** (global) | Detect and flag AI content markers | Auditing lessons for AI-pattern tells, verifying voice guide compliance at scale | +| **blog-post** (global) | Write long-form blog posts with SEO optimization | Companion blog posts that promote the course, deep-dive articles that drive traffic | +| **content-trend-researcher** (global) | Analyze trends across Google, Reddit, Substack, LinkedIn, YouTube for data-driven article outlines | Finding trending topics for companion blog posts that drive traffic to the course | +| **technical-writing** (global) | Create clear, in-depth developer tutorials | If any technical companion pages are needed (Supabase setup, Stripe webhook guide) | + +## Phase 3: Marketing Infrastructure (NEXT — after content is 80% done) + +| Skill | Why | When to use | +|---|---|---| +| **seo-audit** (global) | Audit technical SEO issues on course pages | Before launch — check meta tags, headings, crawlability, page speed | +| **ai-seo** (global) | Optimize for AI search engines, get cited by LLMs | After SEO audit — optimize for ChatGPT/Perplexity/Claude citations | +| **schema-markup** (global) | Add Course, FAQ, HowTo, Breadcrumb structured data | After content is stable — rich results for course pages in Google | +| **site-architecture** (global) | Plan page hierarchy, navigation, URL structure, internal linking | Designing the course navigation, ensuring proper breadcrumbs and link chains | +| **blog-page-generator** (global) | Create blog listing/index pages | Building a course blog hub page that indexes all companion posts | +| **programmatic-seo** (global) | SEO-driven pages at scale using templates | If building city/industry-specific course landing pages at scale | +| **analytics-tracking** (global) | Set up GA4, conversion tracking, event tracking | Track lesson completion, CTA clicks, email captures, share events | + +**Gate to Phase 4:** All Phase 3 skills invoked. SEO audit clean. Schema markup deployed. Site architecture finalized. Analytics baseline captured. + +--- + +## Phase 4: Landing Page & Conversion (NEXT) + +| Skill | Why | When to use | +|---|---|---| +| **landing-page-optimization** (global) | Landing page creation, copywriting, design, conversion | Course landing page (`_index.md`) — hero section, CTAs, social proof, module map | +| **page-cro** (global) | Conversion rate optimization for any marketing page | Optimizing the landing page conversion rate, A/B testing CTAs | +| **copywriting** (global) | Hero copy, CTAs, value propositions | Writing the landing page copy in ICP-E voice | +| **marketing-psychology** (global) | Behavioral science, cognitive biases, persuasion | Framing the value proposition, designing trust triggers, pricing anchors | + +## Phase 5: Distribution & Promotion (LATER) + +| Skill | Why | When to use | +|---|---|---| +| **social-content** (global) | LinkedIn, Twitter, Instagram content creation and scheduling | Paul Keen LinkedIn posts promoting the course, founder Twitter threads | +| **email-sequence** (global) | Create nurture sequences, launch emails, lifecycle emails | Course launch email sequence, re-engagement for drop-offs, completion emails | +| **launch-strategy** (global) | Product launch planning, Product Hunt, beta launch | Planning the course launch — Product Hunt, Hacker News, Indie Hackers, Reddit | +| **cold-email** (global) | B2B cold outreach emails | If reaching out to newsletter curators, podcast hosts, or distribution partners | +| **content-strategy** (global) | Plan what content to create, topic clusters, editorial calendar | Planning the blog + social content calendar that funnels into the course | +| **solo-founder-gtm** (global) | Solo founder GTM motion, AI agent team for go-to-market | Designing the full marketing engine as a solo team with AI agents | +| **competitor-alternatives** (global) | Competitor comparison vs alternative pages | Building "vs YC Startup School" or "vs Lenny's Newsletter" comparison pages | +| **marketing-ideas** (global) | Brainstorm marketing tactics, growth ideas, promotion strategies | When stuck on promotion — "how else can I get this course in front of Sam?" | + +## Phase 6: Growth & Conversion (LATER) + +| Skill | Why | When to use | +|---|---|---| +| **lead-magnets** (global) | Plan email capture content, downloadable resources | Bundling the 6 Founder OS artifacts as a downloadable lead magnet | +| **referral-program** (global) | Referral program, affiliate, word-of-mouth strategy | Building the milestone referral program from 30.03 §6.4 | +| **ab-test-setup** (global) | Plan A/B tests, growth experiments | Testing landing page variants, email subject lines, CTA copy | +| **analytics-tracking** (global) | Optimize conversion tracking, event funnels | Refine lesson completion tracking, email capture funnels, share velocity metrics | + +## Phase 7: Product Strategy & Pricing (IF MONETIZING) + +| Skill | Why | When to use | +|---|---|---| +| **positioning-statement** (global) | Geoffrey Moore positioning — who, what, why different | Clarifying course positioning against YC, Lenny, Reforge, Maven | +| **product-strategy-session** (global) | End-to-end strategy: positioning, discovery, roadmap | If pivoting to a paid course or cohort-based version | +| **pricing-strategy** (global) | Pricing decisions, packaging, monetization strategy | If the course becomes a paid product (freemium → paid tiers) | +| **launch-strategy** (global) | Product launch planning | Launching a paid tier or premium companion offering | + +--- + +## Immediate Next Actions (Phase 1 & 2) + +These skills should be invoked NOW during the micro-lesson migration: + +1. **course-lesson-write** — Draft M1 lessons per TASK-2 through TASK-5 (after 5-Sam pilot gate clears) +2. **5-Sam Validation Pilot** — Recruit 3-5 real founders, watch Clarity recordings, validate simulation predictions before Phase 2 fan-out +3. **customer-research** — mine Reddit/G2/forums for Sam's exact pain language to sharpen lesson hooks +4. **course-designer** — validate that the 5-module structure with 24-28 micro-lessons achieves the right learning objectives by Bloom's taxonomy + +## Task-Awareness Quick Reference + +| Task ID | Action | Skill to invoke | +|---|---|---| +| TASK-1 | Verify prerequisites (Hugo, validators, spec access) | (manual) | +| TASK-2 | M1.1 Founding Hypothesis → 2 micro-lessons | course-lesson-write → course-lesson-review-sam → course-lesson-validate | +| TASK-3 | M1.2b Smoke Test Run → 1 micro-lesson | course-lesson-write → course-lesson-review-sam → course-lesson-validate | +| TASK-4 | M1.3 Price Hypothesis → 1 micro-lesson | course-lesson-write → course-lesson-review-sam → course-lesson-validate | +| TASK-5 | M1 bridge chain + exit gate | (manual verification) | +| TASK-6..26 | M2-M5 migration (21 tasks) | course-lesson-write → course-lesson-review-sam → course-lesson-validate | +| TASK-27..34 | Phase 3 polish (8 tasks) | (cross-cutting audits) | + +See `.agent/tasks.json` for full task index with spec file paths. + +## Skill Import Status + +| Skill | Location | Status | +|---|---|---| +| course-lesson-write | `.skills/` (local) | Created ✓ | +| course-lesson-review-sam | `.skills/` (local) | Created ✓ | +| course-lesson-validate | `.skills/` (local) | Created ✓ | +| course-svg-draft | `.skills/` (local) | Created ✓ | +| All others | `~/.agents/skills/` (global) | Already installed ✓ | diff --git a/.skills/course-svg-draft/SKILL.md b/.skills/course-svg-draft/SKILL.md new file mode 100644 index 000000000..818bc91a6 --- /dev/null +++ b/.skills/course-svg-draft/SKILL.md @@ -0,0 +1,131 @@ +--- +name: course-svg-draft +description: Draft a hand-drawn-style JT-brand SVG illustration for a course lesson. Use this skill whenever the user asks to create a course SVG, draw a diagram for a lesson, create an illustration, or mentions `/course-svg-draft`. Triggers on phrases like "create an SVG", "draw a diagram", "make an illustration for this lesson", "course SVG", "JT-brand illustration", or any request for a hand-drawn style diagram for the course. +--- + +# Course SVG Drafter + +Draft a hand-drawn-style JT-brand SVG for a lesson. Mobile-readable at 375px, viewBox sized for 600px article column. + +## Pre-loaded context + +- **PRD**: `.agent/prd/PRD.md` — 5-module architecture, 15 quality gates. SVGs must serve the lesson's single concept per 30.03 §2.4 (dual coding + cognitive load). +- **30.03 §2.4**: `docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.03-course-format-requirements-for-creators.md` §2.4 — visual discipline rules: 1 visual per lesson, no decorative graphics, mobile-legible at 375px. + +### Canonical v2 SVG examples (study these first) +- `content/course/tech-for-non-technical-founders-2026/smoke-test-build-page/page-anatomy.svg` — the ONLY v2 pilot SVG. Block layout, label/desc pattern, hand-drawn rotation. +- `content/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/tracking-snippets.svg` — multi-column with arrows, event markers. + +**DO NOT reference v1 lesson SVGs as style guides.** v1 SVGs (admin-panel-spaceship, shed-house-skyscraper, signals-scoreboard, etc.) were designed for long-form chapters and may have multi-concept infographics that violate the 1-visual-per-lesson rule. Use the pilot lesson SVGs as the canonical v2 pattern. + +### JT brand palette +- **Ruby red** `#cc342d` — primary accent, borders, emphasis +- **Dark obsidian** `#1a1a1a` — text, headings +- **Pastel fills** — `#fff5f5` (warm pink), `#f0f9f0` (mint), `#e8f4f8` (sky), `#fffbe6` (warm yellow), `#fff8e0` (gold), `#fbe9ff` (lavender), `#f5e9ff` (purple tint) +- **Subtle gray** `#555` — secondary text, notes +- **White** `#fff` — CTA text on red + +### Font stack +- **Headings/labels:** `"Caveat", "Patrick Hand", cursive` — font-size 22-30px, weight 700, color `#1a1a1a` +- **Body/descriptions:** `"Caveat", "Patrick Hand", cursive` — font-size 16-20px, color `#1a1a1a` +- **Notes/italic:** `"Caveat", "Patrick Hand", cursive` — font-size 14-17px, color `#555`, font-style italic +- **Mono/code:** `"JetBrains Mono", "Courier New", monospace` — only for code-like labels +- **CTA text on red:** font-family `"Caveat", "Patrick Hand", cursive`, color `#fff`, weight 700 + +### ViewBox and sizing +- **Default viewBox:** `0 0 600 400` (sized for 600px article column). Use wider if content needs it: `0 0 700 450` or `0 0 800 500`. Adjust height to content. +- **Font-size math for mobile:** at 375px viewport width, text must be ≥14px rendered. With viewBox width = 600, the ratio is 600/375 = 1.6x. Minimum viewBox font-sizes: 14×1.6 ≈ 22px for smallest text. Use: 20-22px for notes (14-15px rendered), 22-26px for labels (15-17px rendered), 26-30px for headings (17-19px rendered). +- **Target:** one concept per SVG. Never cram multiple concepts into one graphic. +- **Stroke width:** 2-2.5px for borders. 2px for arrow lines. + +### Rotational "hand-drawn" effect +Apply subtle rotation to blocks (`transform="rotate(-0.3 X Y)"` or `rotate(0.2 X Y)`) to give a hand-drawn feel. Rotation should be subtle — between -0.5 and 0.5 degrees per block. Use slightly different rotation values on adjacent blocks. + +### Existing SVG style references (pilot SVGs first — canonical v2 patterns) +Study these existing SVGs for style patterns: +- `content/course/tech-for-non-technical-founders-2026/smoke-test-build-page/page-anatomy.svg` — ✅ CANONICAL v2: block layout, label/desc pattern, hand-drawn rotation. Study this FIRST. +- `content/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/tracking-snippets.svg` — ✅ CANONICAL v2: multi-column with arrows, event markers. +- Legacy reference (v1 — study for technique only, NOT as micro-lesson patterns): + - `content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/admin-panel-spaceship.svg` — comparison pair + - `content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/shed-house-skyscraper.svg` — progression diagram + - `content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/signals-scoreboard.svg` — scoreboard/table + +## SVG template + +```xml + + Alt text describing the content of the diagram + + + + + + + + + Diagram title + + + + +``` + +## Design rules + +### Content rules +1. **One concept per SVG** — if the diagram has two separate ideas, it's two SVGs +2. **Title at top** — centered heading, y=32, font-size 28px +3. **3-7 blocks max** — more than 7 blocks overwhelms the visual channel per cognitive load theory +4. **No decorative elements** — every shape carries information. No stock icons, no abstract backgrounds + +### Layout rules +1. **Left-to-right flow** for comparisons: bad on left (red/pink border), good on right (green/mint border) +2. **Top-to-bottom flow** for sequences: steps flowing downward +3. **Center layout** for single concepts +4. **Arrows between connected elements** — dashed lines with arrowheads, stroke-dasharray 6 4 + +### Color coding +| Element | Fill | Border | +|---|---|---| +| Default block | `#fff5f5` | `#cc342d` | +| Good/success | `#f0f9f0` | `#2e7d32` | +| Bad/failure | `#fff5f5` | `#cc342d` | +| Neutral/info | `#e8f4f8` | `#0277bd` | +| Warning | `#fffbe6` | `#bf8a00` | +| CTA button | `#cc342d` | none | +| Purple accent | `#f5e9ff` | `#7c3aed` | +| Lavender accent | `#fbe9ff` | `#a855f7` | + +### Accessibility +1. **role="img"** on the SVG element +2. **aria-labelledby** pointing to the title element +3. **Title text** that describes the diagram content, not just "diagram" or "illustration" +4. **Alt text** — always provide alt text that describes the CONTENT of the SVG. Never write "decorative graphic" or "illustration." Bad alt: "A diagram showing the process." Good alt: "A hand-drawn comparison showing the simple three-button admin panel requested on the left and the 47-button spaceship control deck that was built on the right, connected by a red arrow labeled '10-week build, $15K'" + +## Workflow + +1. Understand the concept the SVG needs to communicate (from the lesson topic) +2. Read 2-3 existing SVGs from the course for style reference +3. Sketch the layout: blocks, arrows, labels +4. Write the SVG following the template above +5. Self-check: + - [ ] ViewBox reasonable (600-900 wide, height proportional) + - [ ] Font sizes ≥20px for smallest text + - [ ] Colors match JT palette + - [ ] One concept only + - [ ] Title describes the content + - [ ] Alt text describes the content (not "decorative graphic") + - [ ] Subtle rotation on blocks for hand-drawn feel + - [ ] No em dashes in text +6. Output the complete SVG file and save to `content/course/tech-for-non-technical-founders-2026//.svg` +7. Provide the alt text separately for the lesson's markdown image reference diff --git a/AGENTS.md b/AGENTS.md index 89de46797..cc588ffcb 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -19,23 +19,34 @@ Workflow references: - `docs/workflows/commands.md` - `docs/workflows/agents.md` -Key commands: +## Projects + +Projects live in `docs/projects//`. Each project follows a standard +onboarding path: + +**First visit — read in this order:** +1. `PROJECT-INDEX.md` — navigation hub, agent routes, integration rules +2. `GOAL-AT-A-GLANCE.md` — one-page exec summary, strategy, metrics +3. `.agent/prd/PRD.md` — formal spec (if PRD-driven project) +4. `.agent/tasks.json` — machine-readable task graph (if PRD-driven) +5. `TASK-TRACKER.md` — live task queue, migration schedule, active phase + +**Project health:** `.agent/STATUS.md` — cross-project RAG dashboard. +Per-project PM health reports in `40-49-review/40.10-*.md`. + +**Skills:** Project-specific skills in `.skills/`. Global skills loaded via +`skill` tool. + +**Key commands:** - `bin/hugo-build` - `bin/rake test:critical` +- `bin/validate-course` (course projects only) -OUTPUT STYLE: expert-terse -- Telegraph format: subject-verb-object, drop articles/prepositions -- Symbolic vocabulary: → cause, ∵ because, ∴ therefore, ⊕ add, ⊖ remove, Δ change, ≈ similar, ≠ different, ∈ in/member, ∅ empty/none, ✓ ok, ✗ fail -- Code blocks: untouched (never compress code syntax) -- Each line: max 80 chars -- Zero narration, zero filler -- BUDGET: ≤100 tokens per non-code response +OUTPUT STYLE: concise-default +- Default: short replies (1-3 sentences or bullet list). +- Expand only when user requests details or task requires explanation. +- No preamble, no filler, no recaps unless asked. +- Code blocks: untouched (never compress code syntax). +- Each line: max 80 chars. - - -## lean-ctx - -Prefer lean-ctx MCP tools over native equivalents for token savings. -Full rules: @LEAN-CTX.md - diff --git a/CLAUDE.md b/CLAUDE.md index 5f47762bb..76a6b53e8 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -102,9 +102,14 @@ Follow official methodology from `/knowledge/`: - **Zero tolerance for duplicates**: No `*_refactored.*`, `*_new.*`, `*_backup.*` files - **New docs allowed only under** `docs/workflows/` (else edit existing files) - **Reflection triggers**: User reports "code is bad" / "over-engineered" → HALT, 5-Why analysis, fix config, THEN proceed +- **Mandatory self-critique on voice-sensitive content (BLOCKING)**: For any draft or revision of LinkedIn posts, blog posts, or marketing copy, invoke `reflexion-reflect` (Standard Path) BEFORE first handback. After user pushback on the same draft, escalate to `reflexion-critique` (multi-judge debate) per the LinkedIn pipeline §3 / blog pipeline equivalent. Solo iteration past first delivery consistently misses pattern-level tells (over-narration, cinematic beat-marking, shape-coded copywriting) — observed on the 2026-05-11 Monday Jira-not-progress post (5 user corrections after the AI rubric scored 0/10). - **Visual regression test gate (BLOCKING for HTML/CSS/template changes)**: After ANY edit to `themes/`, `layouts/`, `content/blog/*/index.md` body HTML, or `*.css`, run BOTH `bin/test` (macOS host) AND `bin/dtest` (Linux/Docker) BEFORE committing. They write to separate baseline dirs (`test/fixtures/screenshots/macos/` vs `linux/`) and CI runs Linux — skipping `bin/dtest` ships a green PR locally that breaks the build. The 35-failure incident on 2026-04-30 happened because Sprints #2/#3 shipped 15 commits without running it once — and the failing tests caught a real `.fl-button` regression Sprint #3 missed. Visual regression failures are NOT optional warnings; they are commit blockers. Either fix the regression OR confirm the change is intentional AND update baselines (both macos/ AND linux/) in the same commit. "I'll run tests after a few commits" is the path that lets unfixed bugs ship. - **Feature-branch + ONE bundled PR per sprint (BLOCKING for HTML/CSS/template changes)**: Don't push HTML/CSS/template/layout changes directly to `master`. The pattern is: (1) `git checkout -b `, (2) ship multiple related commits on the branch (one per fix is fine — easy to revert/cherry-pick), (3) run BOTH test gates green on each commit, (4) `git push -u origin `, (5) open ONE PR via `gh pr create` covering the full sprint with summary + per-commit description + visual evidence. **Bundle related work into one PR — don't split into many small PRs.** User flagged 2026-04-30: "let's have one big PR instead of small PR." A 5-commit sprint = 1 PR, not 5. Direct-to-master is only acceptable for content-only blog edits (markdown body without template changes), commit-message-only fixes, docs under `docs/`, and `CLAUDE.md` policy updates. - **Never commit coordinator/agent report files**: User flagged 2026-04-30: "do not commit report files like docs/projects/2604-typography-ux/sprint-7-coordinator-report.md." Sprint coordinators and verification agents often write a `*-coordinator-report.md` or `*-verification-report.md` summarizing what they shipped. These are working notes, not project documentation — keep them OUT of the repo. Write to `/tmp/` instead, OR write to `docs/` but `git restore --staged .md` before committing the rest of the work. The findings/audit reports under `docs/projects/2604-typography-ux/findings-*.md` ARE legitimate project artifacts (cross-page consistency audit, mobile UX audit, etc.) — those stay. Coordinator reports about WHICH commits ran on WHICH date are session-internal and should not pollute the repo. +- **Surgical edit discipline (BLOCKING for content edits)**: When the user flags ONE attribute (a price, a tool name, a year-stamp, a label, a callout), change ONLY the sentences containing that attribute. Do NOT rewrite, re-balance, or re-theme the surrounding page — name the page's thesis in one line first and confirm it is unchanged. If a fix seems to need touching >1 paragraph or the structure, STOP and ask before expanding scope. When correcting a stance the user called too far one way (e.g. "too free"), land at the documented middle — do NOT swing to the opposite extreme (the budget free→paid→balanced pendulum cost 4 round-trips on 2026-05-22). Before handback, grep your OWN replacement text for the exact pattern you just removed (year-stamp, banned word, hardcoded tool name, alias) — re-introducing the defect you are fixing is a blocking failure. On renames/cleanups default to LESS: remove old references and update them, never add alias/redirect bridges (zero tech debt); question inherited elements (routing blocks, disclaimers) proactively rather than preserving them until the user points. Scope critic/cold-eyes findings to a punch-list of surgical fixes, NOT license to rewrite the page. +- **ICP-reader read-back (BLOCKING for course/content edits)**: Before handback, re-read the edited chapter top-to-bottom AS the course ICP — "Sam," the idea-stage non-technical first-timer, NOT the website lead-gen ICP "Alex the burned founder" (rescue/trauma framing is off-ICP for course bodies). Confirm: (1) every acronym/tool/term is glossed at FIRST mention (what it is, in plain words); (2) progressive disclosure — orientation blocks orient, they do NOT front-load thresholds/metrics/mechanics (those belong where the reader acts on them); (3) value-first tone, not sales; (4) visual rhythm — no two adjacent same-form callouts. See memory `feedback_minimal_edit_scope_no_page_bombing` and `feedback_icp_reader_readback_progressive_disclosure`. +- **Write for Sam, not for Paul (BLOCKING for course content edits)**: When Paul corrects a phrase in fast operator-shorthand ("ICP", "apparatus", "resonate", "confirm demand"), DO NOT echo that wording into the lesson body. Translate to Sam-voice — plain English, observable behavior, named binary outcomes. The 1.1 Outcome pattern is the canonical shape: `"a stranger reads and either says 'that's my problem' or 'not me'"`. Phase 2 should mirror that binary-behavior structure across Outputs and Outcomes. Paul flagged 2026-06-11: "I just spot a problem but you build and use the language of Sam's and resonate with him, not with me." Take initiative on wording — fix the underlying intent in Sam-voice, don't paste Paul-voice into the lesson. +- **"Pilot" in 2605 course work = INTERNAL editorial template review, NOT external customer recruitment**: In any 2605 session, "pilot lessons" / "5-Sam validation pilot" / "validate the template" defaults to Paul-as-reviewer of the v2 micro-lesson template (currently 1.2a + 1.2b). External recruitment / Clarity install / outreach scripts are deferred to post-course-completion (kit lives at `docs/projects/2605-tech-for-non-technical-founders/40-49-review/_DEFERRED_external-validation-pilot-kit.md`). Confirmation signals for INTERNAL: 30.03 spec exists, 40.11 Sam simulation already done, "review them", "approve", "fan out template". Confirmation signals for EXTERNAL (rare, post-launch only): "recruit", "real founders", "Clarity recordings", "promote", "sell the course". Cost a 372-line external-customer-research kit side-quest on 2026-06-11 when I anchored on TASK-TRACKER's literal "recruit 3-5 real founders" without questioning the implicit reviewer. ### ✍️ Blog Post Pipeline (MANDATORY) @@ -146,9 +151,12 @@ Repo voice guides and workflow docs override generic writing, SEO, or humanizer - See `~/.claude/projects/-Users-pftg-dev-jetthoughts-github-io/memory/feedback_cross_post_signal_repetition.md` for the signal portfolio map. See `feedback_hook_bank_diversity.md` for opening-shape rotation (separate concern). **Slop detector + shape-tell critic both required:** -- Sentence-level slop ≤25/100 is necessary but not sufficient. User has flagged "still feels AI" twice in 2026-05-09/10 sessions when slop detector passed. +- Sentence-level slop ≤25/100 is necessary but not sufficient. User has flagged "still feels AI" three times in 2026-05-09 / 2026-05-10 / 2026-05-28 sessions when slop detector passed. - After slop passes, spawn a shape-tell critic with this explicit pattern list: essay arc (hook → pivot → thesis → evidence → caveat → close), dual-source statistical opener, pivot sentences ("That's the experience of...", "Here's what's underneath...", "The bigger problem is..."), listicle scaffolding cloned 3+ times (Strong/Weak/Tips, 5-item lists repeated), "The..." paragraph-opener density >20%, slogany flips ("X works. Y doesn't.", "It looks Y. It isn't Z.", "The framework is a diagnostic, not a cure."), definitional cadence ("X is hypothesis-validation tooling."), "You're not throwing away X" reassurance tic. -- See `feedback_slop_detector_misses_shape_tells.md` for the full pattern list. Run alongside the slop detector, not after. +- **2026-05-28 additions (caught by 4-persona M1-M3 audit):** slogany reveal-twist flip ("X hadn't been Y - Z had been", "It's not about X. It's about Y.", "X wasn't Y - it was Z"); cost-stacked tri-list opener ("$X-$Y in A, N B, one of M C" - reads as workshop slide); cute aphoristic flourish closer ("polite noise", "the kind smile that costs you a year", "the helpful answer is the trap", "Everything else is your mom being nice"); anonymous-named-founder opener template repeated 3+ chapters in a row (Module 2 had Priya/Maya/ed-tech-founder/consumer-app-founder back-to-back); cinematic time-cut narration ("Nine months later: a product, a $62K dev invoice, zero paying customers"); fabricated cohort stats with no source ("4 of 5 real interviewees", "3-5× the rate", "30-45% reply rates"). +- **Opener-shape rotation gate (NEW):** when reviewing a multi-chapter sprint (3+ chapters in the same module), explicitly count the opener shape of each chapter. No 3+ consecutive chapters may share the same opener template (anonymous-founder vignette, year-stamp cohort, named-research-result, etc.). The 2026-05-28 Module 2 audit found 4 consecutive chapters opening with "A [adjective] founder we [verb]" - a regression nobody caught because single-chapter review can't see template repetition. +- **Banned-pattern regression sweep (NEW):** every revision pass must run `grep -rn "## Why this matters\|Founders who\|Most founders\|Founders we worked with"` across edited chapters before handback. Patterns previously removed regress under time pressure - the 2026-05-28 audit found Case 25 banned heading restored in 3 of 9 chapters. +- See `feedback_slop_detector_misses_shape_tells.md` and `feedback_voice_regression_m1_m3_2026_05_28.md` for the full pattern list. Run alongside the slop detector, not after. **dev.to import ICP gate:** - Posts synced from dev.to (`source: dev_to` in frontmatter) are auto-imported without an ICP filter. Before any dev.to-imported post is shipped or referenced, audit it against the JT ICP-E voice guide. If 80+/100 AI-feel or off-thesis (generic management/productivity content with no JT-rescue angle), either rewrite for the ICP or flip to `draft: true`. Caught 2026-05-10: scipab post (Dec 2024 dev.to import) was 92/100 AI-feel, orphan content. Rewrote as "SCIPAB for non-technical founders to interrogate their dev shop." @@ -156,6 +164,28 @@ Repo voice guides and workflow docs override generic writing, SEO, or humanizer **Markdown code fence: use `html` not `erb`:** - Hugo's Chroma syntax highlighter doesn't recognize `erb` as a lexer alias. Fences using ```erb render as plain `
` without the Dracula wrapper — the theme's light foreground (`#f8f8f2`) on missing-background renders as invisible text. The `html` fence highlights HTML tags correctly while ERB `<%= %>` renders as plain text inside the dark block. 10 posts hit this bug before the 2026-05-10 fix; verified by HTML diff comparing the wrapper `
` (present for `html`/`ruby`) vs missing for `erb`.
 
+**Visual verification gate (BLOCKING for any new media element):**
+- After adding ANY new visual (Mermaid diagram, SVG infographic, image, table, chart, callout block, hero image), MUST verify via chrome-devtools MCP before declaring done. The "Screenshot taken" gate is necessary but not sufficient.
+- Take screenshots at BOTH desktop (1280×800) and mobile (390×844) viewports. The first-fold experience is what determines whether the visual wins the 3-second hook.
+- Score honestly from a user perspective against these 4 criteria — and write the scores in the commit message OR the user-facing report:
+  1. **Is it a great look?** — visual harmony, font legibility, color contrast, alignment, fits the brand
+  2. **Is it functional?** — info is readable without effort, doesn't require zooming, mobile renders, no overflow
+  3. **Would it make a person want to read more?** — earns the next scroll OR pushes the reader away with visual fatigue
+  4. **Is it helpful overall?** — orients vs overwhelms; teaches vs decorates; saves parse time vs costs it
+- Any "NO" or "MIXED" on criteria 3 or 4 = ROLLBACK or REDESIGN before commit. Don't ship visuals that fail user-perspective scoring just because they're technically rendering.
+- Verify the visual's POSITION on first-fold: at the typical laptop viewport (1280×800), does the new visual appear ABOVE the fold? If it doesn't, it cannot win the 3-second hook — relocate or accept it as a mid-page visual break (different acceptance criteria).
+- For Mermaid diagrams specifically: measure rendered height. If > 2× viewport height, the diagram is too tall — reader perceives it as a wall, not a hook. Caught 2026-05-19: my Hero Roadmap rendered at 1551px on mobile (2× viewport) and the cursive font's dash-strikethrough effect on phase labels degraded legibility further.
+
+**Cognitive load + F-pattern rules (mandatory for long-form posts > 800 words):**
+- Research-grounded rules from `docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.05-content-organization-patterns-2026.md` Part 2 (Gloria Mark / Pew 2026 / NN/g F-pattern / Sweller CLT). Pew 2026: 71% of readers scroll past within 3 seconds without a visual hook; Gloria Mark 2026: per-screen attention = 43s.
+- **First 3 seconds visual hook (hero rule):** every long-form post needs a visual within the first viewport - hero diagram, infographic, hero illustration, or a strong styled callout. Pure-text hero = guaranteed dropout for 71% of readers per Pew 2026. Decorative photography does NOT count.
+- **Repetitive parallel sections must NOT be 6+ identical bullets or 6+ identical table rows.** Module indexes, template lists, mistake lists, decision lists — break into a card grid OR add per-item icons. Single-column tables with 6+ rows and identical-format bullet lists with 6+ items both trigger the F-pattern "give up + vertical scan only" failure mode (NN/g eye-tracking).
+- **Decision-oriented sections use decision-aid format.** Anywhere the post asks "if X then Y" (rescue triage, decision trees, scoring tables, "should you...") render as flowchart/decision-table, not as a numbered list. Founder readers are in high cognitive load already; a flowchart cuts parse time vs. prose.
+- **Labels INSIDE diagrams, not beside them** (Sweller's split-attention effect). A labeled flowchart works. A flowchart followed by a 200-word "what this shows" paragraph increases cognitive load. If the diagram needs a separate explanation paragraph, fix the diagram - integrate the labels.
+- **No decorative visuals.** Stock photography of "happy founders at laptops," abstract gradients, generic icon arrays without informational content all violate the CLT integration rule. If removing the visual wouldn't lose information, the visual is decorative - delete it.
+- **One visual break per H2.** Plain prose blocks ≥3 H2s in a row = density problem; readers drop off. Acceptable visual breaks: diagram, table, code block, pull-quote callout, icon row. Mermaid diagrams count; bold paragraph leaders do NOT.
+- **Hand-drawn / Excalidraw-style sketches**: allowed when the sketch IS the diagram (informational); rejected when the sketch is decorative ornament beside a separate diagram. Per voice guide, prefer Mermaid + sketchy SVG over polished corporate infographics for the JT brand.
+
 ---
 
 ## 📋 Quick Reference
diff --git a/Gemfile.lock b/Gemfile.lock
index 01e3284c4..f3e7c096c 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,6 +1,6 @@
 GIT
   remote: https://github.com/snap-diff/snap_diff-capybara.git
-  revision: 64c5aef861fee4f80b49fca3841d53c95280c657
+  revision: 5ee298fbc3c1e070c78e3d83862ffd3228204214
   specs:
     capybara-screenshot-diff (1.12.0)
       capybara (>= 2, < 4)
@@ -44,11 +44,11 @@ GEM
     csv (3.3.5)
     docile (1.4.1)
     drb (2.2.3)
-    faraday (2.14.1)
+    faraday (2.14.2)
       faraday-net_http (>= 2.0, < 3.5)
       json
       logger
-    faraday-net_http (3.4.2)
+    faraday-net_http (3.4.4)
       net-http (~> 0.5)
     ffi (1.17.4)
     ffi (1.17.4-arm64-darwin)
@@ -58,7 +58,7 @@ GEM
       multi_xml (>= 0.5.2)
     i18n (1.14.8)
       concurrent-ruby (~> 1.0)
-    json (2.19.5)
+    json (2.19.8)
     language_server-protocol (3.17.0.5)
     launchy (3.1.1)
       addressable (~> 2.8)
@@ -90,7 +90,7 @@ GEM
       racc
     prism (1.9.0)
     public_suffix (7.0.5)
-    puma (8.0.1)
+    puma (8.0.2)
       nio4r (~> 2.0)
     racc (1.8.1)
     rack (3.2.6)
@@ -121,11 +121,11 @@ GEM
       rubocop (>= 1.75.0, < 2.0)
       rubocop-ast (>= 1.47.1, < 2.0)
     ruby-progressbar (1.13.0)
-    rubyzip (3.3.0)
+    rubyzip (3.3.1)
     sanity-ruby (0.8.0)
       activemodel
     securerandom (0.4.1)
-    selenium-webdriver (4.43.0)
+    selenium-webdriver (4.44.0)
       base64 (~> 0.2)
       logger (~> 1.4)
       rexml (~> 3.2, >= 3.2.5)
diff --git a/LEAN-CTX.md b/LEAN-CTX.md
deleted file mode 100644
index e3cf3c912..000000000
--- a/LEAN-CTX.md
+++ /dev/null
@@ -1,35 +0,0 @@
-
-# lean-ctx — Context Engineering Layer
-
-
-PREFER lean-ctx MCP tools over native equivalents for token savings:
-
-## Tool preference:
-| PREFER | OVER | Why |
-|--------|------|-----|
-| `ctx_read(path, mode)` | `Read` / `cat` | Cached, 10 read modes, re-reads ~13 tokens |
-| `ctx_shell(command)` | `Shell` / `bash` | Pattern compression for git/npm/cargo output |
-| `ctx_search(pattern, path)` | `Grep` / `rg` | Compact, token-efficient results |
-| `ctx_tree(path, depth)` | `ls` / `find` | Compact directory maps |
-| `ctx_edit(path, old_string, new_string)` | `Edit` (when Read unavailable) | Search-and-replace without native Read |
-
-## ctx_read modes:
-- `auto` — auto-select optimal mode (recommended default)
-- `full` — cached read (files you edit)
-- `map` — deps + exports (context-only files)
-- `signatures` — API surface only
-- `diff` — changed lines after edits
-- `aggressive` — maximum compression (context only)
-- `entropy` — highlight high-entropy fragments
-- `task` — IB-filtered (task relevant)
-- `reference` — quote-friendly minimal excerpts
-- `lines:N-M` — specific range
-
-## File editing:
-Use native Edit/StrReplace if available. If Edit requires Read and Read is unavailable, use ctx_edit.
-Write, Delete, Glob → use normally. NEVER loop on Edit failures — switch to ctx_edit immediately.
-
-## Proactive (use without being asked):
-- `ctx_overview(task)` at session start
-- `ctx_compress` when context grows large
-
diff --git a/Rakefile b/Rakefile
index 0cd78efdc..9da5beb8a 100644
--- a/Rakefile
+++ b/Rakefile
@@ -26,6 +26,12 @@ namespace :test do
     t.libs << "lib"
     t.pattern = "test/system/*_test.rb"
   end
+
+  Rake::TestTask.new(:integration) do |t|
+    t.libs << "test"
+    t.libs << "lib"
+    t.pattern = "test/integration/**/*_test.rb"
+  end
 end
 
 desc "Build the site (Hugo)"
diff --git a/bin/check-node-runtime b/bin/check-node-runtime
new file mode 100755
index 000000000..8e732c795
--- /dev/null
+++ b/bin/check-node-runtime
@@ -0,0 +1,115 @@
+#!/usr/bin/env bash
+# bin/check-node-runtime — Checks and fixes Node runtime for Hugo's PostCSS
+#
+# Hugo's PostCSS pipe fails when `node` resolves to bun (via symlink or shim)
+# and production plugins (PurgeCSS, cssnano, autoprefixer) are enabled. This
+# can corrupt the Hugo asset cache (resources/_gen/assets) with broken output
+# that persists across CI runs.
+#
+# Checks:
+#   1. Symlink check — "node → bun" (catches CI's $HOME/.bun-as-node symlink)
+#   2. Runtime check — detects Bun global in Node context (catches shims, PATH)
+#
+# If bun is detected: clears asset cache + adjusts PATH to use real Node.
+#
+# Usage: ./bin/check-node-runtime
+# Exit codes:
+#   0 — system Node in use, no action needed
+#   1 — bun detected and fixed (cache cleared, PATH adjusted)
+#   2 — bun detected but couldn't find real Node.js (build will likely fail)
+
+set -euo pipefail
+
+NODE_PATH=$(which node 2>/dev/null || true)
+
+if [ -z "$NODE_PATH" ]; then
+  echo "❌ [check-node-runtime] No 'node' found in PATH"
+  exit 2
+fi
+
+# --- Detection: two-method approach ---
+
+IS_BUN=false
+
+# Method 1: symlink check (catches CI's explicit bun→node symlink)
+if [ -L "$NODE_PATH" ]; then
+  TARGET=$(readlink "$NODE_PATH")
+  BUN_PATH=$(which bun 2>/dev/null || true)
+  if [ -n "$BUN_PATH" ] && [ "$TARGET" = "$BUN_PATH" ]; then
+    IS_BUN=true
+  fi
+fi
+
+# Method 2: runtime check (catches any bun-as-node scenario)
+if [ "$IS_BUN" = false ]; then
+  if ! node -e "process.exit(typeof Bun === 'undefined' ? 0 : 1)" 2>/dev/null; then
+    IS_BUN=true
+  fi
+fi
+
+if [ "$IS_BUN" = false ]; then
+  echo "✓ [check-node-runtime] 'node' is real Node.js ($(node --version))"
+  exit 0
+fi
+
+# --- Bun detected ---
+
+echo "⚠️  [check-node-runtime] 'node' resolves to bun"
+echo "   Path: $NODE_PATH"
+echo "   Hugo's PostCSS fails with bun when production plugins are enabled."
+echo ""
+
+# Step 1: Clear Hugo asset cache (may contain stale bun-produced output)
+if [ -d "resources/_gen/assets" ]; then
+  echo "   Clearing resources/_gen/assets to force clean PostCSS..."
+  rm -rf resources/_gen/assets
+  echo "   ✓ Asset cache cleared"
+  echo ""
+fi
+
+# Step 2: Find real Node.js
+# Search order: PATH (excluding bun dirs), known locations
+REAL_NODE=""
+
+# Remove bun-as-node directories and search PATH first
+REAL_NODE_CANDIDATE=$(echo "$PATH" | tr ':' '\n' | while IFS= read -r d; do
+  if [ -f "$d/node" ] && [ -L "$d/node" ]; then
+    TGT=$(readlink "$d/node" 2>/dev/null || echo "")
+    BUN=$(which bun 2>/dev/null || true)
+    [ "$TGT" != "$BUN" ] && echo "$d/node"
+  elif [ -x "$d/node" ] && [ ! -L "$d/node" ]; then
+    echo "$d/node"
+  fi
+done | head -1)
+
+if [ -n "$REAL_NODE_CANDIDATE" ]; then
+  REAL_NODE="$REAL_NODE_CANDIDATE"
+elif [ -x "/usr/local/bin/node" ]; then
+  REAL_NODE="/usr/local/bin/node"
+elif [ -x "/usr/bin/node" ]; then
+  REAL_NODE="/usr/bin/node"
+elif [ -x "/opt/homebrew/bin/node" ]; then
+  REAL_NODE="/opt/homebrew/bin/node"
+fi
+
+if [ -n "$REAL_NODE" ] && [ "$REAL_NODE" != "$NODE_PATH" ]; then
+  echo "   Found real Node.js at: $REAL_NODE ($($REAL_NODE --version))"
+
+  # Remove bun-as-node directories from PATH
+  DIR_TO_REMOVE=$(dirname "$NODE_PATH")
+  NEW_PATH=$(echo "$PATH" | tr ':' '\n' | grep -v "$DIR_TO_REMOVE" | tr '\n' ':')
+  # Ensure real node's parent dir is in PATH (prepend if not)
+  REAL_DIR=$(dirname "$REAL_NODE")
+  if ! echo "$NEW_PATH" | tr ':' '\n' | grep -qxF "$REAL_DIR" 2>/dev/null; then
+    NEW_PATH="$REAL_DIR:$NEW_PATH"
+  fi
+  export PATH="$NEW_PATH"
+
+  echo "   ✓ PATH adjusted. 'node' is now: $(which node) ($(node --version))"
+  echo ""
+  echo "✓ [check-node-runtime] Runtime fixed — ready for PostCSS build"
+  exit 1
+else
+  echo "   ❌ Could not find real Node.js. PostCSS build will likely fail."
+  exit 2
+fi
diff --git a/bin/dev b/bin/dev
index e1299cca7..c99d094f2 100755
--- a/bin/dev
+++ b/bin/dev
@@ -22,11 +22,17 @@ echo ""
 # - Applies development config overrides
 # - Optimizes for fast rebuilds
 
-# Project uses Bun for JS, never Node. bin/shims/node forwards Hugo's
-# hardcoded "node" lookup to bun. The [security.node.permissions]
-# block in hugo.toml is a defensive fallback for vanilla Node 22+.
+# Set HUGO_ENVIRONMENT for PostCSS (postcss.config.js checks this to
+# skip PurgeCSS, cssnano, and other expensive plugins in dev mode).
+# Hugo does not automatically export this env var to Node child processes.
+export HUGO_ENVIRONMENT="development"
+
+# Add node_modules/.bin to PATH for npm CLI tools.
+# NOTE: We intentionally do NOT include bin/shims (the node→bun shim)
+# here because Hugo's postCSS pipe in server mode fails with bun.
+# Build mode (bin/hugo-build) includes the shim where it works fine.
 SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-PATH="$SCRIPT_DIR/shims:$SCRIPT_DIR/../node_modules/.bin:$PATH"
+PATH="$SCRIPT_DIR/../node_modules/.bin:$PATH"
 export PATH
 
 exec hugo server \
diff --git a/bin/generate-cover-image b/bin/generate-cover-image
deleted file mode 100755
index f930fba75..000000000
--- a/bin/generate-cover-image
+++ /dev/null
@@ -1,39 +0,0 @@
-#!/usr/bin/env bash
-# Generate a blog cover image via gemini CLI (Nano Banana 2).
-#
-# Usage:    bin/generate-cover-image  "concept sentence"
-# Example:  bin/generate-cover-image my-post "pausing and resuming a long computation"
-# Requires: GEMINI_API_KEY from https://aistudio.google.com/app/apikey
-# Design:   docs/projects/2510-seo-content-strategy/20-29-strategy/20.06-blog-cover-image-design-system.md
-
-set -euo pipefail
-
-[[ $# -eq 2 ]] || { sed -n '2,7p' "$0" | sed 's/^# \{0,1\}//' >&2; exit 1; }
-
-SLUG="$1"
-CONCEPT="$2"
-REPO_ROOT="$(cd "$(dirname "$0")/.." && pwd)"
-POST_DIR="${REPO_ROOT}/content/blog/${SLUG}"
-OUT="${POST_DIR}/cover.jpg"
-
-[[ -d $POST_DIR ]] || { echo "error: post dir not found: content/blog/${SLUG}" >&2; exit 1; }
-
-trap 'echo; echo "hint: if 404, export GEMINI_API_KEY from https://aistudio.google.com/app/apikey and retry" >&2' ERR
-
-echo "→ generating $OUT"
-
-gemini \
-    --model gemini-3.1-flash-image-preview \
-    --approval-mode yolo \
-    -p "Generate a 1200x630 JPEG cover image, save to exactly: ${OUT}
-
-Style: minimalist hand-drawn digital sketch, 2-3pt charcoal (#333333) line art on cream (#FFF9F0), subtle paper grain, slight hand-drawn imperfections.
-Composition: single focal point, 60-70% negative space, 15% margin, one hero element only.
-Content: translate the concept into a physical/natural/architectural visual metaphor — not a literal depiction. No code, screens, terminals, keyboards, language logos, robots, gears, or lightbulbs.
-Prohibitions: no text, letters, logos, UI chrome, neon, or 3D.
-
-
-${CONCEPT}
-"
-
-echo "✓ done: $OUT"
diff --git a/bin/hugo-build b/bin/hugo-build
index c7ba1387c..3f0c9db7c 100755
--- a/bin/hugo-build
+++ b/bin/hugo-build
@@ -7,6 +7,11 @@ set -euo pipefail
 OUTPUT_DIR=${OUTPUT_DIR:-_dest/public-dev}
 ENVIRONMENT=${ENVIRONMENT:-development}
 
+# Set HUGO_ENVIRONMENT for PostCSS (postcss.config.js checks this to
+# skip PurgeCSS, cssnano, and other expensive plugins in dev mode).
+# Hugo does not automatically export this env var to Node child processes.
+export HUGO_ENVIRONMENT="$ENVIRONMENT"
+
 BASE_URL=${BASE_URL:-}
 
 echo "Building Hugo site..."
@@ -15,13 +20,27 @@ echo "Output: $OUTPUT_DIR"
 
 BUILD_DRAFTS=${BUILD_DRAFTS:-}
 
-# Project uses Bun for JS, never Node. bin/shims/node forwards Hugo's
-# hardcoded "node" lookup to bun. The [security.node.permissions]
-# block in hugo.toml is a defensive fallback for vanilla Node 22+.
+# Add node_modules/.bin to PATH for npm CLI tools.
+# NOTE: We intentionally do NOT include bin/shims (the node→bun shim)
+# because Hugo's postCSS pipe fails with bun when production plugins
+# (PurgeCSS, cssnano, etc.) are enabled. The CI workflow creates its
+# own bun→node symlink separately — that's a CI-level concern.
 SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-PATH="$SCRIPT_DIR/shims:$SCRIPT_DIR/../node_modules/.bin:$PATH"
+PATH="$SCRIPT_DIR/../node_modules/.bin:$PATH"
 export PATH
 
+# Run course source-of-truth validators before building
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+if [ -f "$SCRIPT_DIR/validate-course" ]; then
+  echo "Running course validators..."
+  if ! "$SCRIPT_DIR/validate-course"; then
+    echo ""
+    echo "❌ Course validators failed. Fix violations before building."
+    echo "   Run bin/validate-course --verbose for full details."
+    exit 1
+  fi
+fi
+
 HUGO_ARGS=(hugo build --noBuildLock --environment "$ENVIRONMENT" --destination "$OUTPUT_DIR")
 [ -n "$BASE_URL" ] && HUGO_ARGS+=(--baseURL "$BASE_URL")
 [ -n "$BUILD_DRAFTS" ] && HUGO_ARGS+=(--buildDrafts)
diff --git a/bin/validate-course b/bin/validate-course
new file mode 100755
index 000000000..e5561a447
--- /dev/null
+++ b/bin/validate-course
@@ -0,0 +1,62 @@
+#!/usr/bin/env ruby
+# frozen_string_literal: true
+
+# Source-of-truth validator runner for the course project.
+# Exits with non-zero status if any validator fails.
+#
+# Usage:
+#   bin/validate-course              # Run all validators
+#   bin/validate-course --json      # Output as JSON
+#   bin/validate-course --verbose   # Detailed output per chapter
+
+require "json"
+require_relative "../lib/course_validators"
+
+verbose = ARGV.delete("--verbose")
+json_output = ARGV.delete("--json")
+
+results = CourseValidators.run_all
+
+failed = results.reject(&:passed)
+passed = results.select(&:passed)
+
+if json_output
+  output = results.map do |r|
+    {
+      validator: r.name,
+      passed: r.passed,
+      violations: r.violations
+    }
+  end
+  puts JSON.pretty_generate(output)
+  exit(failed.any? ? 1 : 0)
+end
+
+separator = "─" * 60
+
+puts ""
+puts separator
+puts "  Course Source-of-Truth Validators"
+puts separator
+puts ""
+
+results.each do |r|
+  if verbose || !r.passed
+    puts r.to_s
+    puts ""
+  end
+end
+
+puts separator
+if failed.empty?
+  puts "  ✅  ALL #{results.length} VALIDATORS PASSED"
+else
+  puts "  ❌  #{failed.length} of #{results.length} validators FAILED"
+  failed.each do |r|
+    puts "     • #{r.name}: #{r.violations.length} violation(s)"
+  end
+end
+puts separator
+puts ""
+
+exit(failed.any? ? 1 : 0)
diff --git a/bun.lockb b/bun.lockb
index f9e39909d..85ef6c015 100755
Binary files a/bun.lockb and b/bun.lockb differ
diff --git a/config/_default/hugo.toml b/config/_default/hugo.toml
index 89efc921a..69bd90b60 100644
--- a/config/_default/hugo.toml
+++ b/config/_default/hugo.toml
@@ -190,6 +190,12 @@ disableKinds = []
   pageRef= "blog/"
   weight = 25
 
+[[menu.main]]
+  identifier = "course"
+  name = "Course"
+  pageRef= "course/tech-for-non-technical-founders-2026/"
+  weight = 28
+
 [[menu.main]]
   identifier = "about-us"
   name = "About Us"
diff --git a/content/course/tech-for-non-technical-founders-2026/_index.md b/content/course/tech-for-non-technical-founders-2026/_index.md
new file mode 100644
index 000000000..80da00181
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/_index.md
@@ -0,0 +1,207 @@
+---
+title: "From Idea to First Paying Customer"
+description: "From idea to first paying users in 2026, with or without engineers. A free five-module course for non-technical founders: hypothesis, validation, design, build, first paying customer."
+date: 2026-05-13
+draft: false
+author: "JetThoughts Team"
+slug: tech-for-non-technical-founders-2026
+keywords:
+  - tech for non technical founders 2026
+  - free founder course
+  - non technical founder course
+  - founder education 2026
+  - solo founder MVP
+tags:
+  - founders
+  - non-technical-founder
+  - course-index
+  - course-landing
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "From Idea to First Paying Customer - A Non-Technical Founder's Course"
+  og_description: "From idea to first paying users in 2026, with or without engineers. Five modules that produce the evidence investors actually fund - smoke test data, interview transcripts, live MVP, signed paid pilot."
+cover_image_alt: "JetThoughts course landing cover showing 5 modules (Hypothesis, Validate, Design, Build, First Customer) on the route from idea to first paying users"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/"
+related_posts: false
+---
+
+Getting from idea to a product someone pays for is harder when you can't read the code. This course is the linear route - five modules from a one-sentence hypothesis to a first paid pilot. The hiring, managing, and rescue chapters wait at the end for the day you actually need them.
+
+Investors fund evidence, not ideas. A pitch deck gets you the meeting. A signed paid pilot, 10 scored interview transcripts, and a live MVP with real users gets you the check. This course produces the evidence.
+
+The 2026 version of this work uses tools that didn't exist five years ago - AI app builders like Lovable and Bolt, hosted backend services like Supabase, hosted payments like Stripe Checkout, AI persona rehearsal in Claude or ChatGPT. One non-technical founder can now ship the full validate-build-pilot loop on evenings and weekends, without hiring an engineer. The course names which tool does which job at each step, and what each one costs (most have a free tier).
+
+> **Start here:**
+> - [**Quickstart**](/course/tech-for-non-technical-founders-2026/quickstart/) - 1 page, 3-minute read: the minimal path for time-starved founders (core lessons only, gate thresholds, "start here" button).
+> - [**How This Course Works**](/course/tech-for-non-technical-founders-2026/how-this-course-works/) - 5-minute read: the full route at a glance - 5 modules, 21 chapters, 6 artifacts (your "Founder OS" - a single Google Drive folder where each module drops one fill-in-the-blank document you can hand to an investor).
+> - [**FAQ**](/course/tech-for-non-technical-founders-2026/faq/) - 15 Q&A for typical blockers: Stripe verification, Mom Test scores below 7, finding 10 people, builder paralysis, asking for money.
+>
+> Free. No sign-up. Start tonight.
+
+> **New founder, no team, no trauma?** Skip the diagnostic. Start at [Chapter 1.1 - Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/).
+
+*Returning? [Skip to the syllabus ↓](#module-index)*
+
+## What this course does NOT cover
+
+To save your time, here is what we intentionally exclude. None of these are needed for the promised result (idea → first paying customer):
+
+- **How to code.** The course assumes zero coding ability. Lovable + Supabase + Stripe handle the technical side.
+- **How to hire a CTO or build an engineering team.** Hiring is covered as a build-path decision (Chapter 4.1), not as an org-design course. If you need a team, you've outgrown this course.
+- **How to raise venture capital.** The course produces evidence investors fund (signed paid pilot, validated problem statement, live MVP). It does not teach pitch decks, term sheets, or fundraising mechanics.
+- **How to manage a 20-person engineering team.** Friday Demo Rule + Weekly Dev Report (in Going Further chapters) cover early-stage management; full org management is out of scope.
+- **Mobile-only or marketplace-only specifics.** Examples use SaaS + B2B + B2C patterns. Mobile apps and two-sided marketplaces have their own playbooks.
+- **Legal incorporation, taxes, IP filings.** Use a lawyer or a service (Stripe Atlas, Clerky, Firstbase). The course assumes you can sign contracts under your existing business entity.
+- **SEO, content marketing, paid acquisition at scale.** Module 5 covers first-10-customers outbound. Scaling acquisition is a separate discipline; come back after you have product-market fit.
+
+## Why this course exists
+
+At the idea stage, the cheapest mistake is the one you skip making by reading the course before you start building. Five mistakes new founders make most often, and where in the course we avoid each one:
+
+- Hiring a dev shop before validating the problem - Modules 1 and 2 show what a $0 validation looks like.
+- Paying for six months of "building" with no way to see what shipped - Module 4.2 (Day-1 ownership) plus the Friday-demo rule in the management chapters cover this.
+- Signing a contract (an "SOW", Statement of Work - the doc that defines what the agency is paid to deliver) where "delivered" means "deployed to staging" - the SOW reading guide flags the bad clauses.
+- Rebuilding from scratch when salvage would have closed the gap in eight weeks - the salvage-vs-rebuild scorer keeps you out of unnecessary rewrites.
+- Shipping an AI feature only to discover the agency was passing per-question AI costs ("OpenAI tokens" - the pay-per-word AI invoicing model) through the invoice without telling you - the AI agency questions chapter catches this on the first discovery call.
+
+Already mid-build and it's failing? Jump to the [rescue chapters](/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/) at the end. Everyone else: start at Module 1.
+
+> **How this is different from Y Combinator / Lenny / Reforge.** Y Combinator Startup School teaches the "talk to users, prioritize them over features" principle through weekly updates and library lectures. Lenny Rachitsky publishes deep essays on each phase (validation, PMF, growth, hiring) as a newsletter and reference library. Reforge sells cohort-based courses designed for product managers and growth leaders with 6+ years of experience at scale-stage companies.
+>
+> This course walks a non-technical founder with neither a team nor a built product from a one-sentence hypothesis to a signed paid pilot, on evenings and weekends.
+>
+> Three chapters we have not found systematized in those competitors' catalogues as of May 2026: [Ch 1.3 - Stripe Payment Link as price-hypothesis test](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/), [Ch 4.1 - four-way build-path decision matrix](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/), and [Ch 5.4 - Design Partner Agreement with deposit math](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) that turns verbal yes-es into paid pilots.
+
+## Take this course if
+
+- You have an idea, or a half-built MVP, and want a route from there to a paying customer
+- You can read a Stripe invoice but not a GitHub commit
+- You want to know what to ask, not what to build
+- You write code yourself but want a structured pass on the validation stage (Modules 1-4) before you start typing
+
+If you're at the rescue stage instead - inherited a half-built codebase, told "the architecture is fine" with no way to verify, considering firing your current team - skip the linear path and start with the conditional chapters under [Going further](#going-further-after-first-paying-customer) and [If Your Team Is Already Failing](#if-your-team-is-already-failing) below.
+
+## This is not for you if
+
+- You want to learn to code
+- You want to outsource founder judgment
+
+## What this course does NOT cover (and why)
+
+We cut these topics intentionally - you don't need them to get from idea to first paying customer:
+
+- **How to code** - the entire course uses no-code tools (Lovable, Carrd, Stripe Payment Links). You prompt, click, and configure. Zero lines of code.
+- **How to hire a CTO** - the course route is self-serve by default. Ch 4.1 covers when to hire, not how to interview.
+- **How to raise venture capital** - the artifacts this course produces (live MVP, signed paid pilot) are what investors want to see, but pitching is outside scope.
+- **How to manage an engineering team** - the management chapters are post-pilot reference material, not in the linear path.
+- **How to build a marketplace, a mobile app, or an AI model** - the stack is B2B SaaS web apps (Lovable + Supabase). Different product shapes need different tools.
+- **Legal advice, incorporation, or tax structure** - the DPA template is a starting point, not a legal document. Consult a lawyer.
+- **SEO, content marketing, paid ads at scale** - Module 1 runs a $300 smoke test. Post-pilot growth marketing is a different discipline.
+
+If you need something on this list, the course won't help with it. If you don't, you're in the right place.
+
+## What you need to start
+
+An idea, or a half-built MVP. The course shows you how to validate it cheaply, find the version with real demand, and confirm there's a business before you commit money to building.
+
+## What you walk away with
+
+A personal **Founder OS** - six filled-in artifacts that prove demand before you ask for a dollar of outside capital:
+
+1. A one-sentence **Founding Hypothesis** - shows an investor you didn't start with a build, you started with a falsifiable bet (Module 1)
+2. A landing-page **smoke test decision** + price point - proves strangers clicked and some reached for their wallet (Module 1)
+3. Ten **Mom Test interview notes** + prototype feedback - proves you didn't build in a vacuum, you built from evidence (Module 2)
+4. A one-page **Product Brief** - shows an investor the scope is constrained by customer language, not feature fantasies (Module 3)
+5. A **live MVP** at a real URL, ownership locked Day 1 - proves you can ship without an engineer and nobody holds the keys but you (Module 4)
+6. A **first signed paid pilot** + channel sequence running - proves someone who doesn't know you paid real money (Module 5)
+
+Investors don't fund ideas. They fund evidence. Each artifact answers a question they will ask. Walk into the meeting with the folder and you answer six of them before the first slide.
+
+## Module index
+
+> Before you start: read [**How This Course Works**](/course/tech-for-non-technical-founders-2026/how-this-course-works/) - the full route at a glance: 5 modules, 20 chapters, the AI tools that accelerate each stage, and the tool stack reference.
+>
+> Length is a byproduct of effective delivery, not a constraint. The course is paced for an idea-stage non-technical founder on evenings and weekends. Read the modules in order; each module's output is the next module's input.
+
+### Module 1 - Hypothesis & Smoke Test
+*Output: One-sentence Founding Hypothesis + a live landing page with Stripe price button.*
+*Start here if you don't have a one-sentence Founding Hypothesis yet (customer + problem + approach + competition + differentiation), or you have a hypothesis but never tested demand with a landing page.*
+- [**1.1** · Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/)
+  - Before you write the hypothesis: [stress-test the blanks with AI](/course/tech-for-non-technical-founders-2026/validation-tools-field-guide/).
+- [**1.2a** · Smoke Test: Build the Page](/course/tech-for-non-technical-founders-2026/smoke-test-build-page/)
+- [**1.2b** · Wire Tracking Before You Spend a Dollar](/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/)
+- [**1.2c** · Smoke Test: Run It and Read the Signal](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/)
+- [**1.3** · Price Your Hypothesis on the Smoke-Test Page](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/)
+
+### Module 2 - Validate the Problem
+*Output: 10 Mom Test interviews + a Lovable prototype shown to 5 of them.*
+*Start here if you've never talked to 10+ potential customers about the problem you want to solve.*
+- [**2.1** · The Mom Test: Ask About the Past, Not the Future](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/)
+  - Templates: [Mom Test Interview Script](/course/tech-for-non-technical-founders-2026/mom-test-interview-script/) · [Validated Problem Statement](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/)
+- [**2.2** · OPTIONAL - Sharpen Your Question List with AI Personas](/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/)  
+  *Skip this if you've interviewed before or don't have 90 minutes. The Mom Test technique in 2.1 is the core; this chapter rehearses your questions with AI personas before real interviews.*
+- [**2.3a** · Find 10 People: Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/)
+- [**2.3b** · Find 10 People: What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/)
+  - Template: [Outreach Sequence Template](/course/tech-for-non-technical-founders-2026/outreach-sequence-template/)
+  - After interviews: [Mom Test Synthesis - Build, Pivot, or Kill](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/)
+- [**2.4** · Build a Clickable Prototype](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/)
+
+### Module 3 - Design from Evidence
+*Output: One-page Product Brief drafted from interview transcripts.*
+*Start here if you've validated the problem but don't have a one-page Product Brief.*
+- [**3.1** · The One-Page Product Brief (Vibe PRD)](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/)
+  - Template: [Vibe PRD Template](/course/tech-for-non-technical-founders-2026/vibe-prd-template/)
+- [**3.2** · Quality-check your brief: features to outcomes](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/)
+
+*Course glossary (reference, not in the linear path):* [Five Tech Words to Stop Nodding At](/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/) - skim once, come back when you hit a word you nodded at.
+
+### Module 4 - Build It Yourself
+*Output: Live Lovable + Supabase + Stripe MVP at a real URL, ownership locked Day 1.*
+*Start here if you have a Product Brief and need to build the MVP.*
+- [**4.1** · Should You Hire? The 2026 Decision Tree](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/)
+  - Template: [Build Path Decision Worksheet](/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/)
+- [**4.2** · Who Owns Your GitHub, AWS, and Database?](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/)
+  - Template: [Ownership Checklist](/course/tech-for-non-technical-founders-2026/ownership-checklist/)
+- [**4.3a** · The Self-Serve MVP Stack: Tools & Setup](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/)
+- [**4.3b** · The Self-Serve MVP Stack: Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/)
+  - Template: [Self-Serve Stack Walkthrough](/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/)
+- [**4.4** · Vibe Coding Done Right: 5 Ceiling Signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/)
+
+### Module 5 - First Paying Customer
+*Output: One paying customer through a deliberately chosen channel.*
+*Start here if your MVP is live but you don't have a paying customer with a signed pilot.*
+- [**5.1** · Your First Customer Is Not a Marketing Problem](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/)
+- [**5.2** · OPTIONAL - Choose Your Channel Before You Send One Message](/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/)  
+  *Skip this if you already have a channel in mind (LinkedIn, cold email, or personal network). The core path is 5.3 (personal network) → 5.4 (paid pilot).*
+- [**5.3** · The First Ten Come From People Who Already Know You](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/)
+- [**5.4** · Charge Before You Ship: The Paid Pilot Contract](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/)
+  - Template: [First Paying Customer Operating Kit](/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/)
+- [**5.5** · Going Outbound Without a Sales Team](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/)
+
+## Going further (after first paying customer)
+
+These continuation chapters apply once you've passed the Module 5 gate (one paying customer):
+
+- **If your customers are leaving:** [Churn Triage Before Acquisition](/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/)
+- **If a key metric has stalled for 2+ months:** [Pivot or Persevere](/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/)
+- **If you've hit the self-serve ceiling and need to hire:** [Hire Track Supplementary Reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/)
+- **Management chapters (return when you have a hired team):** [Org Chart](/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/) | [Friday Demo Rule](/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/) | [Three Standup Questions](/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/) | [Weekly Dev Report](/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/)
+- **If your product touches AI in production:** [Agency AI Questions](/course/tech-for-non-technical-founders-2026/agency-uses-ai-follow-up-questions/) | [AI Token Bill](/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/) | [Slopsquatting](/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/)
+
+## If Your Team Is Already Failing
+
+This section is a side-path for readers in active rescue. If you're working from an idea or a half-built MVP without a team, skip to [Module 1](#module-1---hypothesis--smoke-test).
+
+If you're reading this in the middle of a stalled build or a runaway invoice, the rest of the course can wait. Run these 5 steps now.
+
+1. Check who owns GitHub, AWS, database, and domain. If it's not you, fix that first. - [Ownership Audit](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/)
+2. Demand one Friday demo with working software only - no Jira, no slides, no "almost done." - [Friday Demo Rule](/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/)
+3. Require a plain-English weekly report: what shipped, what's blocked, what's next. - [Weekly Dev Report](/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/)
+4. Score salvage vs rebuild and plan your team transition before you authorize any more work. - [Salvage vs Rebuild and Team Transition Reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/)
+5. If your team is shipping AI features, run the 5-question agency audit before approving more work. - ["We Use AI" Follow-Up Questions](/course/tech-for-non-technical-founders-2026/agency-uses-ai-follow-up-questions/)
+
+## Who built this
+
+Built by [JetThoughts](https://jetthoughts.com). Rails-first dev shop, in business since 2005. The course is what we wish every founder had on their desk before the first build decision.
diff --git a/content/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/cover.png b/content/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/cover.png
new file mode 100644
index 000000000..e035650a9
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/index.md b/content/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/index.md
new file mode 100644
index 000000000..477d9523d
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/index.md
@@ -0,0 +1,129 @@
+---
+title: '"We Use AI": 5 Follow-Up Questions for Your Agency'
+aliases: ["/blog/agency-ai-five-questions/"]
+description: "Five questions that catch AI theatre in 30 minutes. Hand them to your next agency call before you sign anything. Score 0-5; below 3 means walk."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: agency-ai-five-questions
+keywords:
+  - agency uses ai questions
+  - hire ai augmented developer
+  - founder catch ai theatre
+  - non technical founder ai interview
+  - ai agency interrogation script
+tags:
+  - founders
+  - non-technical-founder
+  - template
+  - course-companion
+  - ai-era
+categories: ["Templates"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/"
+related_posts: false
+---
+
+📋 Template companion to the "Manage AI-Era Risks" path of the [From Idea to First Paying Customer course](/course/tech-for-non-technical-founders-2026/). Send 24 hours before the discovery call. Score in real time during the call.
+
+# The "We Use AI" 5-Question Script
+
+Five questions that catch AI theatre in 30 minutes - hand them to your next agency call before you sign anything.
+
+By the end of one Tuesday discovery call you will know whether the agency claiming "we use AI to ship 3x faster" can describe what their developers do with Cursor on a Wednesday morning, or whether the AI talk is a slide. Five questions, sent in writing 24 hours before the call, scored 0 or 1 in real time. Two failed questions is a walkaway.
+
+A founder we picked up in Q1 2026 had been three weeks deep with an "AI-native" agency that promised a four-week MVP for $34K. She asked for a walkthrough of one PR the team had merged that week. The lead developer screenshared a staging branch; her independent advisor paused the screen-share and pointed at line 14 of `config/database.yml`: an OpenAI API key, a Stripe live key, and a database password committed in plaintext, on a public-by-default GitHub repo.
+
+Then he opened the agency's OpenAI billing dashboard the developer had also screenshared by accident: **$4,800 in API charges in the last 30 days**, no project tags, no per-developer attribution, and the agency owner could not explain which client the spend belonged to. She walked. The five questions below would have caught both in the first 20 minutes.
+
+Most agencies in 2026 are not malicious about AI. They adopted Cursor in a hurry, never wrote down a workflow, and never priced the token bill. The damage is the same either way.
+
+## How to use it
+
+Send the five questions in writing 24 hours before the call with one sentence: "We will work through these together on Tuesday; please come prepared." Do not soften it.
+
+Score in real time - 0 or 1 per question, in a Notion doc next to each answer. A score of 3+ is a pass with conditions. A score of 2 or below means do not sign, no matter how impressive the rest of the pitch. Forward your scoring doc to your independent advisor or fractional CTO the same evening for a 15-minute sanity-check call.
+
+If the agency declines to answer in advance, that is a 0 on every question. Exercise over.
+
+## The five questions
+
+### Q1 - The workflow question
+
+> "Walk me through how a developer on your team takes a Jira ticket and ends up with merged code, when they use AI in the loop. Name the tools, the prompt patterns, and the human review gates. Use a real ticket your team closed last week."
+
+**Pass:** Tools named by version - Cursor with Claude 4.5 Sonnet, or Claude Code, or Aider, or Copilot Enterprise. A written sequence: ticket - draft prompt - generate - run the failing test the developer wrote first - review the diff against the spec - PR with `Assisted-by:` tag - second human reviews - merge. The PR was reviewed by a different senior than the one who wrote the prompt. They offer to email the internal one-pager.
+
+**Fail:** "We let the senior dev decide." "It depends on the project." "AI is used where it makes sense." No named tool, no named gate, no real PR.
+
+**Score:** 1 if they name tools + a written workflow + a real PR. 0 otherwise.
+
+### Q2 - The cost question
+
+> "What does the average developer on your team spend on AI tokens per month, and who pays it? Will it pass through to my invoice, and what should I budget per month for the project we just scoped?"
+
+**Pass:** A per-developer dollar range ($80 to $300 per month for Cursor seats plus Anthropic and OpenAI API usage), a pass-through model written into the SOW, and a sample invoice line-item they will email after the call. They have a budget alert on the API account.
+
+**Fail:** "It is included in the rate." "We don't track it that closely." "We absorb the AI costs." Sign without this number and you get a surprise five-figure OpenAI charge in month two - the $4,800 line in the opening story was that number two weeks before the founder caught it.
+
+**Score:** 1 if they give a per-developer dollar range and a written pass-through policy. 0 otherwise.
+
+### Q3 - The verification question
+
+> "When AI generates a 200-line PR, what does your senior reviewer actually check? Walk me through one PR you reviewed last week and tell me what you looked for."
+
+**Pass:** The reviewer pulls up an actual PR on screenshare. Does the diff match the ticket spec, line by line? Any hardcoded secrets, API keys, or database passwords (the agency in the opening story would have caught the `database.yml` problem here)? Are the tests genuine, written by the developer first as failing specs (the team's TDD discipline shows here), or AI-generated to pass after the fact? Did the AI introduce new gems or pip packages, and do they exist on Rubygems / PyPI and pass the team's allowlist?
+
+**Fail:** "We trust the model." "Cursor catches most issues." "We have automated checks in CI." A team that trusts the model will ship the SQL injection vector in [Veracode's 45% of AI-generated code](/blog/ai-code-ownership-accountability/) into your production database.
+
+**Score:** 1 if they show a real PR with named checks. 0 otherwise.
+
+### Q4 - The slopsquatting question
+
+*slopsquatting: when AI suggests a package name that doesn't exist, an attacker registers it, and your build pulls the malicious version. See the [dedicated chapter](/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/).*
+
+> "In April 2025 a security researcher published findings that AI assistants suggested over 200 package names across Rubygems, PyPI, and npm that did not exist; attackers register those names and wait for developers to install the typo. How does your team prevent installing a hallucinated gem or pip package?"
+
+**Pass:** A pre-vetted allowlist with a written process for adding new packages. A scanner like Socket or Snyk on every PR that blocks the build on new dependencies until a human approves. They use the term "slopsquatting" without prompting and cite the [Infosecurity Magazine writeup](https://www.infosecurity-magazine.com/news/ai-hallucinations-slopsquatting/) or the [SecurityWeek piece on AI coding agents and supply-chain risk](https://www.securityweek.com/ai-coding-agents-could-fuel-next-supply-chain-crisis/).
+
+**Fail:** "Our developers know what they are doing." "We use trusted packages." A confused look. An agency that has not heard of slopsquatting in May 2026 has not read their field's security press for a year.
+
+**Score:** 1 if they name a specific defense (allowlist, scanner, gated CI). 0 otherwise.
+
+### Q5 - The accountability question
+
+> "When AI-generated code causes a production incident, who is on the hook? Walk me through the last AI-generated-code incident your team had - what happened, when, and what you changed afterwards."
+
+**Pass:** A specific incident with a date in the last 6 months, a one-paragraph root cause, the named senior who reviewed the offending PR, and the workflow change made the week after. The kernel maintainers' [`Assisted-by:` rule](/blog/ai-code-ownership-accountability/) puts the human reviewer on the hook by name; an agency on that posture knows whose name is next to the bug.
+
+**Fail:** "We have never had an AI-related incident." (Either lying or never shipped to production - the [PocketOS database deletion](/blog/ai-agent-deleted-production-database-pocketos/) was a 9-second incident on a live SaaS the founder did not see coming.) Or: "AI code is the developer's responsibility." (No team-level accountability means no team-level review.)
+
+**Score:** 1 if they describe a specific incident with a date, root cause, and workflow change. 0 otherwise.
+
+## What good looks like vs what bad looks like
+
+The passing-agency pattern: the salesperson defers to the senior engineer on technical questions. The senior pulls up real artifacts on screenshare - a PR, an invoice line, a post-mortem. Specific tool names, dollar amounts, dates, people. The internal AI policy lands in your inbox the same day.
+
+The AI-theatre pattern: the salesperson takes every question. Answers come back as "we use AI to deliver faster value" or "our developers are AI-native." When you ask for a real PR or invoice line, the answer is "I will follow up." That follow-up does not arrive.
+
+One concrete contrast on Q3:
+
+> Bad: "Our senior reviews every PR. We have a high standard."
+> Good: "Open PR #1247 - Marcus reviewed it Tuesday morning. He flagged that Cursor had added `gem 'active_record_extras_helper'` to the Gemfile - a gem that does not exist on Rubygems. He blocked the merge and asked the developer to use the real `active_record_extra` gem. The hallucinated name would have been a slopsquat install if an attacker had registered it."
+
+## What to do after the call
+
+- **Forward your scored doc to your independent advisor the same evening** for a 15-minute paid review. Under $400 and the cheapest decision insurance you will buy this year.
+- **Score below 3:** send a polite "we are pausing the search to refine our requirements" note. Do not negotiate. The agency will argue the framing instead of fixing four gaps.
+- **Score 3-4:** ask for a 45-minute follow-up technical session with the senior reviewer (not the salesperson), working through one of your real product flows. If the senior cannot attend two sessions in two weeks, that tells you who actually staffs the project once you sign.
+- **Score 5:** do reference checks on AI-augmented projects specifically. Ask their last three clients about AI-related incidents, the OpenAI line on monthly invoices, and whether they have ever received an `Assisted-by:` commit log on request.
+
+Every agency uses AI in 2026. The five questions test whether they can describe what they are doing with it, what it costs, who reviews it, and whose name is on the line when it breaks. If they cannot, they are selling you the [quality tax](/blog/quality-tax-ai-mvp-cost/) - the four-month invoice that arrives after the demo, when AI-generated code meets a production load nobody tested against.
+
+## What to do tomorrow
+
+1. Schedule your next agency discovery call - block 30 minutes.
+2. Print the 5-question script (or pull up this page on your phone) and bring it to the call.
+3. After the call, score each answer 0 or 1 in real time (per the scoring rule above) - a total of 2 or below out of 5 means do not sign the SOW.
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/agency-uses-ai-follow-up-questions/cover.png b/content/course/tech-for-non-technical-founders-2026/agency-uses-ai-follow-up-questions/cover.png
new file mode 100644
index 000000000..fd1e773e9
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/agency-uses-ai-follow-up-questions/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/agency-uses-ai-follow-up-questions/index.md b/content/course/tech-for-non-technical-founders-2026/agency-uses-ai-follow-up-questions/index.md
new file mode 100644
index 000000000..f05ba2b8e
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/agency-uses-ai-follow-up-questions/index.md
@@ -0,0 +1,193 @@
+---
+title: "'We Use AI' - 5 Follow-Up Questions for Your Agency"
+aliases: ["/blog/agency-uses-ai-follow-up-questions/"]
+description: "Five follow-up questions that catch AI theatre in 30 minutes. Hand them to your next agency discovery call. Score 0-5 in real time. Below 3 means walk."
+date: 2026-05-18
+course_chapter: true
+author: "JetThoughts Team"
+slug: agency-uses-ai-follow-up-questions
+keywords:
+  - agency uses ai follow up questions
+  - vendor screening ai theatre
+  - non technical founder agency interview
+  - catch ai theatre 30 minutes
+  - ai era vendor due diligence
+tags:
+  - founders
+  - non-technical-founder
+  - course-companion
+  - ai-era
+  - vendor-screening
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "'We Use AI' - 5 Follow-Up Questions for Your Agency"
+  og_description: "Five follow-up questions that catch AI theatre in 30 minutes. Hand them to your next agency discovery call. Score 0-5 in real time. Below 3 means walk."
+cover_image_alt: "Hand-drawn 5-question agency scorecard with Pass and Fail circles and a red marker note that the score must reach 3 to keep talking"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/agency-uses-ai-follow-up-questions/"
+related_posts: false
+course_nav: false
+---
+
+> **Going further (AI in production) · Step 1 of 3** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** an agency claiming "we use AI to ship 3x faster."
+>
+> **Output:** a 30-minute interrogation that catches AI theatre before you sign
+
+**Supplementary content.** This chapter is relevant after you've shipped (Module 4+) and your product touches AI in production. Bookmark and return when needed.
+
+The agency's pitch deck said the weekly retainer was $14,200. The pitch deck also said "every PR ships with an `Assisted-by:` footer naming the human reviewer; AI direction is a first-class part of our delivery."
+
+A founder we picked up in Q3 2026 asked the senior engineer on the discovery call to open one such PR on screenshare. The engineer scrolled GitHub for forty seconds, then promised to email the link "by end of day." The link never arrived.
+
+Two hours of internal back-and-forth later the agency owner emailed back: the `Assisted-by:` line had been added to the pitch deck the week before the call. No PR in the repo carried it. The five questions below would have surfaced the gap inside the first 20 minutes, before any contract conversation, and saved the founder a $56,800 four-week commitment she would have unwound a month in.
+
+### The 5-question scorecard at a glance
+
+Score 0 or 1 in real time during the discovery call. Below 3 means walk.
+
+| # | Question | Pass (1) | Fail (0) |
+|---|---|---|---|
+| Q1 | **Workflow:** walk one Jira ticket to merged PR with AI | Named tools, written gates, real PR number from last week | Slogans, no PR shown |
+| Q2 | **Cost:** per-developer monthly AI token spend, who pays | Dollar range, pass-through written into SOW, sample invoice line | "It's all included" |
+| Q3 | **Verification:** what senior checks on a 200-line AI PR | Opens real PR on screenshare, names checks line by line | "We trust the model" |
+| Q4 | **Slopsquatting:** how do you stop a hallucinated package install | Named defense (allowlist, Socket/Snyk, gated CI), uses the term unprompted | Confused look |
+| Q5 | **Accountability:** who is on the hook for an AI-caused incident | Specific incident with date, root cause, named reviewer, workflow change | "We've never had one" |
+
+**Total: ___ / 5** · 5 = sign with confidence · 3-4 = ask for senior follow-up call · Below 3 = walk, no matter how good the rest of the pitch sounded.
+
+## Why every agency claims AI in 2026 - and why most cannot back it up
+
+Every agency website rewrote its homepage in 2026. "AI-augmented." "AI-native." "We ship 3x faster with AI in the loop." The term arrives in your inbox faster than the agency adopted the tools.
+
+The Stack Overflow [2025 Developer Survey](https://survey.stackoverflow.co/2025/) shows 84% of developers now use or plan to use AI tools, but Veracode's GenAI Code Security Report 2025 found 45% of LLM-generated code shipped at least one exploitable security flaw.
+
+Two populations live behind the same homepage copy: the shops that wrote a workflow, set a budget alert, and put a senior on the diff; and the shops that bought Cursor seats and changed nothing else. The five questions below are written to put both kinds of agency on the same call and watch which one shows up.
+
+## The 5 questions
+
+The full Pass/Fail rubric, scoring template, and "what to send 24 hours before the call" instructions live in the [companion 5-Question Script](/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/). Below is the prose explanation of why each question matters in 2026. Print the script. Read this post once.
+
+### Q1 - The workflow question
+
+> "Walk me through how a developer on your team takes a Jira ticket and ends up with merged code, when they use AI in the loop. Name the tools, the prompt patterns, and the human review gates. Use a real ticket your team closed last week."
+
+A team that cannot describe its workflow does not have one. The agencies that direct AI well have a written one-page playbook: ticket, draft prompt, generate, run the failing test the developer wrote first, review the diff against the spec, open the PR with an `Assisted-by:` footer, second senior reviews, merge. They will offer to email the playbook the same afternoon.
+
+The agencies running theatre answer in slogans. The Q3 2026 founder above never saw a real PR; the senior engineer who could not produce one was not lying about AI - he was describing a workflow that did not exist. A team that cannot show one PR is the team whose senior is improvising in front of the model on every ticket. That is the team whose 200-line PRs end up in your repo unreviewed.
+
+### Q2 - The cost question
+
+> "What does the average developer on your team spend on AI tokens per month, and who pays it? Will it pass through to my invoice, and what should I budget for the project we just scoped?"
+
+AI tokens are a real budget line in 2026. A Cursor Pro seat is roughly $20-$40, and the Anthropic plus OpenAI API spend on top runs $80-$300 per developer per month for a team that is actually using Claude Code or Aider on big diffs.
+
+The shops that have priced this will give you a per-developer dollar range, a sample invoice line, and a written pass-through clause in the SOW. The shops that have not will say "it is included in the rate" and then send you a five-figure surprise in month two.
+
+The [agency-ai-five-questions script](/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/) opens with a $4,800 monthly OpenAI bill nobody could attribute to a client - that founder caught it because the agency screenshared the wrong tab. You will not have that luck. Get the number in writing on the discovery call.
+
+### Q3 - The verification question
+
+> "When AI generates a 200-line PR, what does your senior reviewer actually check? Walk me through one PR you reviewed last week and tell me what you looked for."
+
+The senior should pull up an actual PR on screenshare. They should read it line by line and explain what they verified: did the diff match the ticket spec, are there hardcoded secrets or API keys in the diff, are the tests genuine (written first as failing specs by the developer) or AI-generated to make CI green, did the AI introduce new gems or pip packages and do those packages actually exist on Rubygems / PyPI / npm.
+
+A reviewer who answers "we trust the model" or "Cursor catches most issues" is the reviewer whose name is going to end up next to the SQL injection vector in your incident postmortem. Linus Torvalds put the ["Assisted-by:" footer](https://lore.kernel.org/lkml/CAHk-=wjbiaa7m9aGtw2T-fbmuuiq_-noqfrjEJzbpCSk0FrFkw@mail.gmail.com/) on the kernel commit list precisely because the named human is the accountability mechanism.
+
+Ask which human's name shows up on the agency's `Assisted-by:` lines this week. If the answer is "we have not started doing that yet," you have your Q3 score.
+
+### Q4 - The slopsquatting question
+
+> "In April 2025 a security researcher published findings that AI assistants suggested over 200 package names across Rubygems, PyPI, and npm that did not exist. Attackers register those names and wait for developers to install the typo. How do you prevent installing a hallucinated package?"
+
+A passing answer names a specific defense: a pre-vetted package allowlist with a written process for adding new dependencies, a scanner like [Socket](https://socket.dev/) or [Snyk](https://snyk.io/) on every PR that blocks the build until a human approves any new package, or a manual `gem info ` / `pip show ` / `npm view ` step before any new dependency lands.
+
+They use the word "slopsquatting" without you prompting and can cite the [Bleeping Computer writeup](https://www.bleepingcomputer.com/news/security/ai-code-suggestions-sabotage-software-supply-chain/) or the [SecurityWeek piece on AI coding agents and supply-chain risk](https://www.securityweek.com/ai-coding-agents-could-fuel-next-supply-chain-crisis/).
+
+An agency that has not heard of slopsquatting in late 2026 has not read its field's security press for over a year. The supply-chain attack moved from CVE bulletins to mainstream founder-facing risk the moment Cursor adoption crossed half the developer market.
+
+### Q5 - The accountability question
+
+> "When AI-generated code causes a production incident, who is on the hook? Walk me through the last AI-generated-code incident your team had - what happened, when, and what you changed afterwards."
+
+A specific incident with a date in the last six months. A one-paragraph root cause. The named senior who reviewed the offending PR. The workflow change made the week after. The agencies that have shipped AI code in production have written at least one of these postmortems already.
+
+The agencies that have not will say "we have never had an AI-related incident" - which means either they have never shipped AI code to production or they are not telling you about the ones that landed. A production database wipe was a 9-second incident on a live SaaS that the founder did not see coming because the agency had no team-level review on AI-generated migrations. Ask. If they cannot tell you, they have not built the muscle.
+
+## Score in real time and walk if below 3
+
+Open a Notion doc before the call. Down the left, write Q1 through Q5; down the right, write 0 or 1 per answer. Score as the senior speaks, not after. The full Pass/Fail texture sits in the [5-Question Script](/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/) - print that and lay it next to your laptop.
+
+### Pass (5 / 5): sign with confidence
+
+The agency directs AI. Ask for three references on AI-augmented projects and the line item on their last invoice that shows the OpenAI pass-through. Expect a written AI policy in your inbox the same day.
+
+### Conditional (3-4 / 5): senior follow-up before SOW
+
+Partial coverage. Ask for a 45-minute follow-up technical session with the senior reviewer (not the salesperson), working through one of your real product flows, before any SOW conversation. If the senior cannot block the time, treat it as a walk.
+
+### Walk (below 3 / 5): polite no by end of day
+
+The agency runs AI theatre. Send a "we are pausing the search to refine our requirements" email before the close of business. Do not negotiate. The agency will argue the framing instead of fixing the four gaps you found.
+
+### What "theatre" vs. "direction" sound like in the room
+
+Same five questions, two completely different conversations:
+
+| # | AI Theatre (walk away) | AI Direction (sign with confidence) |
+|---|---|---|
+| Q1 | "Our developers use AI where it makes sense. We are AI-native." | "Cursor + Claude 4.5 Sonnet. Here is PR #1247 from Tuesday." |
+| Q2 | "It's all included in the rate. Don't worry about token costs." | "$140-$220 per dev per month. SOW pass-through. Sample invoice line below." |
+| Q3 | "We trust the model. Cursor catches the obvious stuff." | "Marcus reviewed PR #1247 - flagged a hardcoded API key." |
+| Q4 | "Our developers know what packages to use." [confused look] | "Socket on every PR. Allowlist in `Gemfile.policy`. Yes, slopsquatting." |
+| Q5 | "We've never had an AI-related incident. Our standards are high." | "March 14: AI-generated webhook retried 8x. Added idempotency key." |
+| Score | 0 / 5 - polite no the same evening | 5 / 5 - ask for AI-project references next |
+
+## The interrogation flow on a 30-minute call
+
+Run the call on a 30-minute Zoom block. Hold the timer.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    A["0-3 min
Set the frame
(you sent the questions
24h ago; senior present?)"]
+    A --> B["3-23 min
Walk Q1 - Q5
(~4 min each)
Score 0/1 in Notion live"]
+    B --> C{"Score after Q5"}
+    C -->|"5 / 5"| D["Ask for 3 AI-project references
+ sample invoice line item
(book follow-up)"]
+    C -->|"3 - 4"| E["Ask for 45-min senior session
on a real product flow
(no SOW yet)"]
+    C -->|"< 3"| F["Polite no by end of day
'Pausing to refine
requirements'"]
+    classDef intro fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a
+    classDef body fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a
+    classDef pass fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef fail fill:#fce4ec,stroke:#c2185b,stroke-width:2.5px,color:#1a1a1a
+    class A intro
+    class B,C body
+    class D,E pass
+    class F fail
+```
+
+The salesperson who keeps trying to take Q1 through Q5 from the senior is itself a Q0 fail. You wrote in the meeting invite that the senior would be on the call. If the senior is not on the call, the answer to every question is whatever the salesperson can fabricate in real time. End the call early. The agency that respects your time will reschedule with the senior; the agency that does not will keep stalling.
+
+## What to do tomorrow
+
+Three concrete moves for the next 24 hours, in order.
+
+1. Block 90 minutes on your calendar for the next agency discovery call you have scheduled. Sixty minutes is for the call; the extra 30 is for the post-call score-up and the polite-no email if the score lands below 3. If you do not have a discovery call scheduled, send the screening email from the [5-Question Script](/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/) to the three agencies on your shortlist today.
+2. Forward your scored Notion doc to your independent advisor or fractional CTO the same evening for a 15-minute paid sanity-check call. Under $400 and the cheapest decision insurance you will buy this year. The [Fractional CTO section](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge) explains how to find and hire one if you do not have one already.
+3. Download the ["We Use AI" 5-Question Script](/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/) and send it to your next agency call as the agenda for the meeting. One sentence in the email body: "We will work through these together on Tuesday; please come prepared." Do not soften it. The agencies that decline to prepare are telling you the answer to the interview before it starts.
+
+## Further reading
+
+- Veracode, [GenAI Code Security Report 2025](https://www.veracode.com/genai-security-report-2025) - 45% of LLM-generated code shipped at least one exploitable security flaw. The data behind Q3 (verification) and Q5 (accountability).
+- Stack Overflow, [2025 Developer Survey - AI section](https://survey.stackoverflow.co/2025/) - 84% of developers now use or plan to use AI tools. The market context behind why "we use AI" became a meaningless homepage line.
+- Bleeping Computer, [AI code suggestions sabotage software supply chain](https://www.bleepingcomputer.com/news/security/ai-code-suggestions-sabotage-software-supply-chain/) - the slopsquatting attack vector in plain English. The thing your agency must spot in PR review (Q4).
+- SecurityWeek, [AI Coding Agents Could Fuel Next Supply Chain Crisis](https://www.securityweek.com/ai-coding-agents-could-fuel-next-supply-chain-crisis/) - the practitioner read on why hallucinated package names are now the leading AI-era attack surface.
+- Linus Torvalds, ["Assisted-by:" tag on Linux kernel commits](https://lore.kernel.org/lkml/CAHk-=wjbiaa7m9aGtw2T-fbmuuiq_-noqfrjEJzbpCSk0FrFkw@mail.gmail.com/) - the kernel rule that puts a human reviewer's name in the commit log when AI is in the loop. The accountability standard referenced in Q3 and Q5.
+- Anthropic, [Claude Code documentation](https://docs.claude.com/en/docs/claude-code/overview) - the official reference for one of the tools your agency should be naming in Q1. Worth skimming so you recognise the workflow language when they describe it.
+- DHH, [The One-Person Framework](https://world.hey.com/dhh/the-one-person-framework-711e6318) - the Rails case for keeping the architecture small enough that one engineer can review every diff, including the AI-generated ones. The framework filter to apply before the agency search.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/cover.png b/content/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/cover.png
new file mode 100644
index 000000000..e98d063f7
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/index.md b/content/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/index.md
new file mode 100644
index 000000000..4badf81d7
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/index.md
@@ -0,0 +1,271 @@
+---
+title: "2.2 · Sharpen Your Question List with AI Personas"
+aliases: ["/blog/ai-persona-pre-validation-mom-test-prep/"]
+description: "Chapter 2.2 of the From Idea to First Paying Customer course. A 90-minute companion pass: use Claude personas to sharpen the Mom Test question list you drafted in Ch 2.1 before booking real interviews."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: ai-persona-pre-validation-mom-test-prep
+keywords:
+  - ai persona mom test
+  - claude personas customer research
+  - rehearse interview questions
+  - non technical founder ai validation
+  - ai augmented customer discovery
+tags:
+  - founders
+  - non-technical-founder
+  - module-2
+  - validation
+  - ai-augmented
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "2.2 · Sharpen Your Question List with AI Personas"
+  og_description: "Chapter 2.2 of the From Idea to First Paying Customer course. A 90-minute companion pass: use Claude personas to sharpen the Mom Test question list you drafted in Ch 2.1 before booking real interviews."
+cover_image_alt: "JetThoughts cover for Chapter 2.2 - Claude persona rehearsing Mom Test questions to flag hypothetical-shaped traps before real interviews"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/"
+related_posts: false
+---
+
+> **Module 2 · Step 2 of 4** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** your draft Mom Test question list (5-8 questions from Ch 2.1) + 3 ICP characteristics (ICP = Ideal Customer Profile - the specific kind of person your hypothesis names, introduced in Ch 1.1)
+>
+> **Output:** a sharpened question list (5-7 solid questions) + top 3 objections, ready to take into Ch 2.3 (a + b) recruitment and real interviews
+>
+> **Cost:** $0 (free tier on Claude or ChatGPT)
+
+> **Skip this if you've interviewed before.** If you've run customer interviews in the past and your questions produced concrete past-tense answers, go straight to [Ch 2.3a: Find 10 People](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/). This chapter catches broken question shapes before they waste real interview slots - useful for first-timers, unnecessary if you've already calibrated your question technique.
+
+> **TL;DR:** A 90-minute AI rehearsal catches broken questions before you spend real interview slots on them. Claude personas expose hypothetical phrasing that generates polite yeses from anyone.
+
+> **Already using Perplexity Pro / Claude / ChatGPT Deep Research for Module 1?** The same tools work here for objection rehearsal - swap the deep-research prompts for the in-character persona prompts below; the cost line is already paid.
+
+You drafted 5-8 Mom Test questions in Ch 2.1. Before you spend a real interview slot on a question that turns out to be pitch-shaped, run the question list past a Claude persona that matches your ICP. The persona answers in character; you ask Claude (out of character) which question generated which kind of answer and why.
+
+The failure shape the rehearsal catches: a question like "Would you use a tool like this?" reads fine on paper, generates a polite "sounds great" from any persona, and absorbs five real interview slots before you notice the pattern. The rehearsal flags the question shape before you spend the slot. Same applies to questions that smuggle in your solution, ask for a hypothetical purchase, or bury the past-tense ask under three clauses.
+
+The pattern: rehearsal tells you whether the question is broken; real interviews tell you whether the hypothesis is right. Catching a broken question with a free Claude session is cheaper than catching it on call 5 of 10.
+
+Real interview slots are scarce. You only get about 10 a round, every one took outreach to book, and a hypothetical question burns the slot - the interviewee says "sure, I'd use it" to be kind, you hang up thinking you got a signal, and you got nothing usable.
+
+An AI rehearsal costs nothing. A short pass through Claude before you pick up the phone, and you find out which questions collapse the moment a real human deflects them.
+
+Real interviews stay irreplaceable for the things rehearsal cannot simulate: the noncommittal shrug on question three, the mention of a workaround you never imagined, the silence after Q4 that tells you more than ten polite yeses. The rehearsal sharpens your questions before you spend a real customer's hour on them.
+
+This chapter is the companion polish step between Ch 2.1 (where you learned the Mom Test technique and drafted 5-8 rough questions) and Ch 2.3 (a + b) (where you recruit 10 real interviewees). You don't validate anything here - the real interviews do that. You catch the broken question shapes before they reach a real human - one focused rehearsal session saves 5 wasted interview slots. Here's the rehearsal flow at a glance:
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    Start(["Your draft Mom Test questions
+ 3 ICP characteristics"])
+    P1["Prompts 1-2: Build 3 ICP personas,
test each draft question in-character"]
+    P2["Prompt 3: Get Claude's
out-of-character diagnosis"]
+    P3["Prompts 4-5: Surface 3 likely objections,
sharpen weak questions (past-anchored)"]
+    Done(["5-7 sharpened questions
+ Objection Tracker → real interviews"])
+
+    Start --> P1
+    P1 --> P2
+    P2 --> P3
+    P3 --> Done
+```
+
+## Why rehearse with AI at all
+
+| What AI Personas Can Do | What Only Real Interviews Do |
+|---|---|
+| Show where your questions break before you spend a real slot | Deliver the hesitation, the pause, the "actually, our ops manager..." referral |
+| Flag hypothetical questions like "Do you find this frustrating?" that generate polite yes-mode from anyone | Reveal the emergency workaround someone duct-taped together last Thursday |
+| Reveal vague or confused persona responses that would collapse under real pressure | Surface unexpected competitors, blockers, or stakeholders you never imagined |
+| Prevent the most avoidable failure mode: burning interview slots on broken questions | Tell you when your ICP definition is wrong (real customers can, persona cannot) |
+
+Think of it as a trial attorney prepping cross-examination with a paralegal standing in as the witness. The paralegal can't give testimony, but the rehearsal finds the question that falls apart under any pressure at all.
+
+## Build 3 ICP personas in Claude
+
+You don't need a sophisticated prompt setup. You need to describe the person you're trying to interview in terms Claude can work with, and then ask Claude to stay in character while you practice questions.
+
+Here's the persona setup prompt. The placeholder mapping table below tells you where each `[BRACKETED]` value comes from in your existing artifacts - read it AFTER you scan the prompt, not before.
+
+### Prompt 1 - Persona Setup
+
+```text
+You are [PERSONA NAME], a [ROLE] at a [COMPANY SIZE] company in [INDUSTRY].
+
+Your situation:
+- You deal with [PROBLEM DESCRIPTION] about [FREQUENCY].
+- You currently handle it by [CURRENT WORKAROUND].
+- You've been doing this for [DURATION].
+- Your budget authority for tools in this category is [BUDGET RANGE].
+- You're skeptical of new software because [REASON - e.g. "the last three tools we bought sat unused"].
+
+Stay in character for this entire conversation. Do not break character to explain your reasoning. Answer as [PERSONA NAME] would, not as an AI. If a question is vague, give the kind of vague polite answer a busy professional gives when they're not sure what you're asking.
+```
+
+
+**Placeholder mapping - where each value comes from:**
+
+| Placeholder | Where it lives in your artifacts |
+|---|---|
+| `[ROLE]` | Founding Hypothesis `[customer]` blank (Ch 1.1) - e.g. "solo chiropractor managing insurance claims" |
+| `[INDUSTRY]` + `[COMPANY SIZE]` | The three ICP characteristics you wrote in Ch 1.1 Step 1 |
+| `[PROBLEM DESCRIPTION]` | Founding Hypothesis `[problem]` blank (Ch 1.1) |
+| `[PROBLEM AREA]` | The `[problem]` blank summarized in 2-3 words (e.g. "claim resubmission backlog") |
+| `[CURRENT WORKAROUND]` | Founding Hypothesis `[competition]` blank (what they do today) |
+| `[YOUR DRAFT QUESTION 1]`, `2`, `3`, ... | Pick one question at a time from your Ch 2.1 `Mom Test draft - [date]` doc (5-8 question list) |
+| `[QUESTION X]` (in Prompt 5) | Whichever question you want to sharpen from your draft list |
+| `[PERSONA NAME]`, `[FREQUENCY]`, `[DURATION]`, `[BUDGET RANGE]`, `[REASON]` | Your judgment, anchored to deep-research findings if you ran the Ch 1.1 sidebar - see fallback below |
+
+> **Fallback for the 3 fields not in your hypothesis (`[FREQUENCY]`, `[DURATION]`, `[REASON]`):** make your best informed guess. The rehearsal is calibrated; the persona doesn't have to be perfect. After your first real Ch 2.3 (a + b) interview, you will know whether your guess was too mild ("monthly" when reality is "daily") or too aggressive. Revise BETWEEN interview 1 and interview 2. If any placeholder above is empty, the Ch 1.1 hypothesis is not specific enough - tighten it before rehearsing.
+
+> **Heads up:** Claude is trained to be helpful, which means it tends to give reasonable answers even to broken questions. Don't read a coherent persona answer as proof the question works. Read Claude's out-of-character diagnosis instead - the in-character answer reflects what Claude thinks a polite persona would say; the out-of-character note reflects what the question is actually asking.
+
+Build 3 distinct personas before you start - not 3 variations of the same person. If your ICP is "ops managers at B2B SaaS companies," your three personas might be: one at a 10-person seed startup (different budget, different urgency), one at a 60-person Series A (different process maturity), and one at a 200-person growth-stage company (different buying committee).
+
+Each persona has different objections, different workarounds, and different reasons to care. A question that works cleanly on one persona will collapse on another - and that collapse tells you something before you spend real calendar slots finding out.
+
+## Run the rehearsal session
+
+Once the persona is set, run your draft questions. Here's the sequence.
+
+### Prompt 2 - Opening question test
+
+```text
+I'm going to ask you a question about [PROBLEM AREA]. Answer as [PERSONA NAME] would if a stranger asked you this at a conference. Question: "[YOUR DRAFT QUESTION 1]"
+```
+
+After each answer, ask this diagnostic.
+
+### Prompt 3 - Question diagnosis
+
+```text
+Now break character for 30 seconds. As an AI assessing that question: Was that a question that would produce useful data in a real customer interview? What would a real busy [ROLE] do with that question that I wouldn't predict from your answer? What's the version of that question that would make you open a real memory instead of giving a general response?
+```
+
+Repeat for each question. The in-character answer is plausible by default; the out-of-character diagnosis is where you learn whether the question would actually produce useful data on a real call.
+
+### Prompt 4 - Objection surface
+
+```text
+Back in character as [PERSONA NAME]: What would make you want to end this conversation early? What question would feel like a pitch in disguise? What would make you worry I'm about to sell you something?
+```
+
+This prompt surfaces the three objections you need to test (not discover) in real interviews. An interviewee who feels sold to shuts down. If your question list has any question that a persona reads as a pitch, it will also read as a pitch to a real human - and real humans stop giving real answers the moment they sense a sales agenda.
+
+### Prompt 5 - Sharpening
+
+```text
+Rewrite [QUESTION X] so that it anchors in a specific past event rather than a hypothetical. Keep it under 20 words. Give me three versions.
+```
+
+Use this on every question that produced a vague answer in Prompt 2. Concrete past-anchored questions are the whole point of [the Mom Test](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/). If you can't make the question past-anchored in 20 words, the question isn't ready.
+
+---
+
+Run all three personas against the same question list before you judge any single question. A question that holds up across all three is probably solid. A question that collapses on persona 2 but not persona 3 tells you something about the ICP segment, not just the question.
+
+## What to keep, what to throw out
+
+After the rehearsal, you'll have a mix of responses. Use these three signals to sort:
+
+| Decision | Condition |
+|----------|-----------|
+| **Keep it** | Persona gave a specific, concrete answer without being pushed; Claude's out-of-character diagnosis called it "useful"; all three personas answered with different concrete stories, not just different adjectives |
+| **Revise it** | Persona answered in generalities; the sharpening prompt (Prompt 5) produced a clearly better version in under 60 seconds |
+| **Cut it** | Prompt 4 flagged it as a pitch in disguise; or three sharpening attempts couldn't make it past-anchored |
+
+Judgment is still yours. The diagnostic only tells you which questions are obviously broken before you find out the expensive way. A question with a plausible in-character answer but a "this is hypothetical" out-of-character flag still gets cut - a coherent answer to a hypothetical question tells you nothing about real customer behavior.
+
+## What changed in your real interview slate
+
+After the rehearsal, you have two deliverables.
+
+**The sharpened question list.** Take your original questions, apply the revisions from Prompt 5, cut the ones flagged in Prompt 4. You should end the session with 5-7 solid questions where you started with 8-12 loose ones. That's the list you take into [booking real interviews with the full outreach stack](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/).
+
+**The top 3 objections to test in real interviews.** Prompt 4 will surface 3-5 things that make your persona want to end the conversation. Pick the 3 that appeared across at least 2 of your 3 personas. These are the objections you're listening for in real interviews - not discovering them for the first time, but noticing whether and how they show up. There's a difference between a real customer who raises objection #2 early (strong signal that the objection is real) and one who never raises it at all (either it's not real for this person, or your questions didn't give them space to surface it).
+
+**Objection Tracker** - fill this in after the rehearsal, before your first real interview:
+
+| Objection | Which personas raised it | What phrasing to listen for | Showed up in real interviews? |
+|-----------|-------------------------|----------------------------|-------------------------------|
+| They'll say budget is controlled by their manager | Personas 1 and 3 | "I'd have to run this by..." | [ ] |
+| 1. | | | |
+| 2. | | | |
+| 3. | | | |
+
+Print it. Put it next to the [Mom Test interview script](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) on your second monitor. After each real interview, tick the column. By interview 5, you'll know which objections are real and which were just AI pattern-matching.
+
+## What to do next
+
+**Cost: $0** (the free tier on Claude or ChatGPT covers a focused rehearsal session; no paid plan required).
+
+| Step | Action | Outcome |
+|---|---|---|
+| **1** | Open Claude or ChatGPT and paste the 5 rehearsal prompts in order. Run through one persona session. | 5-7 sharpened questions, top 3 objections identified |
+| **2** | Run the same prompts against personas 2 and 3. Note every question that got vague or off-topic answers - those are the weak ones. | Question list with all weak questions flagged for rewrite |
+| **3** | Rewrite the weak questions using Prompt 5 (past-anchored, under 20 words). Book the first real interview. | Ready to start real customer interviews with a sharp question list |
+
+**Failure signal:** if all 3 personas produce nearly-identical answers to your questions, your persona descriptions are too generic - rewrite them with sharper role / company-size / urgency differences before continuing. The rehearsal only works when the 3 personas are genuinely different people with different objections.
+
+The two deliverables: a sharpened question list (5-7 solid questions) and an Objection Tracker (top 3 objections to listen for in real interviews).
+
+## Going further
+
+Reuse the rehearsal stack when a round of real interviews ends in partial signal.
+
+| Scenario | What to do | Why |
+|---|---|---|
+| **Real interviews end in partial signal** | Run a new persona session with a revised ICP before booking another 10 slots | Filling the 48 hours between round 1 and round 2 surfaces question gaps |
+| **Hypothesis partially invalidated** (problem is real, but wrong customer named) | Build 3 new personas reflecting the ICP shift, run the same prompt sequence | This still doesn't substitute for more real interviews; it just sharpens them |
+| **Product-direction pivot emerges** (round 1 surfaces a different problem) | Build a persona around the new problem before rebuilding the question list from scratch | Spinning up a persona costs 5 minutes; spinning up another 10 interview slots costs a week |
+| **Considering a customer pivot between validation rounds** | Compare question performance across both the old ICP persona and the new one before committing | Reveals which questions survive the ICP shift and which ones were persona-specific |
+
+One constraint worth naming: the rehearsal only surfaces signal that's already in your mental model of the customer. Claude constructs the persona from what you tell it.
+
+If your ICP description is wrong - the wrong role, the wrong company size, the wrong industry detail - the persona will be wrong in the same direction, and the rehearsal will give you false confidence.
+
+This is the other reason real interviews stay irreplaceable: a real customer can tell you your ICP description is wrong, while Claude can only simulate the ICP you described.
+
+> **Module 2 AI critic/simulator block** - This chapter IS the block.
+>
+> **What AI can help with at this stage:**
+> - Simulate 3 ICP personas answering your draft Mom Test questions in-character
+> - Flag hypothetical questions that generate polite-yes responses from anyone
+> - Surface the top 3 objections to listen for in real interviews
+> - Sharpen vague questions into past-anchored versions under 20 words
+>
+> **What AI cannot prove or substitute:**
+> - Whether your ICP description is accurate (only a real interviewee can correct you)
+> - What a real customer will actually say (Claude simulates the persona YOU describe)
+> - Whether the problem is real (only 10 Mom Test interviews can falsify the hypothesis)
+>
+> **The real gate:** 10 Mom Test interviews with real humans, ≥7/10 strong signal (Ch 2.1 technique + Ch 2.3 (a + b) recruitment).
+
+> **Advanced: AI ensemble stress-test (after your interviews).** Once your 10 Mom Test interviews are done and you have a refined hypothesis, you can cross-validate the business logic using multiple AI models simultaneously. Paste your validated problem statement into [IdeaProof](https://ideaproof.io) (70 free credits, no credit card) - it runs your hypothesis through 4 different models (Claude 4, GPT-4.1, Gemini 3, Grok 4.1) and flags contradictions between them. A claim that passes one model but fails another is a blind spot worth investigating before you build. The ensemble approach catches what a single-model rehearsal misses: each model has different training biases, and consensus across four is stronger signal than one model saying "sounds good." This is not a substitute for the Mom Test interviews - it validates the logic AFTER the interviews validated the problem. Think of it as the final sanity check before you commit to building.
+
+The rehearsal does not validate the hypothesis. It validates that your questions are ready to validate the hypothesis. Skip it and you burn real interview slots on questions that fail in minute one.
+
+## Further reading
+
+- Rob Fitzpatrick, [The Mom Test (book site)](https://www.momtestbook.com/) - the canonical reference for past-anchored interview questions.
+- Y Combinator, [How to Talk to Users](https://www.ycombinator.com/library/6g-how-to-talk-to-users) - YC's short essay on why this conversation has to happen.
+- Anthropic, [Claude prompting guide](https://docs.anthropic.com/claude/docs/intro-to-prompting) - persona setup, role-play, and breaking character cleanly.
+
+> **Done when:** You have a sharpened question list (5-7 solid questions) and an Objection Tracker with the top 3 objections to listen for.
+>
+> **Next click:** [2.3a · Find 10 People: Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) - build the 30-name list first, then [2.3b · What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) sends the messages.
+>
+> **If blocked:** If all 3 personas produced identical answers, your persona descriptions are too generic. Rewrite them with sharper role, company-size, and urgency differences before continuing.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Runs his draft questions through a Claude persona - a skeptical controller who's been pitched 3 automation tools and rejected all of them. Persona flags 2 leading questions. Sharpens them to anchor in specific past reconciliation events.
+>
+> **Mia**: Runs her draft questions through a Claude persona - a parent of a 10-year-old with ADHD burned by a tutoring app before. Persona flags 1 question that assumes the parent has time to search. Adds: "What happened the last time you tried to book a tutor during a workday?"
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/cover.png b/content/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/cover.png
new file mode 100644
index 000000000..03578ed22
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/index.md b/content/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/index.md
new file mode 100644
index 000000000..cafb80e2d
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/index.md
@@ -0,0 +1,188 @@
+---
+title: "The AI Token Bill Your Agency Forgot"
+aliases: ["/blog/ai-token-bill-dev-shop-pass-through-cost/"]
+description: "The pass-through OpenAI, Anthropic, and Cursor costs that creep into month-2 invoices. Predictable per-developer ranges plus 3 SOW clauses to redline now."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: ai-token-bill-dev-shop-pass-through-cost
+keywords:
+  - ai token bill agency pass through
+  - cursor anthropic openai cost developer
+  - sow ai cost clause founder
+  - ai pass through invoice itemization
+  - dev shop ai cost ranges 2026
+tags:
+  - founders
+  - non-technical-founder
+  - course-companion
+  - ai-era
+  - cost-management
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "The AI Token Bill Your Agency Forgot to Mention"
+  og_description: "Pass-through Cursor, Anthropic, and OpenAI costs creep into month-2 invoices. Get predictable per-developer ranges plus 3 SOW clauses to redline now."
+cover_image_alt: "JetThoughts course cover showing a stacked AI cost layer cake: Cursor seat, Anthropic API, OpenAI API, totaling per developer per month"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/"
+related_posts: false
+course_nav: false
+---
+
+> **Going further (AI in production) · Step 2 of 3** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a signed agency contract OR a hire who claims "AI-augmented."
+>
+> **Output:** monthly AI cost predicted within ±20% + 3 contract clauses you add to the next SOW
+
+**Supplementary content.** This chapter is relevant after you've shipped (Module 4+) and your product touches AI in production. Bookmark and return when needed.
+
+A founder posted in r/SaaS last month: **"Our dev shop just sent the month-2 invoice. There's a $1,860 line called 'AI Services - passthrough.' We never agreed to this. The contract is for $14K/month flat. What is going on?"** The replies told her what the line was. None of them told her how to predict it for month 3.
+
+That is the gap this post closes. By the end of one coffee you will know the per-developer AI cost ranges that should be in your invoice, the formula that predicts your bill within ±20%, and the 3 clauses you paste into your next SOW so the surprise never happens again.
+
+**What one developer costs you in AI tokens per month (2026 pass-through ranges, above the hourly rate):**
+
+| Line item | Per dev / month | What you control |
+|-----------|-----------------|------------------|
+| Cursor or Copilot Enterprise seat | $20-60 | Fixed monthly. Easy to predict. Pick a tier and stay |
+| Anthropic API (Claude Code) | $30-200 | Usage discipline. Same dev = 7x range depending on agent-loop habits |
+| OpenAI API (gpt-4o, o3) | $50-300 | Whether the team uses it at all. Less common in 2026 if Claude Code dominates |
+| **Disciplined team total** | **$80-$120** | Cursor + Claude Code + budget alerts at $150 |
+| **Undisciplined team total** | **$300-$500** | 5 AI tools, no budget alerts, agent loops left running |
+
+Multiply by your team size. A 4-dev team at the undisciplined end is $1,200-$2,000/month before margin.
+
+> **Read this if**: you've hired an agency in 2026 OR your dev shop is starting to mention "AI tooling" line items in invoices.
+
+## Why this hits in month 2-3
+
+Month 1 your invoice arrives clean. The agency is still negotiating, the team is staffing up, and AI usage is light because the developers are reading your codebase, not generating against it. Month 2 production starts. By month 3 the team is shipping daily, and one or two developers fall in love with Claude Code agent loops that run for 40 minutes against a hard ticket. The invoice arrives with a new line: "AI Services," "Tooling pass-through," or "Engineering AI." There is no breakdown. The number is between $800 and $4,000. The agency owner says "yeah we use AI now, it's industry standard." You sign it because the alternative is fighting about it for two weeks while the project stalls.
+
+That conversation is preventable in 20 minutes of contract reading and 10 minutes of math. The next 1,200 words show you how.
+
+## The 2026 cost ranges
+
+Three line items make up almost every dev shop's AI bill in 2026. Memorize the ranges and you can spot a wrong invoice in 30 seconds.
+
+### Per-developer Cursor (or Copilot Enterprise) seat: $20-$60/mo
+
+Cursor Pro is $20/month per seat ([Cursor pricing](https://cursor.com/pricing)). Cursor Business is $40/seat with admin controls and usage analytics. Cursor Ultra is $200/seat for heavy users. GitHub Copilot Enterprise sits at $39/seat ([GitHub Copilot pricing](https://github.com/features/copilot/plans)). Most agencies pick one - Cursor Business is the modal choice in 2026 because it bundles team admin and gives the agency owner a usage dashboard. This line is fixed and predictable. It should never surprise you.
+
+### Per-developer Anthropic API spend: $30-$200/mo
+
+This is where the variance starts. Claude Code (the terminal agent) uses the Anthropic API directly. A disciplined developer running 30-60 short prompts a day on Claude Sonnet 4.5 spends $30-80/month. A developer who fires off 5-minute agent loops on hard tickets - the kind where Claude reads 12 files and writes 400 lines of diff - can hit $150-200/month without trying. Sonnet 4.5 input is **$3 per million tokens**, output is **$15 per million tokens** ([Anthropic API pricing](https://www.anthropic.com/pricing)). One agent loop on a complex ticket can burn 200K-400K tokens in an afternoon.
+
+### Per-developer OpenAI API spend: $50-$300/mo
+
+Less common in 2026 since Claude Code dominates the agent-loop workflow, but teams that run Codex, gpt-4o for image-heavy tasks, or o3 for "deep thinking" tickets still see this. gpt-4o input is **$2.50 per million tokens**, output is **$10 per million** ([OpenAI API pricing](https://openai.com/api/pricing/)). o3 is dramatically more expensive on output tokens. Some agencies route a fraction of work to GPT for variety; others do not touch OpenAI at all. Ask which during the discovery call.
+
+### Total per developer: $80-$500/mo above the hourly rate
+
+The disciplined-team end of the range is **$80-$120/dev/month**: Cursor Business seat ($40), Claude Code with budget alerts ($60-80), no OpenAI. The undisciplined end is **$300-$500/dev/month**: 5 AI tools concurrent, no per-developer budget caps, agent loops left running on lunch break. Most dev shops in 2026 sit at the disciplined end if they are profitable, the undisciplined end if they are still figuring out their AI workflow.
+
+## The math: predict your bill
+
+Take your invoice in three numbers.
+
+**Formula:**
+
+> Monthly AI bill = (number of developers on your project) × (avg per-dev AI cost) × (1 + agency margin %)
+
+**Worked example - 4-dev disciplined team:**
+
+- Developers on project: 4
+- Avg per-dev AI cost: $100/month (disciplined: Cursor seat + Claude Code with budget alerts)
+- Agency margin: 0% (per Clause 1 in the SOW)
+- Expected monthly AI line: **$400 ± 20% = $320 to $480**
+- If invoice shows $1,800: undisciplined developer (Devon in the table above), 30% hidden margin, or both - 15-minute conversation either way
+
+**Worked example - 2-dev team with one heavy agent-loop user:**
+
+- Developers on project: 2
+- Avg per-dev AI cost: $200/month (mid-range: one runs heavy agent loops on hard tickets)
+- Agency margin: 0%
+- Expected monthly AI line: **$400 ± 20% = $320 to $480**
+- Same total as the 4-dev team, very different reasoning - which is why per-dev breakdown matters more than the total
+
+The trade-off you are accepting: ±20% is a wide band. AI usage is genuinely variable - a sprint full of refactoring tickets burns 2-3x more tokens than a sprint full of UI work. The point of the formula is not pinpoint accuracy; it is catching the 200%-over-estimate invoices that show up when nobody is watching.
+
+## The 3 contract clauses to add
+
+Paste these into your next SOW under "Pricing and Pass-Through Costs." If the agency redlines all three, that tells you something. If they accept all three with a shrug, that also tells you something useful.
+
+```mermaid
+flowchart TD
+    A[Sign SOW with the 3 clauses] --> B[Predict bill: devs x avg x margin]
+    B --> C{Month-2 invoice arrives}
+    C -->|Within +/-20%| D[Pay it. Mark as baseline]
+    C -->|>20% over| E[Itemized breakdown required]
+    E --> F{Itemization explains it?}
+    F -->|Yes - Devon hit a hard ticket| G[Update budget alert. Continue]
+    F -->|No - margin or padding| H[Push back. Cite Clause 1]
+    D --> I[Quarterly: review dashboards under Clause 3]
+    G --> I
+    H --> I
+    I --> A
+```
+
+### Clause 1 - Pass-through caps
+
+> "AI tooling and API pass-through fees are billable at cost plus 0% margin. Total monthly AI pass-through is capped at $500 per developer per month without prior written approval from Client. Charges above the cap require an itemized written request and Client's signature before invoicing."
+
+What it does: blocks the agency from quietly marking up your AI bill 20-30% (yes, this happens) and gives you a per-dev ceiling that any reasonable team stays under without thinking about it. The "prior written approval" bit forces an email conversation before a $4,200 invoice surprise.
+
+### Clause 2 - Itemization
+
+> "Each monthly invoice itemizes AI tooling pass-through separately by developer and by tool (Cursor seat, Anthropic API, OpenAI API, other). The itemization shows tokens consumed per tool per developer for the period."
+
+What it does: makes the "AI Services - $1,860" line illegal. Instead you get the right-hand invoice in the graphic below. With per-dev itemization, when month-3 spikes, you know whether it is one developer on one hard ticket (workflow conversation) or a margin slipped in (contract conversation).
+
+**Bad invoice vs good invoice for a 4-developer team in month 2:**
+
+| Line item | Bad invoice (reject) | Good invoice (accept) | Why it matters |
+|-----------|----------------------|------------------------|----------------|
+| AI tooling line | "AI services (passthrough) - $2,340" with no breakdown | Per developer, per tool, tokens shown (Maria $135, Devon $1,095, Priya $175, Alex $150) | When the AI line doubles in month 3, you have something to push back on |
+| Pass-through margin | Not stated (hidden 20-30% markup possible) | "Pass-through margin: 0%" stated on the invoice | Blocks the agency from quietly marking up the AI bill |
+| Budget alert | None | "Budget alert threshold (per dev): $300" | Devon blew past $300 - conversation possible, not surprise invoice |
+| Question you can answer | "Who used what AI tool to do what work?" - no | Yes, per-line | Without it, every month-3 spike is an argument; with it, every spike is a 5-minute conversation |
+
+### Clause 3 - Visibility
+
+> "Client receives read-only access to the Anthropic Console, OpenAI Platform, and Cursor admin billing dashboards for the project workspace, scoped to project usage. Access provisioned within 5 business days of contract execution."
+
+What it does: collapses the information asymmetry. You see the dashboards the agency sees. When Anthropic rolls out a new model that is 40% cheaper on the same workload, you spot it before the agency does. When usage spikes on a Tuesday, you can see which developer and which day without asking. The agency that refuses this clause is telling you they want the asymmetry.
+
+The trade-off: provisioning read-only project access takes 5-30 minutes per platform. An agency with 12 active clients adds an hour or two of admin per month. That is the cost of trust - cheap.
+
+## What to do tomorrow
+
+Three actions. In order.
+
+- **Open your last 3 invoices and find the AI line.** If there isn't one, ask in writing: "What is your team's average AI tooling spend per developer per month, and where is it billed?" If the answer is "we absorb it" or "it's in the rate," ask for a written breakdown of the rate showing the AI carve-out. The breakdown either exists or the agency is improvising; both answers are useful.
+- **Calculate your expected month-3 bill using the formula above.** Write it in a Notion doc with a date. When month 3 arrives, compare. If actual is within ±20% of predicted, the agency is being straight with you. If actual is 50% over, you have a conversation, not an argument, because you have a number to start from.
+- **Open your in-flight SOW redline (or your next one) and paste the 3 clauses under "Pricing."** Send the redline back the same day. The agency that returns the SOW with all 3 accepted is telling you they have the workflow already. The agency that accepts 2 of 3 is negotiating in good faith. The agency that strikes all 3 is telling you to walk.
+
+> AI tooling is not magic - it is a metered utility. Every agency in 2026 should be able to tell you per-developer Cursor seat plus Anthropic API plus OpenAI API to two significant figures. The ones that cannot are billing you for their own learning curve.
+
+## Further reading
+
+- [Anthropic API pricing](https://www.anthropic.com/pricing) - the canonical Sonnet, Opus, and Haiku per-million-token rates. Read the input vs output split; it is where most invoice surprises live.
+- [OpenAI API pricing](https://openai.com/api/pricing/) - the gpt-4o, o3, and o1 per-token rates. Note the cached input rates if your team uses prompt caching aggressively.
+- [Cursor pricing](https://cursor.com/pricing) - Pro, Business, and Ultra tiers. Business is the modal agency choice in 2026.
+- [GitHub Copilot pricing](https://github.com/features/copilot/plans) - Individual, Business, Enterprise. The fallback for teams that have not switched to Claude Code.
+- The Pragmatic Engineer, [The state of AI coding tools in 2025](https://newsletter.pragmaticengineer.com/p/state-ai-coding-tools-2025) - per-developer spend ranges from a survey of senior engineers, useful for sanity-checking the numbers above.
+- Simon Willison, [Pelican on a bicycle benchmarks](https://simonwillison.net/2024/Oct/25/llm-pricing/) - running cost comparison across models with public token-cost ranges.
+- Latent Space, [The AI engineer's stack 2026](https://www.latent.space/p/ai-engineer-stack) - which model and tool combinations large engineering orgs settle on, with cost commentary.
+
+Related course posts:
+- ["We Use AI": 5 Follow-Up Questions for Your Agency](/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/) - sister chapter; the 5-question script for AI theatre detection includes the cost question this post expands.
+- [Reading the SOW Clause by Clause](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#reading-the-sow) - hire track contract reading guide; pair with the 3 AI clauses above when redlining your next SOW.
+- [The Quality Tax for AI MVPs](/blog/quality-tax-ai-mvp-cost/) - the rebuild bill that arrives when AI-generated code meets production load nobody planned for.
+- [The Hidden Cost of Poor Vendor Management](/blog/hidden-cost-poor-development-vendor-management-fix/) - the broader pattern: surprise line items follow the contracts you did not read carefully.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/cover.png b/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/cover.png
new file mode 100644
index 000000000..a8dd3ff34
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/index.md b/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/index.md
new file mode 100644
index 000000000..2ed3e8257
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/index.md
@@ -0,0 +1,241 @@
+---
+title: "Build Path Decision Worksheet"
+aliases: ["/blog/build-path-decision-worksheet/"]
+description: "5 questions that route a non-technical founder to one of 4 build paths. 30-minute decision, defensible to investors."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: build-path-decision-worksheet
+keywords:
+  - build path decision worksheet
+  - founder build vs hire worksheet
+  - validate without code template
+  - founder build path 4 quadrant
+  - should I hire engineer worksheet
+tags:
+  - founders
+  - non-technical-founder
+  - template
+  - course-companion
+  - decision-framework
+categories: ["Templates"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/"
+related_posts: false
+---
+
+📋 Template companion to the [Module 4 post](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/). Run after your [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) is signed. Print, fill in 30 minutes, write your chosen path at the top of your Notion doc.
+
+# Build Path Decision Worksheet - 5 Questions, 4 Paths
+
+*Print one side of paper. Pen. 30 minutes alone. Walk out with a defensible build decision and the next module to read.*
+
+## Why this exists
+
+A wellness-coaching founder we picked up in Q1 2026 had spent four months building a Lovable MVP, then panicked and signed a $24K-per-month agency contract because three advisors told her "you need a real team now." Two of the advisors had never seen her validation data. The third had not asked.
+
+She showed us the contract on a Tuesday. By Friday we had walked her through the same 5 questions on this worksheet and the matrix said Path 3 (Fractional CTO at $2,400/mo, 8 hours/week), not Path 4 (the agency at $24K/mo). She paid the agency a kill fee and saved 14 months of runway. The decision was already in the data she had. The advisors had not run the worksheet. Cheaper to spend 30 minutes with this page than to spend a quarter undoing a contract somebody else's instinct signed for you.
+
+## How to use this
+
+Friday afternoon, alone, 30 minutes, before coffee runs out. Bring three documents: your filled-in [Validated Problem Statement](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/) from Chapter 2.1, your filled-in [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) from Chapter 3.1, and a current bank statement showing months of runway. Pen on paper. Phone in another room.
+
+Answer the five questions in order. Each one is factual, not aspirational. "Number of paying pre-orders" is a count from your Stripe dashboard, not a vibe. "Months of runway" is cash on hand divided by monthly burn, not a guess. The matrix at the bottom routes you to Path 1, 2, 3, or 4 based on the five answers.
+
+If you spill past 30 minutes, you are negotiating with yourself. Stop, write the verdict the data supports, take it to one peer or advisor for a 20-minute call, and move on.
+
+Total time budget: 30 minutes alone, 20 minutes with one peer, 0 minutes second-guessing. Tomorrow you start the path the worksheet picked.
+
+## The 5 questions - check the box that matches
+
+```
+=========== BUILD PATH DECISION WORKSHEET ===========
+
+Founder: _________________  Date: ____________________
+
+one-page brief finalized on: ____________________
+
+Months of runway in the bank: ________________________
+```
+
+### Q1: Is the problem validated?
+
+```
+------------------------------------------------------
+Q1. Is the problem validated?
+------------------------------------------------------
+
+Counts as YES only if all 3 below are true:
+ [ ] 10 or more Mom Test interviews complete
+ [ ] Strong past-behavior signal in at least 7 of 10
+ [ ] 2 to 5 pre-orders, paid pilots, or annual deposits
+     on the table (real money, refundable is fine)
+
+LinkedIn likes do not count. "They said they would
+buy" does not count. Money or a procurement-call
+calendar invite counts.
+
+VERDICT: [ ] Yes    [ ] No
+
+If NO -> stop here. Path 1 (Validate without code).
+        Run the Airbnb test this week.
+
+If YES -> go to Q2.
+```
+
+### Q2: How backend-heavy is the build?
+
+```
+------------------------------------------------------
+Q2. How backend-heavy is the build?
+------------------------------------------------------
+
+Check every TRUE row:
+ [ ] Real-time updates (WebSockets, server-sent events)
+ [ ] Background queues with retry logic
+ [ ] AI inference inside the request path,
+     >$0.01 per call
+ [ ] Multi-tenant data with row-level security
+ [ ] 5 or more third-party API integrations
+ [ ] Regulated data (HIPAA, SOC 2, PCI scope)
+
+VERDICT:
+ [ ] 0-1 boxes checked   = LIGHT backend
+ [ ] 2-3 boxes checked   = MID backend
+ [ ] 4 or more checked   = HEAVY backend
+
+If HEAVY -> Path 4 (Hire a team - see [hire-track reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/)).
+            Read the SOW guide before kickoff.
+
+If LIGHT or MID -> go to Q3.
+```
+
+### Q3: What is your runway?
+
+```
+------------------------------------------------------
+Q3. What is your runway?
+------------------------------------------------------
+
+Months of cash until you must show paying customers:
+
+ [ ] Less than 4 months
+ [ ] 4 to 12 months
+ [ ] 12 or more months
+
+If LESS THAN 4 -> Path 1 (Validate without code),
+                  regardless of how validated you
+                  feel. The Airbnb test is the only
+                  experiment that fits in the window.
+
+If 4 TO 12 -> Paths 2, 3 are on the table. Go to Q4.
+
+If 12+ -> Paths 2, 3, 4 are on the table. Go to Q4.
+```
+
+### Q4: What is your monthly engineering budget?
+
+```
+------------------------------------------------------
+Q4. What is your monthly engineering budget?
+------------------------------------------------------
+
+Money you can commit for at least 6 months:
+
+ [ ] $0 to $400/wk of your own time
+ [ ] $1,600 to $4,000/mo (Fractional CTO band)
+ [ ] $5,000 to $30,000/mo (small team band)
+ [ ] $30,000+ /mo (multi-person team band)
+
+If $0-$400 -> Path 2 (Self-serve / Module 4).
+              Paste one-page brief into Lovable.
+
+If $1.6K-$4K -> go to Q5.
+
+If $5K-$30K -> Path 3 (Fractional CTO) until problem
+               complexity demands more.
+
+If $30K+ -> Path 4 (Hire a team - see [hire-track reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/)).
+```
+
+### Q5: Senior engineer in your network for 1 hour of architecture review per month?
+
+```
+------------------------------------------------------
+Q5. Senior engineer in your network for 1 hour
+    of architecture review per month?
+------------------------------------------------------
+
+A real human you can text. Returns calls within 48 hrs.
+Has shipped a backend at scale in the last 5 years.
+
+ [ ] Yes, named: ___________________________________
+ [ ] No
+
+If YES -> Path 2 (Self-serve / Module 4).
+          Use them for the monthly architecture call
+          + worst-route code review.
+
+If NO -> Path 3 (Fractional CTO bridge).
+         Buy the same insurance commercially.
+
+======================================================
+THE 4-PATH VERDICT (write your row at the top of
+your Notion doc)
+======================================================
+```
+
+## The 4-path verdict table
+
+| Path | Choose when | First action this week | Cost |
+|---|---|---|---|
+| **1. Validate without code** | Q1 = No, OR Q3 = less than 4 months | Ship Carrd page + Stripe checkout + Notion FAQ. Send to 35 ICP prospects. | $0 - $300 in tools + optional $100-200 in paid ads |
+| **2. Self-serve build (6A)** | Q1 yes, Q2 light, Q4 = $0-$400/wk, Q5 = senior eng in network | Paste one-page brief into Lovable. Hook Supabase + Stripe + Resend. | $200 - $1,200 / month |
+| **3. Fractional CTO bridge (5.2)** | Q1 yes, Q2 mid, Q4 = $1.6K-$4K/mo OR Q5 = no senior eng | Hire 5-10 hrs/wk Fractional CTO. Use for architecture, PR review, hiring, cost watch. | $1,600 - $4,000 / month |
+| **4. Hire a team (6B)** | Q1 yes, Q2 heavy, Q4 = $5K+/mo | Read draft SOW clause-by-clause. Confirm GitHub/AWS/domain ownership before kickoff. | $30K - $80K / month |
+
+**Failure mode to watch for each path** ->
+- Path 1 -> 0 of 35 click. Pivot the pitch or the problem.
+- Path 2 -> Hits architectural ceiling at ~5K users. Route to 6B for next layer.
+- Path 3 -> CTO drifts into coder. 90-day review on hour allocation.
+- Path 4 -> Spaceship for the wrong moon. Friday demo + Org Chart audit catch it in week 3.
+
+## What good looks like vs what bad looks like
+
+**Q1 - Problem validated**
+
+> Bad: *"I posted on LinkedIn and got 47 likes and 12 comments. People love the idea."*
+
+> Good: *"I ran 12 Mom Test calls (May 2026 sample). 9 of 12 described the exact problem in past-tense with a number attached (hours per week, dollars per month). 3 of 9 said yes to a $200 refundable deposit on the spot. 2 wired the deposit by Friday."*
+
+The good answer is countable: 12 calls, 9 strong signals, 3 yes-on-the-spot, 2 wired money. The bad answer is a vibe metric (likes) and a hypothetical (love the idea). Likes do not pay invoices. The matrix routes the bad answer to Path 1 regardless of how confident the founder feels, because the data is not there.
+
+**Q4 - Monthly engineering budget**
+
+> Bad: *"We have $400K in the bank and we will spend whatever it takes to ship."*
+
+> Good: *"$420K in the bank. Burn is $28K/month (founder salary + tools + ads). 15 months of runway. I can commit $4K/month to engineering for the next 6 months without dipping into the marketing budget I need to test the channel."*
+
+The good answer ties budget to runway and to the marketing test that proves the channel. Bad answer commits the bank without a denominator. The matrix routes the bad answer to Path 4 (hire a team) on the founder's confidence, which is the path that runs them out of money. The good answer routes to Path 3 (Fractional CTO at $4K/mo) which fits inside 15 months of runway with the marketing budget intact.
+
+**Q5 - Senior engineer in your network**
+
+> Bad: *"Yes, my college roommate is a software engineer at Google."*
+
+> Good: *"Yes - Maya Chen, ex-Stripe payments backend, currently fractional. Returns texts within a few hours. She agreed to a 1-hour architecture call on the first Monday of every month at $300/hr. First call booked for Sept 7."*
+
+The good answer names the person, the relevant experience (Stripe payments backend, not Google ads), the cadence (first Monday), the price ($300/hr), and the next call (Sept 7). Bad answer names a person without the cadence or the agreement. "My roommate is an engineer" is not a check-in. The matrix counts only the named, scheduled, paid arrangement.
+
+## What to do after
+
+- **Write your verdict at the top of a fresh Notion doc.** One line: *"Path X (name). Started: [date]. Next module: [6A / 6B / 5.2 / Module 2 retake]."* Pin the doc. Re-read the line every Monday for 4 weeks.
+- **Share the worksheet result with one peer or advisor in a 20-minute call.** Not three. One. Ask them: *"If the matrix said Path X, what would change your mind?"* Their first answer is the assumption you should pressure-test next. If they cannot name one, the matrix verdict holds.
+- **Schedule the first action for tomorrow morning.** Path 1: ship the Carrd page. Path 2: paste one-page brief into Lovable. Path 3: 3 LinkedIn outreach messages to Fractional CTOs in your industry. Path 4: read the SOW clause-by-clause with a printed pen, not in Google Docs. Calendar the action with a hard start time. The worksheet routes the decision; the calendar invite routes the work.
+
+Skip this worksheet and route on advisor instinct and you're the founder who, six weeks later, signs a contract the data did not support and posts a [salvage or rebuild question](/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/) when the build runs over budget. The matrix is cheaper than the contract it prevents.
+
+If you want the doctrine in long form, the [Module 4 post](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/) walks through the Airbnb test, the Rob Walling shed-vs-skyscraper warning, and the worked example for each of the four paths.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/cover.png b/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/cover.png
new file mode 100644
index 000000000..0344ea4db
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/index.md b/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/index.md
new file mode 100644
index 000000000..361eecc80
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/index.md
@@ -0,0 +1,266 @@
+---
+title: "5.2 · Choose Your Channel Before You Send One Message"
+aliases: ["/blog/channel-selection-before-outbound/"]
+description: "Channel-hopping after the first batch is the most common newbie mistake. The commitment rule + how to pick from interview evidence + AI-augmented channel research."
+date: 2026-05-13
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: channel-selection-before-outbound
+keywords:
+  - channel selection startup
+  - non technical founder outbound
+  - channel market fit
+  - first ten customers channel
+  - 4 week channel commitment
+tags:
+  - founders
+  - non-technical-founder
+  - module-5
+  - sales
+  - ai-augmented
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "5.2 · Choose Your Channel Before You Send One Message"
+  og_description: "Channel-hopping after the first batch is the most common newbie mistake. The commitment rule + how to pick from interview evidence + AI-augmented channel research."
+cover_image_alt: "JetThoughts blog cover for Chapter 5.2 - choose one outbound channel and commit for four weeks before switching"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/"
+related_posts: false
+---
+
+> **Module 5 · Step 2 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** 10 Mom Test interview transcripts from Module 2 + your live MVP from Module 4 (Ch 4.3b) + the ICP (Ideal Customer Profile - the specific kind of person your hypothesis names; introduced in Ch 1.1) you sharpened across Modules 1-2
+>
+> **Output:** one channel hypothesis committed long enough to read the signal
+
+> **TL;DR:** Pick one channel from your interview evidence and commit for a full send/reply/follow-up arc. Channel-hopping is the most common newbie mistake - you can't read a signal you never let stabilize.
+
+The channel-flailing pattern: switch every 10 days - LinkedIn for two weeks, cold email for two weeks, a Slack community for two weeks, back to LinkedIn. Six weeks in, 8 conversations, zero paid pilots, and no idea which channel actually worked.
+
+The fix is rarely "find a smarter channel." It's pick one channel from your interview evidence and stick with it through a full send/reply/follow-up arc. Same six weeks on LinkedIn alone produces 11 conversations, 2 paid pilots, and a clear hypothesis about what to test next.
+
+The pattern: four channels, no commitment, and no way to tell which channel had worked because none of them had been run long enough to read.
+
+You ran 10 interviews in [Module 2](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/). Your interviewees told you exactly how they find tools like yours. They just did not use the word "channel" when they said it.
+
+This chapter is about listening to what they actually said and committing to one channel before you try anything else.
+
+## The commitment rule
+
+Stick with one channel long enough to read the signal, not chase the algorithm. A cold-email sequence needs time to deliver, more time for replies to accumulate, and more time still before the "not now" replies reveal whether the non-replies are disinterest or bad timing.
+
+Run a batch, call the channel dead because you got 2 replies right away, and you just threw away the signal.
+
+| Phase | Activity | Expected signal | Decision checkpoint |
+|------|----------|-----------------|-------------------|
+| **Send phase** | Build list, send the first batch | 1 reply = normal; panic is common | Do not switch channels |
+| **Reply phase** | Replies arrive, book demos | A handful of demos booked = channel reaches buyer | First real signal the channel works |
+| **Follow-up phase** | Follow-ups + a fresh batch | A paid conversation or two start, reply rate stabilizes | Rate becomes predictable |
+| **Decision phase** | Evaluate all signals | Reply rate >5%? Demos → paid? Right buyer? | If all 3 = no, diagnose script/filter before switching |
+
+The rule is not a ritual. It is the minimum data window that separates "this channel does not work" from "I ran this channel for a few days and panicked."
+
+## How to pick from interview evidence
+
+Your 10 interview transcripts from [Module 2](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) already contain the channel signal. Pull them up and look for three types of clues:
+
+| Clue type | Question to ask | What it signals |
+|-----------|-----------------|-----------------|
+| **Discovery language** | "How do you currently find tools like this?" | Direct answers: "Slack group" = community; "Google search" = SEO; "network referral" = LinkedIn/email; "Twitter" = social |
+| **Where they showed up** | Did they come from a community post or LinkedIn outreach? | If 7 of 10 came from one channel, that channel already converts for recruitment → will convert for sales |
+| **Daily workflow** | "What tools do you use every day?" | Notion + Slack users won't find you in cold email; they find you in community or template gallery |
+
+Go through each transcript. Mark the channel signals. You will see a pattern across 10 interviews that you cannot see in any single conversation.
+
+## Channel-fit scoring
+
+Not every channel fits every product. Four dimensions narrow the field before you spend a single hour:
+
+| Dimension | Question | Scoring rule |
+|-----------|----------|--------------|
+| **Price point** | Can you afford the channel's acquisition cost model? Use the price you tested in [Chapter 1.3](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/) as the input here. | <$50/mo tested = free/organic only; $200-$500/mo = LinkedIn; >$500/mo = outbound calls viable |
+| **Buyer type** | Where do your must-have buyers actually live online? | Individuals = social + Reddit; B2B = LinkedIn + email + professional communities |
+| **Your time budget** | What can you honestly sustain through a full send/reply/follow-up arc? | LinkedIn 20-30 min/10 msgs; cold email 5-8 min/10 msgs; community 45 min/post + no daily mgmt |
+| **Interview signal** | What did your 10 transcripts actually say? | Count mentions per channel; 7-of-10 = louder than gut feeling |
+
+Score each candidate channel 1-3 on all four dimensions (1 = poor fit, 2 = moderate, 3 = strong). Add to get 12-point total.
+
+> **Threshold rule.** ≥9/12 = clear pick, commit to that channel. 7-8/12 = run a 1-week pilot on your top 2 channels first to break the tie; the higher reply rate wins. ≤6/12 = no channel is a strong fit; revisit your 10 interview transcripts for missing signal (channel-mention, daily-workflow, where-they-already-buy) before scaling outbound at all. Picking a 6/12 channel and committing is the failure mode the scoring exists to prevent.
+
+## The 4 channels for newbie B2B and B2C
+
+At this stage you are choosing from four options. Here is what each one actually requires:
+
+| Channel | Best for | Requires | Red flag |
+|---------|----------|----------|----------|
+| **LinkedIn DM** | B2B SaaS/services, professional buyers, job-title filtering, $200+/mo | 1-2 hrs/week; Sales Navigator trial or Apollo.io free tier (credit-based: ~100 email credits + ~10 export credits/mo); one clear filter (title + company + industry) | Buyer is not a professional (freelancer, solo creator, non-employee) |
+| **Cold email** | Any B2B with verified work emails; cheaper at volume | Separate sending domain; free tool ([Instantly](https://instantly.ai) / [Smartlead](https://smartlead.ai)); 30-50 emails from [Apollo](https://apollo.io) / [Hunter](https://hunter.io) (25 searches/mo free tier) | Open rate <20% after first batch = domain rep or subject lines broken; fix before scale |
+| **Community outreach** | B2B and prosumer where buyers already gather in Slack/Discord/forum | Must be a genuine participant first; one signal-quality post per sprint (not per week); spend 2 weeks commenting before posting product or get banned permanently | Joining this week then immediately selling = permanent ban from the community |
+| **Social organic** | B2C and prosumer, visual products (apps, productivity tools, demos); buyer discovery from peers/influencers | A sustained posting cadence; format shows product working (screen recordings, before/after, results) | Never posted before AND can't commit to the early low-visibility stretch |
+| **Engineering as Marketing** | Any B2B or prosumer where your ICP searches for tactical solutions; zero-CAC organic SEO | One free no-code micro-tool (calculator, checklist, grader, template) that solves one micro-problem for your ICP; build it on Carrd/Tally/Notion in an afternoon | Your ICP doesn't search for tactical tooling (they buy via referral or sales call); the micro-tool solves a toy problem nobody actually has |
+
+Pick the one that matches your buyer type, your price point, and your honest time budget - then commit.
+
+> **Engineering as Marketing: the zero-CAC (Customer Acquisition Cost - what you spend to land one customer) channel.** Building a free micro-tool (a pricing calculator, a checklist generator, a "which plan is right for you" grader) on a free no-code stack (Carrd + Tally + Notion) attracts targeted organic search traffic. Users who find the tool useful are pre-warmed leads for your main product. The tool ranks for long-tail SEO keywords your competitors ignore. One afternoon to build, zero monthly cost, and the traffic compounds over months. Unlike content marketing (blog posts), a functional tool has a different backlink profile and ranks for different intent - someone searching "SaaS pricing calculator for [vertical]" is closer to buying than someone searching "how to price SaaS." The tool is not your product - it's a free side door that feeds your product's waitlist.
+
+## AI-augmented channel research
+
+After you pull the signal from your transcripts, run one Claude prompt to pressure-test your hypothesis before you commit to it:
+
+```text
+I am a founder building [product description in one sentence].
+My must-have user is [specific buyer persona: title, company size, industry].
+My price point is [monthly or per-seat price].
+
+From 10 customer interviews, I heard these channel signals:
+- [Quote or paraphrase from interview 1]
+- [Quote or paraphrase from interview 2]
+- [... up to 5 signals]
+
+I am considering [channel A] vs [channel B] for my first stretch of outbound.
+
+Based on the buyer persona and interview signals, which channel is more likely to reach them in the mode where they are open to discovering new tools? What would I need to believe for [channel A] to be right vs [channel B]?
+```
+
+Claude cannot guarantee the right answer - it does not know your specific market. But it will surface the assumptions behind each choice and flag contradictions you missed.
+
+Run the prompt against your own transcripts. If your interview evidence points to one channel (8 of 10 saying "I found it on LinkedIn") while your gut points to another (cold email feels safer), name the gap to yourself: which signal are you ignoring, and why?
+
+The prompt is a forcing function, not a crystal ball. The real data comes from running the channel.
+
+> **Fast-path exit: skip the worksheet if your interviews already named a channel.** If your Ch 2.3 (a + b) interview transcripts pointed to a clear channel (e.g., 7+ of 10 interviewees found tools through LinkedIn, or 5+ named a specific Slack community), jump to Part 3: The Commitment at the bottom of the worksheet. Write your commitment statement and move to Ch 5.3. The full worksheet is for founders still deciding between channels. It's a diagnostic, not a gate.
+
+> **Module 5 AI critic/simulator block**
+>
+> The Claude prompt in the section above is the Module 5 critic layer. It pressure-tests your channel hypothesis against interview evidence, surfaces assumptions behind each choice, and flags contradictions between what your transcripts said and what your gut says.
+>
+> **What AI cannot prove or substitute:**
+> - Which channel will actually convert (only a real send/reply/follow-up arc can)
+> - Your reply rate, demo rate, or paid-conversation rate (only real messages to real buyers can)
+> - Whether the channel degrades over time (only sustained use reveals this)
+>
+> **The real gate:** ≥9/12 channel-fit score + a full send/reply/follow-up arc with reply rate >5%.
+>
+> **Optional: auto-parse social media for leads.** [WorthBuild](https://worthbuild.io) (1 free report/month) scans Reddit, Twitter/X, and LinkedIn for posts matching your ICP's problem description and returns a list of named people publicly complaining about the thing you solve. Use it to seed your outreach list when the manual reading in Ch 2.3 (a + b) didn't produce enough names. The free tier gives you one batch per month - save it until you have exhausted your hand-picked list and need fresh contacts.
+
+## Channel Selection Worksheet
+
+Fill this out before you send message one. It prevents the wasted-effort cycle of channel-hopping.
+
+### Part 1: Interview Evidence
+
+Go through each interview transcript. For each one, note any channel signal the interviewee gave - directly or indirectly.
+
+| Interview # | Interviewee role | Channel signal (direct quote or paraphrase) | Channel type implied |
+|-------------|------------------|---------------------------------------------|----------------------|
+| 1 | | | |
+| 2 | | | |
+| 3 | | | |
+| 4 | | | |
+| 5 | | | |
+| 6 | | | |
+| 7 | | | |
+| 8 | | | |
+| 9 | | | |
+| 10 | | | |
+
+**Tally by channel type:**
+- LinkedIn mentions: ___
+- Email / newsletter mentions: ___
+- Community / Slack / Discord mentions: ___
+- Social (Twitter, Reddit, TikTok) mentions: ___
+- Search / Google mentions: ___
+- Word of mouth / referral mentions: ___
+
+**Strongest signal** (channel with most mentions): _______________
+
+### Part 2: Channel-Fit Score
+
+Score each candidate channel 1-3 on the four dimensions (1 = poor fit, 2 = moderate, 3 = strong). Add the four to a total out of 12. Use the per-channel guidance below as the anchor.
+
+**LinkedIn DM → B2B SaaS, $200+/month.** Pick when: buyer is a professional, title and company size filter cleanly, 1-2 hours/week available. Skip when: buyer is a freelancer, solo creator, or under 30 years old.
+- Price fit: ___ / Buyer type fit: ___ / Time budget fit: ___ / Interview signal fit: ___ / **Total: ___**
+
+**Cold email → Any B2B with verified work emails.** Pick when: you have 30-50 verified emails, a sending domain that is not your main domain, deliverability you can monitor. Skip when: open rates stay below 20% after batch 1 (domain or subject line is broken; fix before scale).
+- Price fit: ___ / Buyer type fit: ___ / Time budget fit: ___ / Interview signal fit: ___ / **Total: ___**
+
+**Community outreach → B2B and prosumer where buyers already gather.** Pick when: a specific Slack/Discord/forum exists, you are already a participant, you can post one signal-quality post per sprint. Skip when: you joined this week (spend two weeks commenting before posting product, or get banned permanently).
+- Price fit: ___ / Buyer type fit: ___ / Time budget fit: ___ / Interview signal fit: ___ / **Total: ___**
+
+**Social organic → B2C and prosumer with a visible product.** Pick when: a sustained posting cadence is realistic, format shows the product working (screen recordings, before/after, results). Skip when: you have never posted content before and cannot commit to the early stretch of posting into a void.
+- Price fit: ___ / Buyer type fit: ___ / Time budget fit: ___ / Interview signal fit: ___ / **Total: ___**
+
+**Highest-scoring channel**: _______________
+
+### Part 3: The Commitment
+
+Write this down. Literally write it. Skip this step and you are the founder who hops channels at the first cricket.
+
+```text
+My chosen channel: [channel name]
+
+Why this channel:
+1. Interview evidence: [which interviewees, what they said]
+2. Buyer type match: [why this channel reaches my buyer]
+3. Price point math: [estimated cost per lead vs my price point]
+4. Time budget: [time per batch I will actually spend]
+
+I will not switch channels until I have run a full send/reply/follow-up arc.
+
+At the evaluation point, I will check:
+- Reply rate (target: >5%)
+- Demo-to-conversation rate (target: >20%)
+- Any paid conversations started (target: ≥1)
+
+If all three targets missed: diagnose the filter and script first, then consider a channel switch.
+```
+
+Keep this in the same Google Sheet as your interview transcripts. Look at it before you send each batch.
+
+---
+
+The decision matters more than the channel itself. Committing to one channel and iterating on the script beats splitting your time across three by a wide margin, because the learning loop is tighter.
+
+With 30 focused messages you get a reply rate you can diagnose; with 10 messages spread across three channels you get nothing you can act on.
+
+Pick the channel your interviews point to, write it down, and give it a real run before you question it.
+
+The first place to apply this is your personal network in [Chapter 5.3 (The First Ten Come From People Who Already Know You)](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/). Once that is exhausted, [going outbound without a sales team](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/) covers the tactics for running the channel you just chose: the filter, the script, the Calendly-to-Stripe pipeline, and what the reply rate actually means.
+
+## What to do tomorrow
+
+1. Open the worksheet above and score each of the 4 channels against your customer interview answers. Pick the one that maps to the most evidence.
+2. Write the channel name + your commitment statement in a Notion doc. The clock starts the day you send your first outbound message.
+3. Read [Chapter 5.3 - The First Ten Come From People Who Already Know You](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/) before your first send - that's the playbook for getting the first conversations on the channel you just picked.
+
+> **Module 5, Step 2 of 5** - channel selection is the decision before any outreach tactic. Finish the worksheet above before you open a single sales tool.
+> Next: [5.3 · The First Ten Come From People Who Already Know You](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/)
+> Course: [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+
+Pick the channel your interviews already named, commit to it long enough to read the signal, and stop running pilots against your own attention.
+
+## Further reading
+
+- Lenny Rachitsky, [How today's fastest growing B2B businesses found their first ten customers](https://www.lennysnewsletter.com/p/how-todays-fastest-growing-b2b-businesses) - the channel breakdown across Figma, Stripe, Slack, Notion. Channel choice is the first lever, not the last.
+- Brian Balfour, [Why Product Market Fit Isn't Enough](https://brianbalfour.com/essays/product-market-fit-isnt-enough) - the case for channel-model fit as a distinct requirement from product-market fit. Strong reading for any founder who has a working product but no acquisition motion.
+- Andrew Chen, [The Law of Shitty Clickthroughs](https://andrewchen.com/the-law-of-shitty-clickthroughs/) - why every channel degrades over time and why early-stage founders need to pick the channel that works now, not the channel that worked for a more established company 3 years ago.
+- First Round Capital, [From 1 to 1,000 Users](https://review.firstround.com/from-1-to-1000-users-tactics-from-airbnb-tinder-etsy-reddit-and-more/) - channel selection stories from Airbnb, Tinder, Etsy, Reddit, including how each picked their first acquisition channel based on where their early customers actually lived online.
+
+> **Done when:** Your worksheet is filled, one channel is chosen, and you have written your commitment statement (channel name + why + evaluation criteria).
+>
+> **Next click:** [5.3 · The First Ten Come From People Who Already Know You](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/)
+>
+> **If blocked:** If no channel scores ≥9/12, your interview transcripts are missing channel signal. Re-read the transcripts looking for "how do you find tools like this" and "what tools do you use every day" - the answers are already in there.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Channel scoring: LinkedIn (9/12 - controllers are there), cold email (8/12), Reddit (5/12). Commits to LinkedIn + cold email. Scoring: 8.0/10.
+>
+> **Mia**: Channel scoring: Facebook groups (9/12 - parents are there daily), school referrals (7/12), Instagram (5/12). Commits to Facebook groups + school district referrals.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/cover.png b/content/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/cover.png
new file mode 100644
index 000000000..9b7767815
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/index.md b/content/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/index.md
new file mode 100644
index 000000000..04295c388
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/index.md
@@ -0,0 +1,392 @@
+---
+title: "2.4 · Build a Clickable Prototype"
+aliases: ["/blog/clickable-prototype-validation-2-hour-lovable/"]
+description: "A throwaway Lovable prototype lets 5 interview subjects experience the SHAPE of your solution. The third validation pillar after the landing page."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: clickable-prototype-validation-2-hour-lovable
+keywords:
+  - lovable prototype validation
+  - clickable prototype mom test
+  - 2 hour mvp prototype
+  - non technical founder validation
+  - throwaway prototype customer research
+tags:
+  - founders
+  - non-technical-founder
+  - module-2
+  - validation
+  - ai-augmented
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "2.4 · Build a Clickable Prototype"
+  og_description: "A throwaway Lovable prototype lets 5 interview subjects experience the SHAPE of your solution. The third validation pillar after the landing page."
+cover_image_alt: "JetThoughts cover for Chapter 2.4 - hand-drawn three-screen clickable prototype with five user-test sessions and pass/fail signal markers"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/"
+related_posts: false
+---
+
+> **Module 2 · Step 4 of 4** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** 5 of the 10 Mom Test interviewees from Chapter 2.3 (recruited in [2.3a](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/), messaged in [2.3b](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/)) - pick the strongest-signal ones (scored per the Ch 2.1 rubric)
+>
+> **Output:** 5 of them watched navigating a throwaway clickable prototype, with pass/fail per session
+
+> **TL;DR:** Three throwaway screens, five silent-observation sessions. Watch whether users can navigate your solution without coaching - something interviews cannot tell you.
+
+> **How this chapter relates to Ch 2.3 (a + b):** [Ch 2.3 (a + b)](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) already booked and ran your 10 past-behavior Mom Test interviews. This chapter takes 5 of those 10 (the ones who scored 7+ on the Mom Test) and re-engages them for a 30-min silent-observation session with a throwaway Lovable prototype. You are NOT recruiting fresh people; you are re-asking warm contacts for a different kind of time. Ch 2.3 (a + b) validated THE PROBLEM; Ch 2.4 validates THE SOLUTION SHAPE.
+
+The [Mom Test](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) tells you whether the problem is real and felt. A clickable prototype tells you something the Mom Test cannot: whether the user knows what to do when you hand them a solution.
+
+Those signals do not measure the same thing.
+
+One of the founders we sat with had run 8 Mom Test interviews that came back strong: workaround evidence, named monthly costs, real frustration language. She moved to Lovable (an AI app builder; see the gloss in [Chapter 4.3a](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/)) and built a working app over several weeks.
+
+When she had 5 of the same interviewees log in to try the live app, several stalled on screen 2 - they recognised the problem the app was solving but could not figure out which button to click next. Validating the problem had not validated whether the interface shape was something they could navigate.
+
+A throwaway prototype run in front of 5 of your interview subjects would have surfaced that early, not after the real build had landed. The rest of this chapter walks you through running one.
+
+> **This is a research tool, not the start of your MVP.**
+>
+> You will build 3 throwaway screens, show them to 5 of your Mom Test interviewees, watch what they do without coaching, then archive everything. The only outputs that carry forward into Module 3 are (a) the pass/fail signal and (b) the exact words your users used when describing what they saw. The prototype CODE is discarded.
+>
+> If you try to polish this prototype into your MVP later, you'll spend much longer on it, carry every throwaway compromise into production, and invalidate the shape test. The actual MVP is a fresh build in Module 4 ([Ch 4.3a](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) defines the stack, [Ch 4.3b](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/) walks the phases), started from the one-page brief (Chapter 3.1) with real auth, real Stripe, real domain.
+
+## Why a Clickable Prototype Catches What Interviews Miss
+
+A Mom Test interview pulls the interviewee into the past. You ask "tell me about the last time this happened" because you are trying to find out whether the problem actually occurred and how badly it hurt when it did.
+
+A prototype session does the opposite: it puts the interviewee into a possible future and watches what they do.
+
+You hand them three screens and watch whether they can figure out which button to click next without you coaching them. That is the signal interviews cannot give you.
+
+Three things break at the prototype stage that looked clean in interviews:
+
+| Failure | What happens | Why interviews miss it |
+|---|---|---|
+| **Workflow backward** | The founder designed the three screens in the order she thought about the problem. The user thinks about it in the opposite order. Screen 1 asks for the wrong piece of information; the user stalls. | An interview asks "how do you do X" - it never asks "what would you click first on a screen." |
+| **Vocabulary wrong** | Founder calls it "reconciliation." User's accountant calls it "matching." Button says "Reconcile"; user clicks everything else on the screen first. | Verbal language in an interview doesn't expose what label a user expects on a button. |
+| **Scope wrong** | User opens the prototype, sees three screens, asks "where do I upload the CSV?" That feature was in Module 5 of the founder's plan; she considered it obvious context. It isn't. | Interview answers paint the system the founder describes, not the surface the user touches. |
+
+None of these show up in a Mom Test interview - they only appear the moment a real person touches the interface, which is why both validation methods matter.
+
+The prototype session is the third validation pillar. The other two tests cover different ground.
+
+The [smoke test](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) shows whether strangers will click your headline. The Mom Test shows whether the problem you found is one your interviewees actually feel.
+
+Neither answers the question this chapter is built around - whether a real user can find their way through your interface without someone over their shoulder telling them what to do.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart LR
+    A["Smoke Test
Do strangers click?
Demand signal"] --> B["Mom Test
Is the problem felt?
Problem signal"]
+    B --> C["Prototype Session
Can users navigate?
Shape signal"]
+    C --> D["Module 3
One-Page Product Brief"]
+    classDef red fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a
+    classDef purple fill:#fbe9ff,stroke:#a855f7,stroke-width:2.5px,color:#1a1a1a
+    class A,B,C red
+    class D purple
+```
+
+## This Is Throwaway
+
+> Three screens, fake data hard-coded in, CTAs that navigate but do not save. You are building a question-"Does the user know what to do?"-not a product. Then you archive it.
+
+Try to "polish the prototype into the MVP later" and you spend much longer on it, add features that invalidate the shape test, and carry every throwaway compromise into production. The [Module 4 Lovable build](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) starts fresh with a proper one-page brief, real auth, and a real database. This prototype has one goal: three screens, five sessions, then archive.
+
+## Build 3 Screens with Lovable
+
+[Lovable](https://lovable.dev) is an AI app builder that generates a working web app from a prompt. Free trial; paid plans from $25/month. No coding required.
+
+Three screens is the constraint - not five, not ten - because each extra screen multiplies the build effort without sharpening the validation signal.
+
+> **The two caps that replace "spend a weekend on it".** (1) **Stop at 3 screens.** The fourth screen is the prototype turning into the MVP - exactly the failure mode this chapter prevents. (2) **Aim for a navigable 3-screen prototype within your first ~10 Lovable exchanges.** If after 10 messages the screens still aren't navigable, the hypothesis or the prompt is too vague - sharpen the prompt (or go back to Ch 1.1) before continuing. Do NOT keep adding messages hoping to brute-force coherence.
+
+### Screen 1 - The entry point
+
+Whatever the user sees first when they open your product. For a workflow tool that is usually a dashboard or an upload screen. For a booking product, a calendar or a search bar. Keep it to one dominant action. The user should be able to answer "what does this screen want me to do?" in 5 seconds.
+
+### Screen 2 - The core action
+
+The step where the value is delivered. For the reconciliation tool: the screen where matched transactions appear. For a booking product: the screen where the user picks a time. For a document tool: the screen where the user sees the processed output. This is where users stall if the vocabulary or layout is wrong.
+
+### Screen 3 - The confirmation or result
+
+What the user sees after the core action succeeds. A confirmation message, a summary, a next-step prompt. This is what the user walks away holding in their memory. If they cannot describe it 10 minutes after the session, the outcome of the product is not clear.
+
+### The Lovable Prompt Template
+
+> **📋 Save this template.** Copy the prompt below into your notes. You'll reuse the same structure in [Module 4's real MVP build](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) - same Lovable tool, same 3-screen skeleton, but with real auth, real database, and real Stripe.
+
+> **Practical Lovable onramp.** [Lovable](https://lovable.dev) is an AI app builder that generates a working web app from a prompt - you type what you want in English, it ships the screens. The **free trial** gives you a small number of messages per day with no credit card required, which is enough to ship this 3-screen throwaway prototype. **Paid plans start at $25/month (Pro)** and are only worth it later if you decide to upgrade for higher message volume - not required for this chapter.
+
+> **If you hit Lovable's free-tier daily cap (5 messages):** save your work-in-progress (Lovable auto-saves to your account, but copy the prompt + the current screen output to a note), come back tomorrow when the cap resets, OR upgrade to $25/mo Pro if you want to ship in one focused session. The 3-screen prototype rarely needs more than 10 total messages once your prompt is well-formed - the cap usually bites only on poorly-scoped first attempts.
+
+Open [Lovable](https://lovable.dev), create a new project, and paste the following. Replace all `[PLACEHOLDERS]` with your specific problem and solution.
+
+---
+
+**Prompt template to paste into Lovable** (placeholders in `[brackets]`):
+
+```text
+Build a 3-screen clickable prototype for a [PRODUCT CATEGORY] tool targeting [TARGET USER].
+
+This is a throwaway validation prototype. Use hard-coded fake data only. No backend, no auth, no database. All buttons should navigate between screens or show a static success state.
+
+SCREEN 1 - [ENTRY POINT NAME]:
+- [PRIMARY ACTION the user takes on this screen]
+- Show [FAKE DATA EXAMPLE]
+- One prominent CTA button: "[BUTTON LABEL]"
+
+SCREEN 2 - [CORE ACTION NAME]:
+- [WHAT THE USER SEES after taking the Screen 1 action]
+- Show [FAKE DATA EXAMPLE]
+- [KEY VOCABULARY the user must understand]
+- One action: "[BUTTON LABEL]"
+
+SCREEN 3 - [RESULT/CONFIRMATION NAME]:
+- [WHAT SUCCESS LOOKS LIKE]
+- Next step prompt: "[WHAT YOU WANT THE USER TO DO NEXT]"
+
+Design: Clean, minimal. Dark sidebar, white content area. [YOUR COLOR] accent. No login screen. No settings. No navigation beyond these 3 screens. Make it look functional, not finished.
+```
+
+**Filled-in worked example.** Below is the same prompt with every blank replaced for one made-up product - a transaction-reconciliation tool for freelance bookkeepers. The category isn't the point; the *level of specificity* is. Read it before you fill yours in, so you can see what kind of answer each blank expects:
+
+```text
+Build a 3-screen clickable prototype for a transaction-reconciliation tool targeting freelance bookkeepers who reconcile Stripe + QuickBooks for client accounts.
+
+This is a throwaway validation prototype. Use hard-coded fake data only. No backend, no auth, no database. All buttons should navigate between screens or show a static success state.
+
+SCREEN 1 - Upload Statements:
+- The user uploads 3 CSVs (one Stripe export, one QuickBooks export, one bank export)
+- Show 3 uploaded files listed: Q1-report.csv, march-invoices.csv, stripe-export.csv
+- One prominent CTA button: "Match transactions"
+
+SCREEN 2 - Match Review:
+- A side-by-side table of Stripe rows next to QuickBooks rows, with a "match" indicator
+- Show 12 matched transactions, 3 flagged for review (use the word "match" not "reconcile" - the bookkeeper vocabulary is "match")
+- Use the word "match" not "reconcile" - the bookkeeper vocabulary in the field is "match"
+- One action: "Approve all matches"
+
+SCREEN 3 - Summary:
+- A summary card showing "12 transactions matched, $4,320 reconciled. 3 flagged need your review."
+- Next step prompt: "Download client-ready report (PDF)"
+
+Design: Clean, minimal. Dark sidebar, white content area. Teal accent. No login screen. No settings. No navigation beyond these 3 screens. Make it look functional, not finished.
+```
+
+If you can't fill in even the worked example's level of specificity (real product category, real user, real vocabulary, real fake-data examples), the prototype isn't your blocker - the hypothesis is. Go back to [Chapter 1.1](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) and sharpen it first.
+
+---
+
+That prompt typically produces a navigable 3-screen prototype in Lovable in our experience - results vary with prompt detail and Lovable model availability that day. Once the screens render, spend the rest of the build on one thing: reading the fake data out loud and asking yourself "does this make sense to someone who has never heard my idea?" If you hesitate, change the wording.
+
+Two rules for the Lovable session itself.
+
+First, use the vocabulary you heard in Mom Test interviews, not the vocabulary you use when you describe the problem to other founders. If 7 of your 10 interviewees called it "matching" and you call it "reconciliation," the prototype uses "matching."
+
+Second, resist adding a fourth screen. The constraint is the test. If you feel the prototype needs a fourth screen to "make sense," that is a finding: your solution has more steps than a single session can validate. Note it and keep the prototype to three screens. You are testing legibility of the shape, not the completeness of the product.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    P["Open Lovable
Paste the prompt template"]
+    P --> R["Read fake data out loud
Change vocab to match
interview language"]
+    R --> T["Test the 3 screens yourself
as if you've never seen your idea"]
+    T --> Done["Prototype ready
Share link to 5 interviewees"]
+
+    classDef red fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a
+    classDef purple fill:#fbe9ff,stroke:#a855f7,stroke-width:2.5px,color:#1a1a1a
+    class P,R,T red
+    class Done purple
+```
+
+## Run a Silent-Observation Session with 5 Interviewees
+
+| During the session | What TO do | What NOT to do |
+|---|---|---|
+| **They pause on a screen** | Write down which button they reached for, how many seconds they paused | Don't explain what the screen does |
+| **They ask you a question** | Say "I'd love to hear what you're thinking, keep going" | Don't answer directly |
+| **They click the wrong button** | Record which button they clicked and note it | Don't tell them the right path |
+| **They finish Screen 3** | Ask: "Describe in one sentence what that tool just did" | Don't prompt or rephrase their answer |
+
+### Setup - recruit and book
+
+Choose 5 of the 10 interviewees whose Mom Test scores were 7 or higher. You already have a relationship with them. They already confirmed the problem is real. Now you are asking them one hour of a different kind of time: watching them use the interface, not answering your questions.
+
+Book the sessions as 30-minute video calls. Send the Lovable prototype link 10 minutes before - not earlier. You do not want them exploring it solo before you can observe.
+
+**The re-engagement message** (paste into LinkedIn DM or reply to your original Ch 2.3 (a + b) thread):
+
+> *"Hi [name] - thank you for the 40 minutes last week. I built a quick clickable prototype based on what you told me about [their specific workaround from the Mom Test transcript]. I'd like 30 more minutes to watch you try it without me explaining anything - just silent observation while you click through. I'll send the link 10 minutes before. Would Tuesday afternoon or Wednesday afternoon work?"*
+
+Expect 4-5 of 5 to say yes. They invested 40 minutes in the first call; the second ask is half that time and a different motion. The *"I built something based on what you told me"* line is the unlock - it signals you listened, and it makes the prototype session feel like the natural continuation of the first conversation rather than a fresh cold outreach.
+
+> **Slow-path variant for the part-time founder**: scheduling 5 live observation calls on top of your only weekly window is unrealistic. Async alternative: send each interviewee the Lovable prototype link + a short Loom prompt ("record yourself trying these 3 tasks"). Use [Maze](https://maze.co) (free tier covers 3 testers) or [UserTesting](https://www.usertesting.com) (paid) if you want screen recording with click heatmaps. You lose the real-time follow-up question ability, but you gain async scheduling - the testers record on their own time, you watch the 5 recordings in one batch. Catch rate is about 70% of what live sessions surface (you miss the "what were you about to click" follow-ups) but 200% better than skipping the validation step because you couldn't schedule it.
+
+### Script - the prototype session
+
+**What most founders say first (and why it ruins the session):**
+
+> "Hi! Thanks so much for testing my prototype. I'm really excited to show you what I've been working on - I've been building this for the last few weeks. Just click around and tell me what you think! Don't worry, it's still early. Let me know if anything's confusing and I can walk you through it."
+
+Every sentence above quietly biases the test:
+
+- **"my prototype"** + **"I've been building"** - the interviewee now knows it's YOUR baby. They're going to be kind, not honest.
+- **"really excited"** - sets the emotional contract: please don't disappoint me.
+- **"click around and tell me what you think"** - asks for opinion, not behavior. Opinions are cheap and polite.
+- **"I can walk you through it"** - signals you will rescue them if they get stuck. The whole point of the test is to find where they get stuck WITHOUT rescue.
+
+You now run a session where the interviewee performs satisfaction for you instead of doing the thing. You learn nothing about whether the screens make sense.
+
+**Opening (read verbatim, do not paraphrase):**
+
+"Thank you for your time. I'm going to share a link with you - I'm sending it now in the chat. It's a very early rough prototype, not a real product. I want to watch you use it and understand where it's clear and where it's confusing. Please don't try to be kind to me. The most useful thing you can do is think out loud while you click through it and tell me when you're confused or when something doesn't make sense. I won't explain anything while you use it. Just start from Screen 1 and try to do what the screen is asking. I'll stay quiet."
+
+*[Paste the Lovable link in the chat. Start your screen recording. Say nothing.]*
+
+**While they work through it:**
+
+- Start a timer when they first touch the interface.
+- Write down: the first 3 things they click or try to click.
+- Note the first moment they pause for more than 5 seconds.
+- Note any words they say out loud ("what does this mean", "where do I", "I thought it would").
+- Do not respond to questions. Say "I'd love to hear what you're thinking, just keep going" if they ask you a direct question. Do not explain. Do not coach.
+
+**After they reach Screen 3 (or after 10 minutes, whichever is first):**
+
+"Thank you. Can you describe to me in one sentence what that tool just did for you?"
+
+Write down their exact words. Do not prompt. If they give a vague answer, say: "Say more about that." If they stall, say: "What would you tell a colleague this does?"
+
+**Closing questions (pick 2, not all 4):**
+
+- "What was the moment you felt most lost?"
+- "What did you expect to see on the second screen that wasn't there?"
+- "If you used this every week, what would you call the thing it does for you?"
+- "What would have to be true for you to pay [your target price] for this?" (Use the price hypothesis you tested in [Chapter 1.3](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/) - if you haven't run that test yet, the chapter's $49-$299 band is your default starting point.)
+
+Thank them. End the call. Score the session immediately.
+
+### Scoring - what to record live
+
+When the user pauses on Screen 2 for 8 seconds and clicks the wrong button, you will want to help. Do not. The pause and the wrong click are the signal you came for. Write down exactly which button they clicked and how long they paused. That is the data.
+
+If the user says "I give up" or "I have no idea what this wants me to do" - that is a fail. Thank them, ask the closing questions, end the call. A session where the user cannot get past Screen 1 is a strong signal: the entry point is wrong.
+
+## Pass/Fail Scoring
+
+Score each session immediately after the call ends. Use three signals.
+
+| Signal | Pass | Fail |
+|---|---|---|
+| Gets to Screen 3 without coaching | Yes, under 5 minutes | No, or needs explanation |
+| Describes the product accurately in 1 sentence | Names the core action correctly | Vague ("it does something with data") or wrong |
+| First 3 clicks are correct | Navigates toward the CTA | Clicks UI elements that aren't the intended path |
+
+A session is a **pass** if all three signals are green. A session is a **fail** if any signal is red.
+
+The prototype gate:
+
+- **4 or 5 passes out of 5 sessions:** Shape is legible. Advance to [Module 3 - One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/).
+- **2 or 3 passes:** Revise one element (vocabulary, Screen 1 layout, or CTA label) and run 2 replacement sessions. One iteration only.
+- **0 or 1 pass:** The shape is wrong. The problem statement may be right but the solution concept needs a different starting point. Return to Chapter 2.1 before writing any brief. Shape mismatch usually means the problem signal you got from interviews was off - re-running the Mom Test with sharper questions catches what a prototype rebuild would miss.
+
+The common fixable failures:
+
+**The vocabulary fail.** The user understands the goal but uses a different word than your interface. Fix: run a word-swap on Screen 2. Match the vocabulary you heard in the sessions. Test with one new session before advancing.
+
+**The wrong first click.** The user clicks a secondary element on Screen 1 first - a logo, a link, a visual that looks interactive. Fix: remove everything on Screen 1 that is not the primary CTA. Prototype UI clutter is a signal that the real product will have the same problem.
+
+**The "what am I supposed to do?" question.** The user asks you what the product does before touching it. Fix: add one line of microcopy above the primary CTA on Screen 1 that names the action in the user's vocabulary. Not a headline about the product. One instruction sentence.
+
+The throwaway nature of the prototype matters here too.
+
+When you find a vocabulary fail on Screen 2 of session 3, you fix the Lovable prompt, run 2 more sessions, and discard the whole project once you've banked the insight. You do not carry the prototype forward.
+
+You carry the insight forward - into the [One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/), where it becomes a vocabulary constraint that shapes the real build.
+
+## What to Do With Results
+
+| Pass count | Outcome | Next step |
+|---|---|---|
+| **4-5 passes** | Shape is legible. Users navigate without coaching. | Write the [One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) using the exact "describe in one sentence" words from closing questions. This vocabulary is worth more than marketing copy. |
+| **2-3 passes** | Shape is mostly legible but something broke. | Revise one element (vocabulary, Screen 1 layout, or CTA label) and run 2 replacement sessions. One iteration only. |
+| **0-1 pass** | Shape is wrong. Solution concept needs a different starting point. | Read the "what did you expect to see" answers-that is the user's mental model. Return to Chapter 2.1 before restarting. Do not write the brief yet. |
+
+Catching a shape mismatch here costs you a single throwaway prototype.
+
+Catching it in Module 4, after you have started the real build, costs the real build. The throwaway prototype buys you the cheaper version of that lesson.
+
+## Artifacts you carry out of Module 2
+
+After finishing Ch 2.1-2.4, Sam has five artifacts. Each one feeds a specific downstream destination - this table is the map:
+
+| Artifact | Where it goes next |
+|---|---|
+| **Validated Problem Statement** (Ch 2.1 synthesis applied to your Ch 2.3 (a + b) transcripts) | Ch 3.1 Section 1 - copy verbatim. This is the PRD's foundation. (PRD = product requirements document, the one-page spec a team or AI agent builds from.) |
+| **Pass/fail prototype log** (5 sessions from this chapter) | Reference doc: did we get the shape right? If yes, write the brief. If no, the table above routes you to a revision or restart. |
+| **Verbatim "describe in one sentence" vocabulary** (closing answers from this chapter) | Ch 3.1 Section 3 ("what you're building") + Ch 4.3 (a + b) Lovable prompts. The user's words beat your marketing copy. |
+| **10 raw transcripts** (Ch 2.3 (a + b) interview recordings + notes) | Archive. Reference if you ever pivot - they hold the language for a re-targeted ICP. |
+| **30 raw verbatim sentences** (Ch 2.3 (a + b) step 2, Reddit/forum complaints) | Reference for Ch 3.1 Section 1 supplementary evidence + the bank for Ch 2.3 (a + b) cold-message subject lines in any future round 2. |
+
+## Iterate or proceed? The combined Module-2 decision matrix
+
+The 2 chapters each have their own iteration guidance (Ch 2.3 (a + b) reply rate, Ch 2.4 pass count above). The COMBINED decision uses both signals together:
+
+| Ch 2.3 (a + b) interview signal | Ch 2.4 prototype signal | Decision |
+|---|---|---|
+| 7+ of 10 scored ≥7 | 4-5 of 5 passed | **PROCEED** - write the Ch 3.1 brief tonight |
+| 7+ of 10 scored ≥7 | 2-3 of 5 passed | **ONE iteration round** - revise the prototype's worst-failing screen, re-run 2 replacement sessions (NOT new interviews) |
+| 5-6 of 10 scored ≥7 | 4-5 of 5 passed | **ONE iteration round** - re-interview 3 of the polite-yes scorers asking sharper past-behavior questions (NOT a new prototype) |
+| 5-6 of 10 scored ≥7 | 2-3 of 5 passed | **STOP and re-evaluate** - read all 10 transcripts; either the ICP is wrong (re-target) or the problem framing is wrong (re-write hypothesis at Ch 1.1) |
+| <5 of 10 scored ≥7 | (any) | **KILL** - the problem is too weak for this ICP. Return to Ch 1.1 with a different customer or problem blank rewritten. |
+| (any) | 0-1 of 5 passed | **STOP, don't proceed to M3** - the solution shape is fundamentally wrong; return to Ch 2.1 |
+
+The trap to avoid: doing 2-3 iteration rounds when the matrix says STOP. Module 2 is the cheapest place in the course to discover the problem or ICP is wrong - don't burn another round of interviews trying to massage signal into a problem that isn't there.
+
+---
+
+The artifacts from this chapter (pass/fail log + vocabulary) plus the validated problem statement from Ch 2.1 synthesis are everything Module 3 needs. The brief goes into [Module 4's fresh Lovable build](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/).
+
+## What to do next
+
+| Step | Action | Output |
+|---|---|---|
+| **1** | Open Lovable and run the persona-setup prompt with your 3 ICP variants. Aim for a navigable 3-screen prototype within your first ~10 Lovable exchanges; stop at 3 screens (a 4th is the prototype turning into the MVP). | Throwaway 3-screen prototype with link |
+| **2** | Book 5 silent-observation sessions with interviewees who scored 7+ on the Mom Test. Send the prototype link 10 minutes before each call. | 5 sessions on the calendar |
+| **3** | Tally the pass count from 5 sessions. Copy the exact "describe in one sentence" answers into a doc - those words go into the [One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) verbatim. | Pass/fail count + verbatim vocabulary |
+
+Nothing from the throwaway prototype carries forward except what you learned.
+
+## Further Reading
+
+- Rob Fitzpatrick, [The Mom Test (book site)](https://www.momtestbook.com/) - the problem-signal validation this prototype session builds on.
+- Steve Krug, [Don't Make Me Think](https://sensible.com/dont-make-me-think/) - the thinking-aloud usability test that the silent-observation session above is adapted from.
+- IDEO, [The Field Guide to Human-Centered Design](https://www.designkit.org/resources/1) - prototyping-for-learning methodology at the source.
+- Y Combinator, [How to Talk to Users (Startup Library)](https://www.ycombinator.com/library/6g-how-to-talk-to-users) - how the prototype observation fits into the broader customer-discovery arc.
+- [Lovable](https://lovable.dev) - the AI builder used in this chapter's throwaway prompt-to-prototype workflow.
+
+> **Done when:** 5 silent-observation sessions are complete, scored with pass/fail per session, and you have verbatim vocabulary from the closing "describe in one sentence" answers.
+> **Founder OS · Artifact #3 of 6:** 10 scored Mom Test transcripts (from Ch 2.3a + 2.3b) + 5 prototype session pass/fail signals + the `Prototype Vocabulary - [date]` doc with verbatim "describe in one sentence" answers. Drop them all in your `Founder OS` folder; Ch 3.1 reads the vocabulary into Section 3 of the brief.
+>
+> **Next click:** [3.1 · The One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/)
+>
+> **If blocked:** If 0-1 of 5 sessions passed, the solution shape is wrong. Read the "what did you expect to see" answers from the closing questions - that is the user's mental model. Return to Ch 2.1 before writing the brief.
+
+> **Module 2 closes here.** Before opening Module 3, you should have: (1) a sharpened question list after the AI persona rehearsal (Ch 2.2), (2) a 30-name ICP list built from real complaints (Ch 2.3a), (3) 10 interview transcripts scored 7+/10 strong signal (Ch 2.3b), (4) a one-page validated problem statement with build/pivot/kill verdict (Ch 2.1b synthesis), and (5) 5 prototype sessions with verbatim "describe in one sentence" vocabulary (this chapter). All five in your `Founder OS` folder. Missing one? Go back - Module 3 cannot start without the validated problem statement + prototype vocabulary.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Builds a 2-hour Lovable prototype: a dashboard showing mock reconciliation - Stripe transactions on the left, QuickBooks invoices on the right, a "match" button in the middle. 4 of 5 controllers say "when can I use this?" 1 objects: "what happens when the match is wrong?"
+>
+> **Mia**: Builds a 2-hour Lovable prototype: a tutor search page with filters (specialty, location, availability) and mock profiles with reviews. 4 of 5 parents say "I'd use this tomorrow." 1 asks for reviews before booking - she adds them.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/cover.png b/content/course/tech-for-non-technical-founders-2026/cover.png
new file mode 100644
index 000000000..06719ed14
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/cover.png b/content/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/cover.png
new file mode 100644
index 000000000..3f725b3d1
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/index.md b/content/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/index.md
new file mode 100644
index 000000000..b21bb9387
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/index.md
@@ -0,0 +1,192 @@
+---
+title: "When Your Customers Are Leaving: Churn Triage Before Acquisition"
+aliases: ["/blog/customers-leaving-churn-triage-not-acquisition/"]
+description: "30 paying users churning at 60% / month. Module 5 is about getting customers; this chapter is about keeping the ones you have. The 3-decision triage: fix product, change segment, or kill the SKU."
+date: 2026-05-14
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: customers-leaving-churn-triage-not-acquisition
+keywords:
+  - founder churn triage
+  - non technical founder customer churn
+  - what to do when users leave saas
+  - product market fit churn signal
+  - churn cohort analysis founder
+tags:
+  - founders
+  - non-technical-founder
+  - first-paying-customer
+  - course-companion
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "7.5 · When Your Customers Are Leaving: Churn Triage Before Acquisition"
+  og_description: "30 paying users churning at 60% / month. Module 5 is about getting customers; this chapter is about keeping the ones you have. The 3-decision triage."
+cover_image_alt: "JetThoughts course cover for the churn triage chapter showing a leaky bucket with users dropping out faster than they enter"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/"
+related_posts: false
+---
+
+> **Going further · Continuation chapter 5 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a live product with paying customers AND a churn rate above 30%/month
+>
+> **Output:** a 3-decision triage (fix the product, change the segment, or kill the SKU) backed by cohort data you can read in 60 minutes
+
+## Acquisition Is Not Your Problem
+
+A B2B SaaS founder I worked with in early 2026 - call her R. - opened her dashboard on a Wednesday morning and saw 32 paying users at $29/month. She had texted me the screenshot the night before with one line: *"net new this month is 3, what am I doing wrong with my ads."*
+
+Here is what the numbers under that screenshot looked like. Her trial-to-paid conversion was healthy (around 11%). Her Meta Ads spend was $4,800/month. Her dev support invoice for keeping the signup flow patched was $1,400/month. New paid signups: 24. Churn in the same 30 days: 21. The bucket was leaking faster than the funnel could fill it. Net new customer count: 3. All-in spend per net new customer: $2,066. She was paying enterprise-CAC numbers for a $29/month SMB product.
+
+Her instinct, the same one every founder has when they see a 0.4% net-growth number, was to lift the funnel: better ads, lower CAC, more landing-page tests. We pulled the cohort data instead. Forty minutes in, the picture was obvious. The product worked great for one segment - 3-person teams using it as a shared workflow tool retained at around 70% by week 4. Solo users, who made up two-thirds of her signups, retained at 8% by week 4. She had been selling a 3-person workflow tool to people who wanted a single-user productivity tool. The ads were not the problem. The audience the ads were buying was the problem.
+
+The fix was not a better Meta Ads brief. The fix was to stop the ads, run a 90-minute cohort analysis, and make one of three triage decisions before she spent another dollar.
+
+### The leaky bucket - what the spend actually buys
+
+| In | Out | Net |
+|---|---|---|
+| **+24 new signups / month** | **-21 churning / month** | **+3 net new** |
+| Driven by $4,800 Meta Ads + $1,400 dev support | 65% will churn within 30 days | $2,066 spend per net new user |
+| Top of funnel is healthy (~11% trial-to-paid) | Wrong segment, no 7-day return | The fix is not the ads |
+
+Bucket holds **32 paying users at $29 / month**. Stop the ads. Run the 90-minute cohort triage. Decide: fix the product, change the segment, or kill the SKU.
+
+This chapter is the one Module 5 does not cover. Modules 6.1 through 6.5 teach you how to land your first paying customers. This chapter teaches you what to do when the customers you already have are leaving faster than the funnel can replace them. It is the chapter for the messy middle - the founder who hit Module 5 once, got customers, and watched them slip away faster than the spreadsheet predicted.
+
+The KISS rule for this chapter: if your churn is above 30% in a 30-day window, every dollar you spend on acquisition is wasted until you triage. Read on.
+
+## The 90-Minute Cohort Floor
+
+### Step 1 - pick a free analytics tool
+
+You do not need a data analyst, a Snowflake instance, or a custom dashboard. You need 90 minutes, a free analytics tool, and four numbers. Mixpanel, Amplitude, and Heap all ship a free tier in 2026 that handles up to 20K monthly events - enough for any product under 10,000 users. Pick one. PostHog is the open-source option if you prefer self-host.
+
+### Step 2 - wire three events (30 minutes)
+
+Three events: `signup_completed`, `core_action_completed` (define the one thing your product is for - send first invoice, schedule first job, run first import), `returned_after_signup` (any session 7+ days after signup). Pipe them in via the snippet your team or your no-code tool already has. If you are on Lovable, Bubble, or Webflow, the integration is a copy-paste API key.
+
+### Step 3 - answer the four questions
+
+The cohort tool already groups users by signup week, so this is a matter of reading the table.
+
+1. **Of users who signed up in the last 90 days, what percent completed `core_action_completed` within 7 days?** This is your activation rate. Industry floor for SaaS is 40%; under 25% means your onboarding fails before the user gets to the value moment.
+2. **Of those activated users, what percent triggered `returned_after_signup` within 14 days?** This is your week-2 return rate. Anything under 30% is a 7-day novelty product, not a habitual one.
+3. **Of those week-2 returners, what percent are still active at day 30?** This is your 30-day retention. Sean Ellis-style must-have products land at 60-80%; struggling products land at 8-15%.
+4. **Slice question 3 by segment.** Job title from your signup form. Company size from your signup form. Use case from a single-question post-onboarding survey. One segment will retain dramatically higher than the rest. That segment is the answer to the triage question.
+
+A B2B founder with a $29/month tool I worked with last quarter ran this in 70 minutes flat. Her overall 30-day retention was 19%. Solid not-a-business numbers. Sliced by segment: 3-person teams 71%, freelancers 12%, solo founders 8%. The average hid the only real customer she had.
+
+### Cohort retention by segment - one product, four shapes
+
+The 40% line is Sean Ellis's must-have threshold; cohorts that finish day 30 above it are habitual, below it are novelty.
+
+| Cohort | Day 7 → Day 30 retention | Verdict |
+|---|---|---|
+| 3-person teams | 88% → **70%** | Above must-have line - your real customer |
+| Small agencies | 75% → 32% | Borderline - could lift with workflow fix |
+| Freelancers | 58% → 12% | Wrong audience - below must-have |
+| Solo founders | 40% → **8%** | Wrong audience - refund and redirect |
+
+Same product, two answers. The 3-person team segment is the customer; the other three were the wrong audience the ads were buying.
+
+Print the [Churn Triage Worksheet](/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/) (in the operating kit) before you start. One A4 page: the four numbers, the segment slice, and the triage decision box. If you are filling it in on a screen, you are stalling.
+
+The trade-off worth naming: a 90-minute cohort analysis on 32 users is directional, not statistically significant. You will not pass a peer review. You will get a clear-enough picture to make a triage decision before another month of ad spend. That is the point.
+
+## The 3-Decision Triage
+
+The cohort numbers route you to one of three decisions. There is no fourth option. "Keep running ads" is not a fourth option; it is the option you took before reading this chapter, and the bucket numbers tell you how that ends.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    A[Cohort numbers from the 90-minute floor] --> B{Per-segment 30-day retention spread?}
+    B -->|All segments under 25%
and roughly the same| C[Decision 3 - KILL THE SKU
Sunset gracefully + pivot]
+    B -->|All segments around 20-35%
and roughly the same| D[Decision 1 - FIX THE PRODUCT
Rebuild one workflow]
+    B -->|One segment over 50%
others under 20%| E[Decision 2 - CHANGE THE SEGMENT
Refund the wrong half]
+    C --> CK[Go to chapter 7.6
Pivot or Persevere]
+    D --> DK[Go to chapter 8 / 9
When things break]
+    E --> EK[Re-run Module 5 outreach
aimed at the right segment]
+
+    classDef redbox fill:#fff5f5,stroke:#cc342d,stroke-width:2px;
+    classDef yellowbox fill:#fff8e0,stroke:#b8860b,stroke-width:2px;
+    classDef purplebox fill:#fbe9ff,stroke:#a855f7,stroke-width:2px;
+    classDef greenbox fill:#f0f9f0,stroke:#2e7d32,stroke-width:2px;
+    class C redbox
+    class D yellowbox
+    class E purplebox
+    class CK,DK,EK greenbox
+```
+
+### Decision 1 - FIX THE PRODUCT
+
+Cohort retention is uniform across segments but stuck around 20-35%. Nobody is having a great time. The product genuinely does not deliver the must-have job for anyone yet. The Q3 verbatims from your [must-have segment test](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/) will read hedged ("it is OK", "I would use it more if it had X").
+
+The fix is to stop adding features and rebuild one workflow until it actually works. Pick the workflow that the highest-retaining cohort describes as the reason they came back. Ship that workflow rebuilt in 4-6 weeks. Re-run the cohort. If retention bumps to 40%+ in the must-have segment, you have a product. If it does not, you are in Decision 3 territory.
+
+### Decision 2 - CHANGE THE SEGMENT
+
+One segment retains at 50%+ while others languish under 20%. The product works; the audience is wrong. R.'s case from the opening was Decision 2 - 71% retention for 3-person teams, 8% for solo founders, two-thirds of her customers paying for a product that did not fit their job.
+
+The fix has two parts. First, fire the wrong segment - refund their last 30 days, recommend an alternative tool, and remove them from the customer list. Second, double down on the right segment - rewrite the landing page headline for 3-person teams, redirect ad spend to that audience, and re-run [Chapter 5.2 personal-network outreach](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/) within the segment that retains.
+
+R. did this on a Friday afternoon. By the following Friday she had 11 paying customers (the right ones) and a refund tab of $5,800 (the wrong ones). Her net month-end customer count went from 35 to 11, and her churn rate dropped from 65% to 14% the next 30 days. Fewer customers, less revenue, but a real business instead of a leaking one.
+
+### Decision 3 - KILL THE SKU
+
+No segment retains above 25%. You have a feature, not a product. The pain is real but your build does not relieve it - users try it once, do not see the value, and never come back regardless of who they are.
+
+This is the hardest decision because it feels like quitting. It is not quitting; it is recovering the runway you would otherwise burn proving the same thing for another two months. Sunset the SKU. Refund the active subscribers (Stripe handles this in two API calls; your support inbox handles the rest). Move the operating decision to [chapter 7.6 Pivot or Persevere](/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/), which walks the six pivot types and the trigger conditions. The cohort data you collected in the 90-minute floor is the strongest single piece of evidence you will hand into the pivot decision.
+
+The most common founder failure mode at this triage step is to refuse to pick. The cohort data says Decision 2; the founder spends six more weeks "trying to lift the solo segment retention" because saying goodbye to two-thirds of paying customers feels worse than burning $4,800/month. Six weeks later the metrics are unchanged and the runway is shorter. The triage works only if you commit to the decision in the same week you ran the cohort.
+
+## The Refund-the-Wrong-Segment Script
+
+Decision 2 is the hardest to execute because it requires telling 18 of your 30 paying customers, in writing, that you built the wrong product for their situation. The default response is to flinch at this step. They run an "improvement campaign" instead, hoping the wrong segment will start retaining if the product gets a few more features. It will not. The wrong segment never converts to the right segment.
+
+Refunds are cheaper than churn. If a wrong-segment user churns at month 2, you have collected $58 and lost $200 in CAC and ~$25 in support time - net negative. If you proactively refund their last 30 days at month 2, you have lost $58 plus the same $200 CAC, but you have gained a goodwill quote, a clean Stripe ledger, and 20 minutes of support time you would otherwise spend explaining why the product feels off. The math on a wrong-segment refund campaign is positive against the alternative of waiting for churn.
+
+Here is the email template that worked for R.'s 18 wrong-segment customers. Send it from your founder address (`founder@product.com`), not from the support queue. Send it on a Tuesday or Wednesday morning - never Friday afternoon, when refunds get parsed as bad news.
+
+> Subject: Refunding your last 30 days, and a recommendation
+>
+> Hi [first name],
+>
+> I am writing to tell you something I should have figured out earlier. We built [product] as a workflow tool for 3-person teams to share invoice tracking. Looking at how you have been using it - mostly solo, a few times a week - I do not think we built the right product for your situation. The features that make this useful (shared comments, the team activity feed, the assignee column) are not the features you came here for.
+>
+> I am refunding the last 30 days to your card. You should see the credit in 3-5 business days. You can keep using the account through the end of the month if you want; after that I am going to suggest you look at [specific alternative tool], which is built for solo invoice tracking and is one-third the price.
+>
+> No pitch, no follow-up. If we ever build a solo version (we are not planning to), I will email you first.
+>
+> Thanks for trying us out and for the 6 weeks of payments.
+>
+> [your name]
+
+The script does three things at once. It admits the misfit in the founder's voice (not a support template). It hands the user a concrete alternative (so they do not have to start the search over). It removes the future-pitch hook (which is the part wrong-segment users actually appreciate). R.'s response rate to this email was 14 of 18 sent - 11 thank-yous, 2 questions about the alternative tool, 1 angry user, 0 chargebacks. The 1 angry user wanted to keep using the product anyway; she comped them a year and removed their seat from the team metrics.
+
+The honest trade-off: a refund-the-wrong-segment campaign cuts your customer count and your MRR in the short term. R.'s MRR went from $928 to $319 the week she sent the emails. By month 3 she was back above $928 with the right segment, with churn at 11% instead of 65%. The instinct is to flinch and not let the MRR number drop in week 1; the founders who hold the line are the ones who get out of the leaky-bucket cycle.
+
+## Hand This to the Next Chapter
+
+You walk out of this chapter holding one of three artifacts: a fix-the-product plan with a 4-6 week ship date, a change-the-segment plan with a refund script and a redirected outreach motion, or a kill-the-SKU verdict pointing toward a pivot decision. Pick the next move from your verdict and re-run the cohort floor every 6 weeks until the bucket stops leaking.
+
+1. **If Decision 1 (FIX THE PRODUCT):** open the [salvage-vs-rebuild decision framework](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/) and feed it the cohort data. Use the same numbers in the brief to whoever rebuilds the workflow - dev shop, fractional CTO, or AI tooling - so they know which workflow to rebuild and which to leave alone.
+2. **If Decision 2 (CHANGE THE SEGMENT):** re-run [Chapter 5.2 - personal-network outreach](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/) aimed at the high-retention segment. R.'s 11 kept customers seeded her next outreach run - she asked each for two intros to similar 3-person teams and landed 7 paid pilots in 3 weeks. Your cohort data ("we have 11 customers who look like you and they retain at 70%") is the warmest possible referral.
+3. **If Decision 3 (KILL THE SKU):** open [chapter 7.6 - Pivot or Persevere](/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/). The cohort floor numbers are the evidence the pivot framework asks for - four cohorts saying the same thing, not a hunch.
+
+## Further reading
+
+- Sean Ellis and Morgan Brown, [*Hacking Growth*](https://hackinggrowth.org/) - the cohort-and-segment-driven north-star approach Ellis used at Dropbox and LogMeIn.
+- Lenny Rachitsky, [The Sean Ellis test for product-market fit](https://www.lennysnewsletter.com/p/the-sean-ellis-test-for-product-market) - the must-have-user framing the segment slice in this chapter operationalizes.
+- ProfitWell (Patrick Campbell), [The Hidden Cost of High Churn](https://www.profitwell.com/recur/all/cost-of-churn) - the unit-economics math that explains why refunds beat churn for wrong-segment customers.
+- Rahul Vohra, [How Superhuman built an engine to find product-market fit](https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit/) - segment-isolation playbook layered on top of the 40% test.
+- Kieran Flanagan and Scott Tousley, [B2B SaaS retention benchmarks 2025](https://www.lennysnewsletter.com/p/b2b-saas-retention-benchmarks) - the 30-day-retention floors used in the 90-minute cohort questions.
+- Steve Blank, [The Customer Development Manifesto](https://steveblank.com/2010/01/25/the-customer-development-manifesto-reasons-for-the-revolution-part-1/) - the foundational framing for "fire the wrong customer before adding more."
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/cover.png b/content/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/cover.png
new file mode 100644
index 000000000..b8f05a9ea
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/index.md b/content/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/index.md
new file mode 100644
index 000000000..d09dd2a80
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/index.md
@@ -0,0 +1,160 @@
+---
+title: "6.2 · The Org Chart Your Dev Shop Won't Draw"
+aliases: ["/blog/engineering-org-chart-non-technical-founder/"]
+description: "The 5-person team your agency pitched is rarely the team writing your code. Six questions to surface who actually ships, who reviews, and who is on-call."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: engineering-org-chart-non-technical-founder
+keywords:
+  - engineering team structure for founders
+  - dev shop team size
+  - who reviews pull requests
+  - engineering team org chart
+  - fractional CTO
+tags:
+  - founders
+  - non-technical-founder
+  - tech-literacy
+  - dev-shop-management
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "6.2 · The Org Chart Your Dev Shop Won't Draw"
+  og_description: "The 5-person team your agency pitched is rarely the team writing your code. Six questions to surface who actually ships, who reviews, and who is on-call."
+cover_image_alt: "JetThoughts blog cover showing a redacted org chart with question marks over four boxes and one named senior reviewer"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/"
+related_posts: false
+course_nav: false
+---
+
+> **Chapter 5.2 · Step 1 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a team in place + a signed SOW
+>
+> **Output:** a weekly oversight rhythm running by month 3
+>
+**Supplementary content.** This chapter assumes you have a hired team. If you're still on the [self-serve path](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/), bookmark this and return when you graduate to a hired team.
+>
+> **Read this if**: you've signed an SOW with a dev shop OR you're paying for "a team of N" without seeing the GitHub handles of who reviews your PRs each week.
+
+Marina, a FinTech founder we picked up in Q1 2026, had been billing **$44K a month for "a team of four."** Three months in, her new fractional CTO asked who had written the last twelve pull requests. The answer: one senior reviewer who signed off most weeks, two mid-level shippers, and three rotating juniors paid by a sub-contracted shop she had never heard of. She had been paying senior rates for code one junior wrote and another junior reviewed.
+
+The agency had not lied, exactly. The kickoff deck just did not say which names touched the repo on which weeks, who reviewed whose pull requests, or who picked up the phone at 2am when production was down.
+
+## What an org chart hides
+
+The vibe-coding wave made the org chart even fuzzier. Agencies that pitch "AI-augmented teams" route work through three layers: a senior who runs the demo, a mid-level who prompts Cursor or Claude Code, and a junior who reviews whatever falls out. The labor cost dropped; the bill rate did not. [TechTIQ Solutions' 2026 staff augmentation report](https://techtiqsolutions.com/it-staff-augmentation-cost-breakdown-and-pricing-models/) flags that hidden costs add 15-30% on top of base rates, with 10-18% already going to vendor margin. The shops we rescue in 2026 are charging the same and paying less, with the gap going to subcontracted juniors and AI tooling the founder never approved as a line item.
+
+**What the kickoff deck said vs who actually shipped your PRs:**
+
+| Slot on the slide | Kickoff deck (what you bought) | Reality on the PRs (what you got) |
+|-------------------|-------------------------------|-----------------------------------|
+| 1 | Senior Dev / Tech Lead - "available for architecture calls" | Senior Dev - 1-2 days/week, 3 other clients, signs off most weeks |
+| 2 | Mid-level Engineer - "daily shipper" | Mid Engineer - full-time, writes 60% of code |
+| 3 | Mid-level Engineer - "daily shipper" | Mid Engineer - part-time, writes 30% of code, on another client most weeks |
+| 4 | Junior Engineer - "in mentorship" | Subcontracted Junior #1 - from a partner shop you never met |
+| 5 | PM (1/4 allocation) - "runs your standups" | Subcontracted Juniors #2, #3 - rotating, AI-augmented, no Slack handle in your repo |
+| **Bill rate** | **$44K / month** | Same. Senior rate paid, junior work delivered |
+
+Same five seats. Different five humans. Ask the six questions below to learn which side of this chart you're on.
+
+## The five-person team your shop pitched
+
+The kickoff deck almost always shows a tidy stack. From the top:
+
+- **One senior dev or "tech lead."** Usually the salesperson on calls. Strong on architecture conversations, weak on weekly availability. Their actual job is to win the next contract.
+- **One or two mid-level engineers.** The daily shippers. They write most of the code that ends up in your repo and run the standup when the lead is busy on another pitch.
+- **One or two juniors.** Often AI-augmented now. In a healthy shop they are paired with the mid-levels and grow into them. In an unhealthy shop they ship straight to your main branch with one rubber-stamp review.
+- **A quarter of a project manager.** Shared across three or four projects. Their Slack is yours on Mondays and Wednesdays, gone the rest of the week.
+- **A tenth of a CTO.** The founder of the agency, "available for escalation," which means available if you escalate loudly enough.
+
+That is a 4.35-person team on the spreadsheet, billed as five. The Rails version works when the senior actually reviews - she catches the `before_action` that bypasses auth, the missing Sidekiq retry, the migration that locks the orders table. It collapses when the senior is on three other projects and the juniors are reviewing each other. [Our MVP team-structure note](/blog/our-mvp-team-structure-startup-management/) describes the alternative: two full-stack developers and one frontend, with a product owner in your meetings, not three others'.
+
+## The questions that surface the real org chart
+
+These six questions belong in your next status call. Ask them in this order. Watch which ones the team answers fast and which ones get a "let me get back to you."
+
+### 1. "Who specifically reviewed the last five pull requests on my repo? Name them."
+
+A healthy answer names two or three humans whose handles you can find in GitHub. A failing answer is a role ("the senior team"). One reviewer for all five means single point of failure; five different reviewers means no consistent owner. [Will Larson at Carta](https://review.firstround.com/unexpected-anti-patterns-for-engineering-leaders-lessons-from-stripe-uber-carta/) treats the pull request funnel as the load-bearing signal for engineering health. Founders should too.
+
+### 2. "How many other clients does that reviewer have this week?"
+
+A senior carrying three other projects gives your PRs about fifteen minutes each. That is enough to skim a diff and click approve. It is not enough to catch the auth regression or the N+1 query in the dashboard endpoint. JT's [60-day playbook for slow teams](/blog/fixing-slow-engineering-teams-an-extended/) starts by figuring out where the senior's attention actually is.
+
+![PR reviewer attention math: senior's week split across 4 clients at 25% each leaves 10 hours on your repo, divided by ~40 PRs per week, equals 15 minutes per PR; what 15 minutes catches versus what it misses including auth regressions, N+1 queries, hardcoded Stripe secrets, dropped test coverage, and locking migrations](reviewer-attention.svg)
+
+### 3. "Is anyone on my project subcontracted - paid by you but employed elsewhere?"
+
+Ask flat. Watch the pause. [DataToBiz describes the practice plainly](https://www.datatobiz.com/blog/subcontracting-in-it-staff-augmentation/): the agency you signed with can route work through a partner shop you never met. Subcontracting is not automatically bad - the question is whether you knew. If your contract does not say "no subcontracting without written approval," it can happen and probably is.
+
+### 4. "Who is on-call if production breaks at midnight, and what is the handoff?"
+
+A shop with a real on-call rotation can tell you the schedule, the escalation path, and the SLA in under a minute. Without one, you get "best effort" coverage - which means your senior sees the Sentry email when she opens her laptop on Monday. [Team Coherence on code ownership and accountability](https://www.teamcoherence.com/code-ownership-and-accountability/) makes the point: ownership without a named person is not ownership. JT's [remote team accountability writeup](/blog/remote-team-accountability-non-technical-founders/) covers the same ground in plain English.
+
+### 5. "If your senior reviewer quits Friday, who replaces them on my project Monday?"
+
+A real answer names a person, their familiarity with your repo, and their existing client load. "We have bench depth" means the agency will scramble and you will pay for the scramble in slower velocity and missed reviews. This is the question covered in [our 15-minute engineering team health check](/blog/how-to-assess-engineering-team-health-15-minutes-non-technical-founder/).
+
+### 6. "Walk me through one PR from last week. Who wrote it, who reviewed it, what they checked."
+
+This catches what the first five missed. A team that ships well can replay a PR in a minute: "Marcos opened a 40-line change in the `OrdersController`, Priya pushed back on the missing test for the refund branch, Marcos added the test, she approved, CI went green, we merged at 3pm Wednesday." A team that does not ship well will describe a process instead of a transaction. JT's note on [small PRs as the unit of team productivity](/blog/how-small-pr-improves-team-productivity-development/) explains why the transaction is the trust signal; if your team cannot point at one, the unit does not exist.
+
+```mermaid
+
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#f5f5f5', 'primaryBorderColor':'#666', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+
+flowchart TD
+
+    Start(["Run on your next status call.
Six questions, in order."])
+    Start --> Q1{1. Who reviewed
the last 5 PRs?}
+    Q1 -->|Named humans| Q2{2. How many other
clients this week?}
+    Q1 -->|'the senior team'| F1[Single point of failure
or no clear owner]
+    Q2 -->|1-2| Q3{3. Anyone
subcontracted?}
+    Q2 -->|3+| F2[15 min per PR
= skim and approve]
+    Q3 -->|No, all in-house| Q4{4. On-call for
midnight outages?}
+    Q3 -->|Pause / 'sometimes'| F3[Hidden labor layer
at junior rate, senior bill]
+    Q4 -->|Named rotation + SLA| Q5{5. If senior quits Friday,
who replaces by Monday?}
+    Q4 -->|'best effort'| F4[Sentry hits Monday morning
not Tuesday at 3am]
+    Q5 -->|Named person, familiar| Q6{6. Walk me through
one PR from last week}
+    Q5 -->|'we have bench depth'| F5[You will pay for
the scramble]
+    Q6 -->|Replays in 60 sec| Pass[✓ Real org chart visible
Continue with team]
+    Q6 -->|Describes process,
not transaction| F6[Unit of trust missing]
+    F1 --> Audit[3+ flags fire
= time to audit your team
cross-check PRs, AWS bill, names on commits]
+    F2 --> Audit
+    F3 --> Audit
+    F4 --> Audit
+    F5 --> Audit
+    F6 --> Audit
+    classDef good fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef bad  fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a
+    classDef neutral fill:#f5f5f5,stroke:#666,stroke-width:2px,color:#1a1a1a
+    classDef start fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a
+    class Start start
+    class Q1,Q2,Q3,Q4,Q5,Q6 neutral
+    class Pass good
+    class F1,F2,F3,F4,F5,F6,Audit bad
+
+```
+
+## What to do tomorrow
+
+Email your agency tonight. One line: "Please send me the current org chart with names, roles, and FTE allocation for everyone touching my code this month. Include any subcontracted resources." Forward the response to your fractional CTO or developer-friend - if you do not have one, [our note on fractional CTO ROI](/blog/fractional-cto-vs-full-time-cto-complete-comparison-2025/) explains the shape. Cross-check against [our dev-shop red flags checklist](/blog/dev-shop-red-flags-checklist/) and the [non-technical founder checklist](/blog/checklist-for-non-tech-founder-agile/). If the reply has fewer named humans than the kickoff deck promised, the deck was the pitch and the reply is the truth.
+
+## When the org chart shows you've got a problem
+
+If the answers came back vague, contradictory, or missing, that is the signal. The fix is putting numbers next to the names before the next agency conversation: how many PRs each reviewer touched last month, how many days the senior was actually on your project, which juniors shipped which features. Cross-reference the [eight red flags checklist](/blog/dev-shop-red-flags-checklist/) and the [15-minute team-health assessment](/blog/how-to-assess-engineering-team-health-15-minutes-non-technical-founder/) to know what good looks like.
+
+## Further reading
+
+- DHH, [The One Person Framework](https://world.hey.com/dhh/the-one-person-framework-711e6318) - the Rails case for shipping with a small team.
+- DHH, [The Majestic Monolith](https://signalvnoise.com/svn3/the-majestic-monolith/) - why Basecamp ran on one codebase since 2003.
+- AWS Executive Insights, [Amazon's Two-Pizza Teams](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/) - Bezos' rule on team size and what it actually optimised for.
+- Jason Yip, [My critique of "the Spotify Model"](https://jchyip.medium.com/my-critique-of-the-spotify-model-part-1-197d335ef7af) - an ex-Spotify coach explaining what the model is and is not.
+- Agile Pain Relief, [The Spotify Model of Scaling - Spotify doesn't use it, neither should you](https://agilepainrelief.com/blog/the-spotify-model-of-scaling-spotify-doesnt-use-it-neither-should-you/) - the broader agile-community position on cargo-culted squad structures.
+- Will Larson (interviewed by First Round Review), [Engineering leadership anti-patterns from Stripe, Uber, Carta](https://review.firstround.com/unexpected-anti-patterns-for-engineering-leaders-lessons-from-stripe-uber-carta/) - on review processes and the PR funnel as the productivity signal.
+- TechTIQ Solutions, [IT Staff Augmentation Cost Breakdown 2026](https://techtiqsolutions.com/it-staff-augmentation-cost-breakdown-and-pricing-models/) - hidden costs of staff-augmented teams.
+- DataToBiz, [The Strategic Advantage of Subcontracting in IT Staff Augmentation](https://www.datatobiz.com/blog/subcontracting-in-it-staff-augmentation/) - plain description of the subcontracting layers founders rarely see.
diff --git a/content/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/reviewer-attention.svg b/content/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/reviewer-attention.svg
new file mode 100644
index 000000000..ecbb99715
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/reviewer-attention.svg
@@ -0,0 +1,61 @@
+
+  PR reviewer attention math: 4 projects, 15 minutes per PR, what gets missed
+  
+    
+  
+
+  Your senior reviewer's week, by project
+
+  Mon
+  Tue
+  Wed
+  Thu
+  Fri
+
+  
+  Client A · 25%
+
+  
+  Client B · 25%
+
+  
+  YOUR PROJECT · 25%
+
+  
+  Client D · 25%
+
+  10 hours/week on your repo  ÷  ~40 PRs/week  =
+  15 minutes per PR
+
+  What 15 minutes catches vs what it misses:
+
+  
+  ✓ Diff looks reasonable
+  ✓ CI passed green
+  ✓ Style nits flagged
+  ✓ Click approve
+
+  
+  ✗ Auth regression in before_action
+  ✗ N+1 query in dashboard endpoint
+  ✗ Stripe webhook secret in controller
+  ✗ Test coverage silently dropped 11%
+  ✗ Migration that locks orders table
+
+  
+  
+
+  "We trust the senior to catch issues" - the senior had 15 minutes and three other clients.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/fake-stripe-pre-sale-pieter-levels/cover.png b/content/course/tech-for-non-technical-founders-2026/fake-stripe-pre-sale-pieter-levels/cover.png
new file mode 100644
index 000000000..336cd5b80
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/fake-stripe-pre-sale-pieter-levels/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/fake-stripe-pre-sale-pieter-levels/index.md b/content/course/tech-for-non-technical-founders-2026/fake-stripe-pre-sale-pieter-levels/index.md
new file mode 100644
index 000000000..370d2f9f1
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/fake-stripe-pre-sale-pieter-levels/index.md
@@ -0,0 +1,95 @@
+---
+title: "Fake-Stripe Pre-Sale: The Pieter Levels Pre-Order Smoke Test"
+description: "When a $1 refundable Stripe charge is a stronger demand signal than an email signup. The pre-sale variant of the smoke test, with refund + FTC compliance notes."
+date: 2026-05-23
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: fake-stripe-pre-sale-pieter-levels
+keywords:
+  - fake stripe presale
+  - pieter levels presale
+  - pre-order smoke test
+  - dollar intent vs email signup
+  - $1 refundable validation
+tags:
+  - founders
+  - non-technical-founder
+  - smoke-test
+  - course-companion
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "Fake-Stripe Pre-Sale: The Pieter Levels Pre-Order Smoke Test"
+  og_description: "When a $1 refundable Stripe charge is a stronger demand signal than an email signup. The pre-sale variant of the smoke test, with refund + FTC compliance notes."
+cover_image_alt: "JetThoughts companion cover for the fake-Stripe pre-sale: a landing page with a 'Reserve $1 refundable' button flowing into a Stripe $1.00 charge panel with an auto-refund indicator, beside Pieter Levels' 0 / 1-10 / 50+ outcome tiers"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/fake-stripe-pre-sale-pieter-levels/"
+related_posts: false
+---
+
+The default [smoke test](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) captures email addresses. The Pieter Levels variant captures dollars instead - a real $1 refundable Stripe charge as the CTA, before the product exists.
+
+This page is the companion writeup for that variant. Use it when an email-only signal isn't strong enough to commit to a build.
+
+## Email signup vs $1 refundable charge
+
+A waitlist captures curiosity (a free email costs the visitor nothing). A $1 charge captures a wallet decision. The same 100 visitors who would cheerfully give you an email might generate zero payment clicks - and that zero is the validated demand signal you actually need.
+
+The conversion rate drops 3-5x compared to the email-only version. That is the point. The remaining converters are real demand, not curious clickers.
+
+## When to use this instead of email-only
+
+- You ran the email-only smoke test and the signal was strong (>10% conversion); now you want to upgrade to dollar intent before you build.
+- Your hypothesis price is high enough ($50+) that the wallet decision is a meaningful gate.
+- You're on your second or third hypothesis and need a sharper signal than email curiosity provides.
+
+If you're running your first ever smoke test, use [the email-only version](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) - it's faster to set up, and the refund + FTC discipline below adds real overhead.
+
+## The setup (15 minutes)
+
+The Stripe Payment Link mechanic is the same as in [Chapter 1.3 (Price Your Hypothesis on the Smoke-Test Page)](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/) - read that for the full setup walkthrough. The variant-specific changes:
+
+1. **CTA copy.** Replace "Get on the waitlist" with **"Reserve your spot ($1 today, refundable if we don't ship by [date])"**. The "$1 today" + "refundable" combination is the load-bearing phrase.
+2. **Thank-you page.** "You're reserved. We'll email you when we ship. Your $1 is fully refundable - just reply to this email and ask."
+3. **Footer disclosure.** A one-line "About this pre-order: we are testing demand for [product]. If we don't ship by [date], you get an automatic refund. Your $1 charge appears as JTHOUGHTS-RESERVE on your statement."
+4. **Stripe metadata.** Set the product name to your hypothesis title + "(pre-order)". This shows up on the customer's bank statement and on the refund record.
+
+## Refund discipline (non-negotiable)
+
+If the test fails (you don't ship), you refund every $1 charge **automatically** within 30 days. Two reasons:
+
+- **Ethics.** People gave you real money for a product that doesn't exist. The refund is the implicit contract.
+- **FTC compliance.** US FTC pre-order rules require you to ship within 30 days of the charge unless you disclose the delay in writing AND get the buyer's consent. The blanket "refund if we don't ship by [date]" disclosure on the landing page + thank-you page covers this for the smoke-test window.
+
+Set a calendar reminder for Day 25 of the test window. If you haven't started the build by then, log into Stripe and refund all charges in one batch (Dashboard > Payments > select all > Refund). Takes 5 minutes.
+
+## Reading the result (Levels' 70-product tiers)
+
+Based on Pieter Levels' [70-product startups portfolio](https://levels.io/startups/) - a decade of running this exact test:
+
+| Pre-sale count from a typical traffic spend | What it means | Next move |
+|---|---|---|
+| **0 sales** | Hypothesis or price is wrong | Invalidate; rewrite the [hypothesis sentence](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) or the price point |
+| **1-10 sales** | Hypothesis directionally right; headline or audience wrong | Iterate headline + ad targeting; re-run for one more week |
+| **50+ sales** | Product-market-fit signal in range | Move to [customer interviews](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) and [The One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) in parallel; start building |
+
+## What this test does NOT prove
+
+The fake-pre-sale signal tells you the headline + price + audience combination converts at the moment of decision. It does NOT tell you:
+
+- Whether the product will retain users once shipped (that's [Chapter 5.1, the Sean Ellis 40% test](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/)).
+- Whether the unit economics work at full price (that's a follow-on test post-launch).
+- Whether the people who pre-ordered will actually use the product (that's interview-stage research - [Chapter 2.1, The Mom Test](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/)).
+
+The pre-sale is the strongest pre-build demand signal you can buy. It is not validation that you have a business.
+
+## Further reading
+
+- Pieter Levels, [the 70-product startups portfolio](https://levels.io/startups/) - this technique in operation across a decade of indie launches.
+- [Chapter 1.2b (the standard smoke test - run-it phase)](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) and [Chapter 1.2a (build the page)](/course/tech-for-non-technical-founders-2026/smoke-test-build-landing-page/) - the email-only version this page upgrades.
+- [Chapter 1.3 (Price Your Hypothesis on the Smoke-Test Page)](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/) - the full Stripe Payment Link setup walkthrough.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/faq/index.md b/content/course/tech-for-non-technical-founders-2026/faq/index.md
new file mode 100644
index 000000000..b43b34968
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/faq/index.md
@@ -0,0 +1,134 @@
+---
+title: "FAQ - From Idea to First Paying Customer"
+aliases: ["/blog/faq-tech-for-non-technical-founders/"]
+description: "Common blockers and questions from founders working through the course. Stuck? Start here before you ask for help."
+date: 2026-06-07
+draft: false
+course_chapter: false
+author: "JetThoughts Team"
+slug: faq
+keywords:
+  - tech for non technical founders faq
+  - founder course help
+  - stuck founder course
+  - startup validation questions
+tags:
+  - founders
+  - non-technical-founder
+  - course-faq
+categories: ["Founders"]
+metatags:
+  image: cover.png
+  og_title: "FAQ - From Idea to First Paying Customer"
+  og_description: "Common blockers and questions from founders working through the course. Stuck? Start here."
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/faq/"
+related_posts: false
+---
+
+> **FAQ** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+
+If you're stuck, start here. These are the questions founders ask most often - read the 2-3 that match your situation and get back to the build. If your question isn't here, try the course's [Quickstart path](/course/tech-for-non-technical-founders-2026/quickstart/) or the [How This Course Works](/course/tech-for-non-technical-founders-2026/how-this-course-works/) overview.
+
+---
+
+## Module 1 - Hypothesis & Smoke Test
+
+**Q: My hypothesis sentence still sounds vague after 3 drafts. What now?**
+
+Write it at the specificity level of "solo chiropractors in Pennsylvania who spend 30 minutes re-entering insurance claim codes from a PDF every Tuesday." Not "healthcare professionals who want to save time." If you can't name the industry, the company size, and the specific 30-minute moment, you're not there yet. Go back to [Ch 1.1](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) and fill each blank with a real person in mind.
+
+**Q: My landing page got zero signups from 300 visitors. Is the idea dead?**
+
+Maybe. Below 1% conversion on cold traffic is a strong negative signal. But first: check your tracking. Did you install Microsoft Clarity? Watch 10 session replays. Common failure modes: the form is broken, the page takes 5+ seconds to load on mobile, or your headline is too vague. Fix those and re-run before you kill the idea. The [smoke test chapter](/course/tech-for-non-technical-founders-2026/smoke-test-build-landing-page/) has the 6-element checklist.
+
+**Q: My Stripe account verification is taking 3+ days. Can I skip the price button?**
+
+Don't skip - sign up for Stripe tonight and let it verify in the background while you build the landing page. Verification takes 1-3 business days. If you wait until launch day to create the account, you block on a wait you could have run in parallel. If it's already been 3+ days, check your email for a Stripe support message asking for business documents.
+
+**Q: Which landing page builder should I use?**
+
+Mixo ($7/mo, 30 seconds from idea to page). If the templates don't fit, Manus AI (free tier, no card). Don't comparison-shop for a week - you're testing demand, not builders. The [Ch 1.2a builder section](/course/tech-for-non-technical-founders-2026/smoke-test-build-landing-page/#pick-your-builder) has the full list.
+
+---
+
+## Module 2 - Validate the Problem
+
+**Q: I can't find anyone to interview. I've searched everywhere.**
+
+Two fixes: (1) Your hypothesis is too vague - "small business owners" is not a searchable ICP. Tighten to "12-person law-firm office manager." (2) Search second-degree keywords: "boarding costs" instead of "pet sitter." The [Ch 2.3a chapter](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) has the AI prompt that generates 8 communities + 5 search strings from your hypothesis.
+
+**Q: Everyone I interview says "sounds great" but nobody gives me real data.**
+
+Your questions are probably hypothetical-shaped. "Would you use a tool like this?" generates polite yeses from anyone. Switch to past-tense: "When was the last time you dealt with [problem]? Walk me through what happened." The [Mom Test chapter](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) has the 5-question template that fixes this.
+
+**Q: Should I skip the AI persona rehearsal (Ch 2.2)?**
+
+If you've run customer interviews before and your questions reliably produce concrete past-tense answers, skip it - go straight to [Ch 2.3a](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/). If this is your first time running Mom Test interviews, the 90-minute rehearsal catches broken question shapes before they waste real interview slots.
+
+**Q: All my Mom Test scores are below 7 out of 10. What does that mean?**
+
+Directional KILL. Less than 7 of 10 interviewees have spent real time or money on the problem - the problem isn't acute enough to build for. Before you pivot, check: are you interviewing the right ICP? If you interviewed 10 chiropractors and the problem isn't real for them, but 3 mentioned a related problem they DO care about, build a new hypothesis around that problem and re-validate.
+
+---
+
+## Module 3 - Design from Evidence
+
+**Q: My Product Brief keeps growing beyond one page. How do I cut it?**
+
+If a feature in Section 3 doesn't trace back to a verbatim quote from a Module 2 interview, cut it. If you can't name which interviewee said they needed it, it's your feature, not theirs. The [Ch 3.2 chapter](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/) has the quality-gate that catches scope creep before you open Lovable.
+
+**Q: Claude keeps naming features that aren't on my no-go list. My brief keeps failing.**
+
+Your Section 3 is too vague. Rewrite every feature as a "When / I want / So I can" job story. "CSV export" becomes "When I prepare the weekly investor report, I want to grab the top 5 metrics in 30 seconds, so I can paste them into the deck before the 4pm call." The engineer has nothing left to invent.
+
+---
+
+## Module 4 - Build It Yourself
+
+**Q: I don't know whether to hire or build myself.**
+
+Run the [Ch 4.1 decision tree](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/). The default answer for a first-time solo founder with a validated brief: build it yourself with Lovable + Supabase + Stripe. Hiring triggers when you hit a [Ch 4.4 ceiling signal](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) - not before.
+
+**Q: The 12 rules checklist is overwhelming. Where do I even start?**
+
+Only 3 rules need to be true before you open Lovable: (1) your one-page brief passed the Ch 3.2 quality-gate, (2) you scoped one workflow for one persona, (3) GitHub sync is on in Lovable Settings. The other 9 rules fire inline during the build. Read the [Ch 4.3a chapter](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) for the full list.
+
+**Q: Lovable generated a 47-button admin panel from my one-page brief.**
+
+Your brief's Section 3 is feature-shaped. Go back to [Ch 3.2](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/) and rewrite every feature as a "When / I want / So I can" outcome before you re-prompt Lovable. Then use the AI critic block in [Ch 4.3a](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) to audit your build against your brief.
+
+---
+
+## Module 5 - First Paying Customer
+
+**Q: I'm terrified of asking for money. How do I start?**
+
+The deposit is a test of whether the problem is real - not a test of whether you deserve to be paid. Send the [DPA template](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/#dpa-template) to your warmest lead first. A refundable deposit at kickoff is easier to ask for than a full-price sale. The [Ch 5.4 chapter](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) has the exact contract template.
+
+**Q: My personal network only has 5 names. What do I do?**
+
+Five is enough to start. Message all five before you try cold outbound. The warm-network motion closes at 30-50% conversion; cold outbound closes at 3-5%. Three pilots from five warm leads is a better outcome than one pilot from 30 cold emails. If your network truly has zero applicable names, skip to [Ch 5.5 cold outbound](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/).
+
+**Q: The customer wants to start free and convert later. Should I accept?**
+
+No. A verbal yes is not a paid pilot. Reframe: the deposit is year-one ACV prepaid, not added cost. If they still say no, their problem isn't acute enough - they're not in your must-have segment. Move to the next lead.
+
+---
+
+## General
+
+**Q: How long does the full course take?**
+
+A full-time founder with daytime availability can complete all 5 modules in 6-10 weeks. An evening-only founder (2-4 hrs/week, the pattern this course is built for) typically needs 10-16 weeks. The [Quickstart](/course/tech-for-non-technical-founders-2026/quickstart/) is the shortest possible path - core lessons only.
+
+**Q: Do I need to do the modules in order?**
+
+Yes. Each module's output is the next module's input. The hypothesis you write in Module 1 feeds the landing page. The interviews you run in Module 2 feed the Product Brief. The brief you write in Module 3 feeds the Lovable build. Skip a module and the input to the next one is missing.
+
+**Q: I already have a half-built MVP. Where do I start?**
+
+If you validated the problem (10+ customer interviews), start at [Module 3 - Design from Evidence](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/). If you never validated, start at [Module 1](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/). The half-built MVP might be solving a problem nobody has - better to find out now than after launch.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/cover.png b/content/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/cover.png
new file mode 100644
index 000000000..06719ed14
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/index.md b/content/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/index.md
new file mode 100644
index 000000000..77255a2aa
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/index.md
@@ -0,0 +1,223 @@
+---
+title: "2.3a · Find 10 People: Where to Look"
+aliases: ["/blog/find-10-people-where-to-look/"]
+description: "Where to find 10 people who actually have your validated problem. AI translates your hypothesis into an ICP map, you read where they post, you build a 30-name list from people you can name."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: find-10-people-where-to-look
+keywords:
+  - find customers to interview 2026
+  - non technical founder outreach
+  - icp mapping ai
+  - reddit customer research
+  - validation outreach strategy
+tags:
+  - founders
+  - non-technical-founder
+  - customer-research
+  - validation
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "2.3a · Find 10 People: Where to Look"
+  og_description: "Where to find 10 people who actually have your validated problem. AI translates your hypothesis into an ICP map, you read where they post, you build a 30-name list."
+cover_image_alt: "JetThoughts cover showing the 5-step outreach funnel from Reddit mining at the top down to 10 calls booked at the bottom"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/"
+related_posts: false
+---
+
+> **Module 2 · Step 3a of 4** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a hypothesis you suspect is real (from Ch 1.1) + a sharpened Mom Test question list (built in Ch 2.1, polished in Ch 2.2)
+>
+> **Output:** a 30-name list of specific people you can name because you read what they wrote, ready for the outreach templates in [Ch 2.3b](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/)
+
+> **TL;DR (Part 1 of 2):** Paste your three-sentence hypothesis into Claude, get back the ICP (Ideal Customer Profile - the specific kind of person your hypothesis names; introduced in Ch 1.1) profile + exact communities + search strings. Read where your ICP is already complaining. Build a 30-name list. [Part 2: What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) covers the message templates, cadence, and follow-up sequence.
+
+Most non-technical founders start with the same move: "I'll just message my LinkedIn network." Sixty polite DMs over a week tend to produce 3 calls - two old colleagues showing up to be nice, one real lead who ghosts on reschedule.
+
+The technique below replaces that move with a different one: read where strangers are already complaining about your exact hypothesised problem, then write back to those specific complainers. Same hypothesis, same work hours, different place to look. The DM-the-network move books 2-3 polite calls. The read-where-they-already-complain move - half a day of reading threads, then 30 named outreach messages - produces a calendar of 10+ booked interviews.
+
+The full journey, top to bottom:
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    H(["Your 1-sentence hypothesis
(from Ch 1.1)"])
+    H --> S1[Step 1
Translate hypothesis → ICP map
Paste into Claude/ChatGPT]
+    S1 --> S2[Step 2
Read where they complain
Reddit/LinkedIn/forums]
+    S2 --> S3[Step 3
Build 30-name list
One name per real complaint]
+    S3 --> S4[Step 4
Write each one personally
Templates in Part 2]
+    S4 --> S5(["Step 5
10 interviews on calendar"])
+
+    classDef start fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a
+    classDef step fill:#fff5f5,stroke:#cc342d,stroke-width:2px,color:#1a1a1a
+    classDef end1 fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+
+    class H start
+    class S1,S2,S3,S4 step
+    class S5 end1
+```
+
+1. **Translate the hypothesis into an ICP map** - paste your three sentences and two competitor URLs into Claude or ChatGPT.
+2. **Read where they're already complaining** - work through the channels the AI proposed. Note 30 sentences in their real words.
+3. **Build a list of 30 specific people** from those threads.
+4. **Write to each one** using the templates in [Part 2](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/).
+5. **10 interview calls on the calendar.**
+
+> **Calendar reality + smoke-test gate before you start.** Full-time founder typically books 10 interviews across 2-4 calendar weeks; evening-only founder (2-4 hr/week) typically needs 6-8 calendar weeks - plan around the longer version. Your Ch 1.2 (a + b) smoke test should have cleared roughly 6%+ email conversion (the "Promising" band) or 5%+ Stripe-click on the Ch 1.3 price-button variant. 3-5% is the "iterate the message" zone, not a green light. Below 3% means you have a demand-side problem - go back to [Ch 1.1](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) and rewrite the weakest blank before booking interviews.
+
+This page covers steps 1-3. Part 2 covers steps 4-5.
+
+## Before you start: write three sentences
+
+Write three sentences in your own words before you open Reddit. Without them, every interview answer sounds encouraging and you can't tell which ones confirm the bet and which ones kill it:
+
+| Profile | What to write | Bad vs Good |
+|---------|---------------|------------|
+| **Customer (one sentence)** | *Who* is this person, in real-world detail? Role, company size, the moment in their week when the pain happens. | Bad: "small-business owners"
Good: "a 12-person law-firm office manager on Friday afternoon trying to invoice ten clients before Quickbooks logs her out" |
+| **Business (one sentence)** | What kind of business are *you* building? B2B SaaS, B2B services, B2C app, marketplace. Free or paid. Self-serve or sales-led. | Bad: "a SaaS tool"
Good: "B2B SaaS, self-serve, $29-49/month annual billing" |
+| **Solution (one sentence)** | Not a feature list - a sentence about the change. You won't pitch this in calls, but you need it written down to know which conversations confirm or kill it. | Bad: "a tool that automates invoicing"
Good: "I think a one-click invoice export to Stripe and Wave saves the office manager 90 minutes every Friday" |
+
+If you can't write all three on a single napkin, do that first. The deeper version of these three lines is the [one-page Product Brief in Chapter 3.1](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/).
+
+## How to find 10 people who actually have this problem
+
+You can do every part of this with a Reddit account, a Gmail address, and short daily blocks. AI does the heavy lifting that used to need a researcher; the rest is reading and writing.
+
+### Translate the hypothesis into an ICP map
+
+The 2026 shortcut: AI does the part that used to take a week of research. You hand it your three sentences plus two competitor URLs; it returns the ICP profile, the exact places those people post, and the search strings to find named individuals.
+
+Paste this prompt into Claude or ChatGPT:
+
+```text
+You are helping me find the first 10 customer interviews for a product I'm validating.
+
+My hypothesis (3 sentences):
+- Customer: [paste your customer sentence]
+- Business: [paste your business sentence]
+- Solution: [paste your solution sentence]
+
+Two competitors or adjacent products serving a similar customer:
+- [competitor 1 URL]
+- [competitor 2 URL]
+
+Return:
+1. A sharper ICP profile (role, industry, company size, the moment in their week when the pain happens, one quote in their language).
+2. 8 subreddits, Slack/Discord communities, and forums where this person posts. For each, give the community's topic focus, typical post frequency (e.g., "20 new posts/day" or "2-3 per week"), and 2-3 short keyword phrases that come up most often. Do NOT generate URLs - you cannot browse the web. I will verify the community myself with these inputs.
+3. 5 Google + LinkedIn search strings I can paste in today to find named people complaining about this problem (use `site:`, quotes, and `intext:` where helpful).
+4. 5 second-degree adjacent search terms I might miss (workarounds they use, related complaints, tool names they'd mention while frustrated).
+
+If you cannot describe a real community for any item, respond with "NOT FOUND - [item]" rather than guessing.
+```
+
+> No competitor URLs yet? If you ran the [naive Claude/ChatGPT prompt in Chapter 1.1](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) with the follow-up "name 3-5 competitors," you already have them. Otherwise: Google your problem in plain words plus `tool` or `software`, grab the top 2 results that aren't blog posts.
+
+What you get back: the channels you'll read next and the search strings you'll use to build the list. If a community the AI proposes turns out to be dead or off-topic, drop it and ask: `Suggest 3 alternatives more focused on [vertical].`
+
+If your hypothesis is consumer-facing, swap "Slack/Discord" for "TikTok hashtags, Instagram comments, YouTube comment threads, and product subreddits."
+
+### Read where they're already complaining
+
+Read before you write a single message. You're looking for the exact words people use when their problem flares up - those words become your subject lines when you write the cold messages in Part 2.
+
+**The simplest way:**
+
+1. Open one of the channels the AI proposed in the ICP map.
+2. In the search bar, paste the exact problem phrase in quotes (e.g. `"invoicing takes forever"`).
+3. Sort by Top → Past Month. Read the top 30 results.
+4. Open a Google Doc. Each time a complaint matches your hypothesis, copy the sentence verbatim - with the username and URL.
+5. Repeat for two more channels.
+
+When you're done you should have 30 real sentences and 30 named people. Don't paraphrase. The exact wording is the point.
+
+**Where to search (the AI gave you specifics; here are the common starting points):**
+
+- **Reddit** - subreddits in your vertical. Sort by Top → Past Month. The 1% willing to complain in public are usually willing to take a 20-minute call. Free tool [Keyworddit](https://keyworddit.com) surfaces the keywords a given subreddit is currently using, so you can search those phrases back into Reddit and find the named complainers.
+- **LinkedIn** - paste the problem in quotes into search, filter to Posts → Past Week.
+- **Industry Slack and Discord** - Indie Hackers, Lovable, No Code Founders, and the vertical-specific communities your AI map named.
+- **G2 and Capterra reviews** - pull every 2-star and 3-star review of the closest competitor. Pain a stranger typed for free, organized by feature.
+- **Twitter/X** - the 280-character constraint forces complaints to be precise.
+- **Personal network referrals** - text 10 people you know: `Do you know anyone who [painful task] regularly? Research call, not sales.` Warm referrals book at 70%+ show rates.
+
+One Reddit rule: don't blast a launch post on day one. Read the sub for a week, leave three real comments, then post a research question. The [self-promotion on Reddit guide](/blog/self-promote-on-reddit-without-getting-banned-promotion/) covers the karma floor and the unwritten rules.
+
+Write down 30 specific sentences in their language with the username next to each. That bank is your raw material when you write the cold messages. Don't paraphrase.
+
+### Build a list of 30 specific people
+
+Turn the 30 sentences into 30 names. Open each thread you saved while reading, click each useful username, and copy four things into a spreadsheet:
+
+- **Name** (theirs, not their company)
+- **Role + company** (one cell)
+- **The post you'll reference** (paste the URL)
+- **One specific line they wrote** (the phrase you'll quote back when you write to them)
+
+Aim for 30 hand-picked people in one focused sitting.
+
+**This is the most important step in the chapter.** A list of 30 individuals you can name - because you read what they wrote - replies at 3-5× the rate of a list of 30 strangers a tool exported for you.
+
+If you run out of named posters before you hit 30, [Apollo](https://apollo.io)'s free tier (credit-based: roughly 100 email credits + 10 export credits per month, no credit card) lets you filter on role + industry + company size and export the rest (at 10 exports/month, this fills the gap over several weeks, not one sitting). Treat it as backfill, not the source - the hand-picked names always perform better.
+
+> **Save the Apollo filter and whatever contacts your monthly export credits cover (roughly 10 per month on the free tier) to a tab named "Module 5 cold seed" in your outreach spreadsheet.** You will reuse this exact filter in [Ch 5.5 cold outbound](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/).
+
+Filter the final list on six dimensions:
+
+1. **Buyer OR user** - not both
+2. **Company size** in your sweet spot (50-500 for most B2B SaaS)
+3. **One industry** first - vertical depth beats horizontal spread
+4. **One timezone** - so the calls are actually bookable
+5. **The tool you replace or integrate with** - filters out the "different problem" lookalikes
+6. **A recent funding or hiring signal** - movement = budget = openness
+
+Drop anyone outside the band. You want signal, not volume.
+
+> **Consumer founders** - skip the database backfill. Your buyer is on Reddit, Discord, TikTok comments, and Instagram. The hand-picked path is the only one that works for you.
+
+## What to do next
+
+| Step | Action | Output |
+|---|---|---|
+| **1** | Write the three sentences: customer, business, solution. One napkin. | Three sentences locked |
+| **2** | Run the AI ICP map prompt with your three sentences + 2 competitor URLs. | ICP profile + 8 communities + 5 search strings |
+| **3** | Read the top channels. Copy 30 verbatim complaint sentences with usernames and URLs. | Google Doc with 30 sentences |
+| **4** | Build the 30-name spreadsheet: name, role+company, post URL, one quoted line. | 30-name list ready |
+| **5** | Move to [Part 2: What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) for the message templates and send cadence. | Next chapter |
+
+## Optional upgrades
+
+These are skip-by-default. The main chapter works without any of them.
+
+**Upgrade the AI ICP map prompt with a deep-research tool.** The Claude/ChatGPT version above is fast and free; the trade-off is the AI synthesizes text without source links. For a verifiable evidence trail, swap in Perplexity Pro ($20/mo) or Gemini Deep Research ($20/mo Advanced) with the same prompt - both return real-source citations for every claim. Spot-check that each proposed community is alive and on-topic before you invest reading time, and grab verbatim quote snippets you can reuse as cold-message subject lines later.
+
+**Offline-heavy verticals - paid panel as Plan A.** If your ICP lives in trades, nursing, in-store retail, elderly users, or regulated B2B, the Reddit / LinkedIn / G2 flow returns nothing useful. Use a paid panel instead. [UserInterviews](https://www.userinterviews.com/) and [Respondent](https://www.respondent.io/) have screened participants across these verticals; cost is $30-$100 per interview. Decision rule: if your ICP description names an offline trade, an over-60 user, or a regulated profession, budget for a paid panel as Plan A.
+
+**Monitoring tools that cut the manual reading load.** [Keyworddit](https://keyworddit.com) (free, no signup) surfaces the high-frequency keywords inside any subreddit. [F5Bot](https://f5bot.com) (free) sends email alerts when your keywords appear on Reddit, Hacker News, or Lobste.rs. [Reddinbox](https://reddinbox.com) / [Pushshift](https://pushshift.io) (free) searches Reddit's full archive for high-commercial-intent phrases like "how to automate X" or "sick of doing Y manually." These tools surface the threads faster - you still read them yourself.
+
+## Further reading
+
+- Rob Fitzpatrick, [The Mom Test (book site)](https://www.momtestbook.com/) - the past-behavior interview technique you'll run on every call this chapter's list books.
+- Y Combinator, [Talking to Users (Startup Library)](https://www.ycombinator.com/library/6g-how-to-talk-to-users) - the canonical YC essay on why this conversation has to happen.
+- [Apollo](https://www.apollo.io/) - contact database for filtering by role + industry + company size when the hand-picked list runs thin.
+- [Clay](https://www.clay.com/) - list enrichment with email verification, useful once you're past 5 paying customers.
+- [User Interviews](https://www.userinterviews.com/) and [Respondent](https://respondent.io) - research panels for ICPs that cannot be reached cold.
+
+> **Done when:** 30-name list is built in your spreadsheet with name, role+company, post URL, and one quoted line per row.
+> **Next click:** [2.3b · Find 10 People: What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) - the message templates, cadence, and follow-up sequence.
+> **If blocked:** If the AI returned "NOT FOUND" for every community, your hypothesis is too vague. Go back to Ch 1.1 and rewrite the customer sentence with a specific role, company size, and the moment in their week when the pain happens.
+
+> **Stuck? Most first-timers stall here:** your name list stops at 3 people. **Fix:** search a related keyword - "boarding costs" instead of "pet sitter," "claim denial appeal" instead of "medical billing." The second-degree search surfaces people with the same problem but different vocabulary. 30 minutes of keyword variation turns 3 names into 12. Not "License Apollo Pro."
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: AI ICP map identifies r/Accounting (300K members), Controller-specific LinkedIn groups, AICPA conference attendees. Builds a 30-name list of controllers who posted about "manual reconciliation" or "month-end close pain" on LinkedIn in the last 90 days.
+>
+> **Mia**: AI ICP map identifies Facebook parent groups (ADHD Parent Support, Dyslexia Moms Unite), r/ParentingADHD, local school district special-ed coordinators. Builds a 30-name list of parents who posted about "can't find a tutor" or "tutoring waitlist" in the last 60 days.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/cover.png b/content/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/cover.png
new file mode 100644
index 000000000..25ebf8e67
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/index.md b/content/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/index.md
new file mode 100644
index 000000000..71e1682df
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/index.md
@@ -0,0 +1,210 @@
+---
+title: "2.3b · Find 10 People: What to Say"
+aliases: ["/blog/find-10-people-with-problem-outreach-2026/"]
+description: "The message templates that book 10 customer interviews. 3-message sequence, volume targets, research panel fallback. Part 2 of Chapter 2.3."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: find-10-people-with-problem-outreach-2026
+keywords:
+  - find customers to interview 2026
+  - non technical founder outreach
+  - cold outreach message template
+  - book customer interviews
+  - validation outreach sequence
+tags:
+  - founders
+  - non-technical-founder
+  - customer-research
+  - validation
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "2.3b · Find 10 People: What to Say"
+  og_description: "The message templates that book 10 customer interviews. 3-message sequence, volume targets, research panel fallback."
+cover_image_alt: "JetThoughts cover showing the 5-step outreach funnel from Reddit mining at the top down to 10 calls booked at the bottom"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/"
+related_posts: false
+---
+
+> **Module 2 · Step 3b of 4** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a 30-name list from [Part 1: Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) - specific people you can name because you read what they posted
+>
+> **Output:** 10 interview calls booked, transcripts in hand, ready to score per the Ch 2.1 rubric
+
+> **TL;DR:** Send 30 staggered messages referencing specific posts you read. A 3-message sequence (Day 0 intro + Day 3 bump + Day 7 close) books 10 interviews. Reply rate runs 20-30% when each message names a specific post; 1-5% when it doesn't.
+
+> **This is Part 2 of 2.** [Part 1: Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) covers the ICP mapping, reading threads, and building the 30-name list. You need the list from Part 1 before the templates below will work - generic openers collapse to 1-5% reply rates.
+
+> **How this chapter relates to Ch 2.4:** this chapter recruits 10 fresh interviewees and runs PAST-BEHAVIOR interviews about whether the problem is real. [Ch 2.4](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/) takes the 5 strongest-signal interviewees from these 10 and runs a DIFFERENT kind of session - silent observation while they click through a throwaway Lovable prototype. Same recruitment pool; different methodology; sequential, not parallel. Run Ch 2.3 (a + b) first to validate THE PROBLEM, then Ch 2.4 to validate THE SOLUTION SHAPE.
+
+This is interview recruitment, not sales. You're asking for time and insight, not money - different message template, different channels, different reciprocity. Don't use the Chapter 5.5 cold-email script here; it scares interview subjects who don't yet know you have a product.
+
+## What to write so they don't ignore you
+
+Send 30 messages staggered, not in one burst. A handful a day, by hand, beats a single bulk-send. Reply rate runs 20-30% when each message names a specific post you read - 2-3 booked calls per batch, which is enough to hit 10 interviews when stacked with replies still trickling in.
+
+You can do this from Gmail and a [NeetoCal](https://www.neeto.com/neetocal) booking link. If 6 a day by hand is too slow, [Gmail's multi-send](https://support.google.com/mail/answer/12018150) (up to 1,500/day on Workspace, ~500/day on personal) or [Streak](https://www.streak.com/) does the mail merge for you. Reply by hand either way - the back-and-forth is where the interview actually gets booked.
+
+### The message most non-technical founders write first
+
+Before we hand you a working sequence, look at the version a founder typically sends on attempt one. This is composed from real first-draft messages we've seen across rescues:
+
+```text
+Subject: quick chat?
+
+Hi Marcus,
+
+My name is [your name] and I'm building a tool that helps small-business
+owners with invoicing. I'd love 30 minutes of your time to learn more about
+your business and see if my product would be a good fit.
+
+Would you be open to a quick chat next week? Calendar is here: [link]
+
+Thanks!
+```
+
+Reply rate on that message hovers around 1%. Here's why each sentence dies:
+
+- **"quick chat?"** subject - generic; competes against every recruiter cold email in their inbox.
+- **"building a tool that helps small-business owners with invoicing"** - pitches a solution to a stranger who didn't ask.
+- **"learn more about your business"** - vague. They need to know what you'll do with their 30 minutes.
+- **"see if my product would be a good fit"** - sales language. The reader hears "I'm prospecting," closes the tab.
+- **No mention of how you found them.** The reader can't tell whether you're spamming 500 people or actually paying attention.
+
+The rewrite fixes one thing at a time: subject names the topic they posted about, opening line names the specific post you read, the ask is for 20 minutes of their experience (not their feedback on your idea), and you make it explicit you're not selling.
+
+### The working 3-message sequence
+
+Copy the 3-message sequence below. Replace bracketed parts with their words from when you read where they're complaining in [Part 1](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/), not yours.
+
+```text
+Day 0 - intro (reply rate target: 20-30%)
+Subject: quick question about [their exact workaround]
+"Saw your post on r/SaaS last week about [the thread]. I'm a [role]
+looking into the same problem. Not selling - 20 min so I can ask 5
+questions about how you handle [task] today? Calendar: [NeetoCal link]."
+```
+
+**Day-3 bump message - pick the version that fits your stage:**
+
+- **First-round variant (you have 0-9 interviews done):** "Hi [name] - circling back on the [topic] piece. Running my first 10 conversations on this problem - still learning, would value 25 minutes if you have it."
+- **Experienced variant (you have 10+ interviews done):** "Hi [name] - circling back on the [topic] piece. Already 30+ founders in - the conversations are sharper than I expected; happy to share the pattern if you have 25 min."
+
+Day-3 bump recovers 8-12% of non-responders. Subject line: `re: [their workaround]`.
+
+```text
+Day 7 - close (recovers 3-5% more)
+Subject: last try - 20 min on [topic]
+"Last note. If this isn't your problem, no worries - I'll stop. If it is
+and you haven't had a chance: [NeetoCal]. Running interviews through next
+Friday."
+```
+
+In our 2026 outreach engagements that sequence ran 30-45% reply rates when the Day-0 subject referenced something the recipient had actually posted - your mileage will vary by audience tightness and recency of the posted content. It collapses to 1-5% with a generic "love to pick your brain" opener - the difference is the reading you did in Part 1 to find named people. The [cold-email conversion playbook from YC Startup School](/blog/how-convert-customers-with-cold-emails-startup-school/) walks through more variations on the opener pattern.
+
+The same 3-email pattern works as LinkedIn DMs. Subject becomes the connection-request note. Skip Day 7 on LinkedIn (too aggressive in DM context).
+
+### Volume targets
+
+Send 30 to 50 messages to land 10 interviews. Target a reply rate of 20% or higher - below that, your opener is too generic or you're in the wrong channel. Of the replies who say yes, expect 50% or more to actually show. If your show rate drops below 50%, add a 24-hour reminder message and confirm the meeting time the day before.
+
+## What if cold outreach can't reach them
+
+### Backup with a research panel
+
+If your ICP can't be reached cold - a CFO at a regulated bank, an oncology nurse, a top-100 retailer's head of operations - cold messages will not work no matter how sharp the opener is. The shortcut: a research panel that pays interviewees for their time.
+
+**[User Interviews](https://userinterviews.com)** and **[Respondent](https://respondent.io)** are the two big ones. You write a screener, upload the interview script, and they ship booked calls in 3-5 days. Respondent tends to reach business roles (CFOs, engineering directors, ops leads) more reliably; User Interviews has broader consumer coverage.
+
+The cost is real - each booked call has a meaningful incentive attached - so panels are not the default. Use them only when the cold-outreach path can't reach your ICP. When they do work, run them in parallel with cold outreach: the two samples bias differently (free-time strangers vs. paid-time strangers), and together they give you a more honest read.
+
+### The parallel smoke-test landing page
+
+While the cold-outreach path books the calls, the smoke-test landing page from [Chapter 1.2b](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) (built in [1.2a](/course/tech-for-non-technical-founders-2026/smoke-test-build-landing-page/)) measures whether strangers will give you their email for the thing you described. Run it in parallel and drop the URL into your messages - it doubles as the warmest opener:
+
+> "You signed up for the waitlist on [page] last Tuesday - up for a 20-minute call?"
+
+Reply rates on that opener run 60%+ - the highest in this whole chapter.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    A(["Start a focused block. 30-name list from Part 1."])
+    A --> B[Cold outreach track: 30 messages by hand]
+    A --> C[Research-panel track: only if cold can't reach the ICP]
+    A --> D[Smoke-test track: landing page from Chapter 1.2a + 1.2b]
+    B --> E[10 interviews booked]
+    C --> E
+    D --> E
+    E --> F[Apply Mom Test script from Chapter 2.1]
+
+    classDef start fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a
+    classDef track fill:#fff5f5,stroke:#cc342d,stroke-width:2px,color:#1a1a1a
+    classDef paid fill:#faf5ff,stroke:#a855f7,stroke-width:2px,color:#1a1a1a
+    classDef goal fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+
+    class A start
+    class B,D track
+    class C paid
+    class E,F goal
+```
+
+Run the cold-outreach track first - that's where the 10 calls usually come from. Run the smoke-test in parallel because it costs nothing extra. Add the research panel only if your ICP can't be reached cold.
+
+## What to do next
+
+| Step | Action | Target |
+|---|---|---|
+| **1** | Open your 30-name list from Part 1. Customize the Day-0 message for the first 5 names - one specific reference per message from the line you quoted. | First 5 messages drafted |
+| **2** | Send the first 5 by hand. Reply by hand to anyone who answers. | First replies trickle in |
+| **3** | Send the remaining 25 staggered over the next few days. Day-3 bumps to non-responders. | Full 30-message batch out |
+| **4** | Check the reply rate. If under 10%, rewrite Day-0 subject line referencing a specific post and resend. If 10-30%, let the sequence run. If 30%+, move to [Mom Test script](/course/tech-for-non-technical-founders-2026/mom-test-interview-script/). | Calibrate by reply rate band |
+
+> **Slow-path variant for the part-time founder** (working evenings only, day-job constraints): the staggered cadence above assumes daytime availability. If your only window is one evening block a week, batch-send instead: sort 30 names into priority buckets first, then personalize and send all 30 in one go using Gmail multi-send. Expect a lower reply rate (~8-12% vs 20-30%) because the messages land in a burst instead of a stagger - compensate by booking the first 2-3 interviews from your fastest responders quickly.
+
+The [Outreach Sequence Template](/course/tech-for-non-technical-founders-2026/outreach-sequence-template/) carries the verbatim sequence plus the LinkedIn DM openers, cold-email subject lines, Reddit research-comment template, and NeetoCal page copy.
+
+## What happens after the 10 calls are booked
+
+This chapter's output is 10 booked interviewees. Running them, scoring them, and turning them into the validated problem statement that Module 3 needs is the linear sequence below.
+
+> **You are now ready to run the interviews using Ch 2.1's 5-question script.** Open Ch 2.1 on a second tab and scroll to the scoring rubric. Then move to [Mom Test Synthesis: Build, Pivot, or Kill](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) once all 10 transcripts are scored.
+
+The chain of artifacts the booked calls produce:
+
+1. **Run each interview using the Ch 2.1 5-question Mom Test technique.** Open the [Mom Test Interview Script](/course/tech-for-non-technical-founders-2026/mom-test-interview-script/) artifact on a second monitor; read the 5 questions verbatim. 30-40 minutes per call.
+2. **Score each call 1-10 within 5 minutes of hanging up** per the Ch 2.1 scoring rubric. Write the score before opening the next browser tab.
+3. **After all 10 calls are done, fill the [Validated Problem Statement template](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/)** using the [Mom Test Synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) page.
+4. **Pick the 5 strongest-signal interviewees** (Mom Test score ≥ 7) for Ch 2.4 prototype sessions.
+5. **Two artifacts now flow into Module 3 + later modules:**
+   - The Validated Problem Statement (Section 1 of the Ch 3.1 one-page brief, lifted verbatim)
+   - The 5 strongest-signal interviewees (Ch 2.4 input - and later, your Module 5 onramp invitees in Ch 4.3 (a + b), plus your warm-list seed in Ch 5.3)
+
+If fewer than 7 of 10 calls score ≥ 7, the problem is too weak for this ICP. Re-evaluate the ICP, the problem framing, or the question wording before booking another 10 calls. The full kill / iterate / proceed decision lives in the [Mom Test Synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) page.
+
+Skip this module and start building, and the typical failure mode is burning months of build time and a five-figure contractor budget before discovering the problem you assumed was real wasn't. Validation is founder work because the signal disappears when an intermediary handles the conversation.
+
+## Further reading
+
+- Rob Fitzpatrick, [The Mom Test (book site)](https://www.momtestbook.com/) - the past-behavior interview technique you'll run on every call this chapter books.
+- Y Combinator, [Talking to Users (Startup Library)](https://www.ycombinator.com/library/6g-how-to-talk-to-users) - the canonical YC essay on why this conversation has to happen.
+- [Apollo](https://www.apollo.io/) - contact database for filtering by role + industry + company size when the hand-picked list runs thin.
+- [User Interviews](https://www.userinterviews.com/) and [Respondent](https://respondent.io) - research panels for ICPs that cannot be reached cold.
+
+> **Done when:** 10 interview calls are booked on your calendar and you have sent the first batch of outreach messages.
+> **Next click:** Return to [2.1 · The Mom Test](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) to run the interviews using the 5-question script, then move to [Mom Test Synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) to score the transcripts.
+> **If blocked:** If your reply rate is under 10%, your Day-0 subject line is too generic. Rewrite it to reference a specific post you read by that person. If your ICP can't be reached cold, switch to a paid research panel (User Interviews or Respondent).
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Sends the 3-message sequence to 30 controllers on LinkedIn. Books 12 interviews from 30 reaches (40% reply rate - high because Tomas was an accountant and speaks their language).
+>
+> **Mia**: Sends the 3-message sequence to 30 parents via Facebook DM. Books 14 interviews from 30 reaches (47% - high because Mia was a teacher and parents trust her).
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/cover.png b/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/cover.png
new file mode 100644
index 000000000..5f4b2db5f
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/index.md b/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/index.md
new file mode 100644
index 000000000..41c8b0af1
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/index.md
@@ -0,0 +1,230 @@
+---
+title: "The First-Paying-Customer Operating Kit (DPA Template Live)"
+aliases: ["/blog/first-paying-customer-operating-kit/"]
+description: "The six-template kit for Module 5. We are assembling and shipping templates here as each one is ready - bookmark and check back. No email signup."
+date: 2026-05-13
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: first-paying-customer-operating-kit
+keywords:
+  - first paying customer template
+  - design partner agreement template free
+  - sean ellis survey template
+  - cold email scripts founder
+  - stripe checkout rails django laravel
+tags:
+  - founders
+  - non-technical-founder
+  - first-paying-customer
+  - course-companion
+  - lead-magnet
+categories: ["Templates"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "The First-Paying-Customer Operating Kit (DPA Template Live)"
+  og_description: "The six-template kit for Module 5. We are assembling and shipping templates here as each one is ready - bookmark and check back. No email signup."
+cover_image_alt: "JetThoughts blog cover for the First-Paying-Customer Operating Kit showing 6 component cards arranged as a single bundle"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/"
+related_posts: false
+---
+
+📋 Template companion to [Module 5 of the From Idea to First Paying Customer course](/course/tech-for-non-technical-founders-2026/). Six artifacts that take you from live MVP to signed paid pilot in 4 weeks.
+
+> **Status: shipping.** The DPA template (component 3) is live below - copy and paste into Google Docs. The other 5 components are described here and shipping as each is ready. There is no email signup; when a template is downloadable, the link appears inline below. Bookmark and check back.
+
+# The First-Paying-Customer Operating Kit
+
+*From live MVP to signed paid pilot in 4 weeks - the templates Module 5 runs on.*
+
+## What this kit covers
+
+Module 5 of this course walks five chapters: the Sean Ellis 40% test, the personal-network outreach, the paid-pilot contract, and the cold-outbound pipeline. Each chapter references a template. This page hosts them as each one ships. The DPA template is live below (component 3); the remaining 5 are described and shipping next.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TB
+    Kit[First-Paying-Customer
Operating Kit]
+    Kit --> T1[1. 50-name network list
Google Sheets template]
+    Kit --> T2[2. Cold-email scripts
3 variants]
+    Kit --> T3[3. Design Partner Agreement
one-page LOI]
+    Kit --> T4[4. Stripe Checkout setup
Rails / Django / Laravel]
+    Kit --> T5[5. Sean Ellis survey
5 questions, Typeform-ready]
+    Kit --> T6[6. First 10 Customers tracker
Airtable template]
+    classDef kitstyle fill:#a855f7,stroke:#1a1a1a,stroke-width:2px,color:#fff;
+    classDef compstyle fill:#fff5f5,stroke:#cc342d,stroke-width:2px;
+    class Kit kitstyle;
+    class T1,T2,T3,T4,T5,T6 compstyle;
+```
+
+## The 6 components
+
+### 1. 50-name network list template (Google Sheets)
+
+The fill-in spreadsheet from [Chapter 5.2](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/). Six columns - Name, Company, Role, Bucket, Relationship strength, Last contact date - plus four progress columns for tracking replies and demos. Pre-sorted by bucket: 5 champions on top, then 10 hot, 15 warm, 20 cold. Three blank rows in each bucket for week-2 additions.
+
+In practice: turns a vague "I should reach out to people" instinct into 50 named messages going out by Friday EOD.
+
+### 2. Cold-email scripts (3 variants)
+
+The verbatim 4-line scripts from [Chapter 5.4](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/). Three sector-specific versions:
+
+- **B2B SaaS rescued-Rails context** - the script for founders who got out of an agency burn and are now selling to operators in the same situation.
+- **B2B services** - for fractional CTOs, consultancies, and managed-services founders who sell time rather than license.
+- **B2C app** - for direct-to-user products where the Loom + claim-link motion replaces a Calendly call.
+
+Each script comes with three sample subject lines that have cleared 25%+ open rates in 2026 founder cold-outbound runs, plus a 3-message follow-up cadence (day 0, day 4, day 11).
+
+Why it matters: removes the "what do I say in the email" friction so you spend 60-90 seconds per name on personalization, not 20 minutes.
+
+### 3. Design Partner Agreement template (one-page LOI + paid pilot)
+
+The one-page DPA from [Chapter 5.3](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/). Six sections plus signature block. Plain English, mutual-edit document, no lawyer required for v1. Comes in three formats: Google Docs (default), PDF (for customers who want to print), DocuSign-import (for customers who want to e-sign with audit trail).
+
+Two annotated examples: a $1,500 B2B SaaS pilot DPA and a $5,000 B2B services pilot DPA, both based on real (anonymized) 2026 founder deals.
+
+The outcome: makes the "we run paid pilots" conversation a 15-second handoff instead of a three-week back-and-forth.
+
+> **📋 Copy-pasteable DPA template - copy into Google Docs, fill the [BLANKS], send:**
+>
+> # Design Partner Agreement
+>
+> **Between:** [Your Company Name] ("Company") and [Customer Company Name] ("Design Partner")
+> **Date:** [YYYY-MM-DD]
+>
+> ## 1. Scope of Pilot
+>
+> The Company will deliver the following outcomes during the pilot period:
+> 1. [Outcome 1 - measurable, e.g. "Reduce weekly report prep from 3 hours to 30 minutes"]
+> 2. [Outcome 2]
+> 3. [Outcome 3]
+>
+> Specific use cases covered: [Use case 1], [Use case 2].
+> Anything outside this list is out of scope until year-one conversion.
+>
+> ## 2. Duration + Dates
+>
+> Start date: [YYYY-MM-DD]
+> End date: [YYYY-MM-DD] (6-8 weeks)
+> Weekly Friday demo at [time] [timezone]. 15 minutes. Loom or live screenshare.
+>
+> ## 3. Pilot Fee + Deposit
+>
+> One-time deposit: $[500-6,000] (10-30% of year-one ACV).
+> Paid via Stripe before pilot kickoff. Credited dollar-for-dollar toward year-one invoice on conversion.
+> If Design Partner cancels before week 4: deposit forfeited.
+> If Company cancels for any reason: 100% refund within 14 days.
+>
+> ## 4. Success Criteria
+>
+> The pilot is successful if **2 of 3** criteria are met by [end date]:
+> 1. [Measurable criterion 1 - e.g. "Report prep time reduced to ≤30 min/week, verified in Friday demo"]
+> 2. [Measurable criterion 2]
+> 3. [Measurable criterion 3]
+>
+> If 2+ criteria met: year-one contract auto-converts unless Design Partner opts out in writing within 7 days.
+> If <2 criteria met: both parties walk. Company retains deposit as paid consideration for pilot work.
+>
+> ## 5. Conversion Terms
+>
+> Year-one price: $[amount] / [month or year]
+> Billing: [monthly / annual]
+> Conversion: auto-convert at pilot end unless Design Partner opts out in writing.
+> Post year-one: 30-day written notice to cancel.
+>
+> ## 6. Data, IP, Termination
+>
+> Design Partner keeps their data. Company keeps the product IP.
+> Either party may exit at 30 days written notice during pilot.
+> Design Partner's data remains exportable for 90 days after termination.
+>
+> **Signed:**
+>
+> _________________________  Date: __________
+> [Your Name], [Your Company]
+>
+> _________________________  Date: __________
+> [Champion Name], [Customer Company]
+
+### 4. Stripe Checkout setup checklist (Rails / Django / Laravel)
+
+Five steps to a working Stripe payment link, no engineer required. Plus optional Rails / Django / Laravel snippets for founders who want to wire deposits back into their app after the first pilot ships.
+
+The Rails snippet uses `Stripe::Checkout::Session.create` from the official `stripe` Ruby gem. The Django snippet uses `stripe.checkout.Session.create` from `stripe-python`. The Laravel snippet uses `Stripe\Checkout\Session::create()` from `stripe/stripe-php`. All three produce the same hosted checkout URL Stripe Payment Links produces; the difference is whether the deposit row gets logged in your app database in real time or you import the CSV at the end of the month.
+
+What it does: 15-minute payment-link setup so the first deposit arrives Wednesday, not three weeks after kickoff.
+
+### 5. Sean Ellis 40% survey template (5 questions, Typeform-import ready)
+
+The exact 5 questions from [Chapter 5.1](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/), in three importable formats:
+
+- **Typeform JSON** - drag-and-drop into a new Typeform.
+- **Tally.so spec** - paste into Tally's import flow.
+- **Google Forms** - copy the question list into a new Google Form (Forms does not support import, but the template is short).
+
+Plus a one-tab Google Sheet that computes per-segment must-have % from your CSV export. Pivot the Q1 column by the Q5 segment column and the per-segment number appears in cell B2.
+
+Result: 24 hours from "I should run the test" to a scored result you can act on.
+
+### 6. The "First 10 Customers" Airtable tracker
+
+The Airtable base from [Chapter 5.4](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/). Pre-filled columns - Name, Company, Bucket, Loom sent, Reply, Demo, DPA sent, Deposit - with color-coded bucket pills (champion / hot / warm / cold) and date stamps on every progress column. Filters: "Replied this week," "Demo this week," "Pilot landed this month."
+
+![Sample row from the First 10 Customers Airtable tracker](kit-sample-row.svg)
+
+The payoff: turns Friday afternoon into a 10-minute "what shipped this week" review instead of a 90-minute scroll through Gmail.
+
+### 7. Pilot kickoff call agenda (60-minute template)
+
+The Stripe deposit cleared on Friday. The pilot starts Monday. Your customer is asking "so what happens next?" - and the course's [Charge Before You Ship](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) chapter taught you how to get to the deposit, not what to run after it. This is the 60-minute kickoff call that turns a deposit into an operating pilot:
+
+| Minute | Section | What to cover | Output |
+|--------|---------|---------------|--------|
+| **0-5** | Introductions | Founder + 1-2 customer stakeholders by name; one-line each on what each person wants from the pilot (champion's measurable win + power-user's daily-job-to-be-done) | Each name + job-to-be-done in your Notion doc |
+| **5-15** | Success criteria recap from the DPA | Read aloud the 1-3 success criteria you wrote into the Design Partner Agreement. Confirm the customer still agrees with them this week. Ask: "If we hit these by Friday week 4, do you renew at the standard price?" | One-line yes/no answer recorded |
+| **15-30** | Friday demo cadence | Lock the recurring Friday 15-min demo slot for 4 weeks. You demo what shipped that week against the success criteria. Customer brings one piece of feedback or one new question. Calendar invites sent during the call. | 4 calendar invites on both sides |
+| **30-40** | Shared Slack / Discord / WhatsApp channel | Create the channel during the call. Add 2 customer-side stakeholders + you. Standing rule: bug reports go in the channel, not email. Channel name: `pilot-[customer-name]`. | Channel live + invite link shared |
+| **40-50** | Single point of contact + escalation | Identify the one person on each side who owns "is this pilot on track?" Customer side is usually the champion who signed the DPA, not their CTO. Your side is you. Escalation path: if the champion is unreachable for 7 days, you escalate to who? Document. | Escalation tree in Notion |
+| **50-60** | Week 1 commitment + go/no-go gate naming | What ships this week (1-3 specific things, not a roadmap). When the go/no-go gate runs (end of week 4, by default - the [DPA template](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) covers this). What "go" means (renew at standard price) and what "no-go" means (refund or graceful exit, no hard feelings, written reference from the customer). | Week 1 commitment + go/no-go date on both calendars |
+
+The trap to avoid: skipping the kickoff and treating the deposit as the end-state. The deposit clears, both sides assume the other knows what happens Monday, and 14 days later the champion is asking "have you started yet?" while you are asking "have they used the tool yet?" - 14 days lost. The 60-minute kickoff is the cheapest insurance against that gap.
+
+For your second pilot onwards, re-use this agenda as a Notion template - 90% of the call is identical across customers; only the success criteria + stakeholders change. The Friday demo cadence is the single biggest churn-prevention move you can make in the first 4 weeks: if your customer sees something new every Friday they are in for the long run, even if you ship small.
+
+## How to use the kit
+
+The kit runs Monday-to-Friday for the four weeks of Module 5. The sequence:
+
+**Week 1 (must-have segment).** Run the Sean Ellis survey (template 5). Compute per-segment must-have %. Pick your target segment.
+
+**Week 2 (personal network).** Fill the 50-name template (template 1). Record Loom. Send champion + hot Monday, warm Tuesday, cold Thursday.
+
+**Week 3 (paid pilot).** Send DPA (template 3) and Stripe link (template 4) to 1-2 warm leads who agreed to demos. Bank first deposit.
+
+**Week 4 (cold outbound).** Filter 30 prospects in Apollo or Sales Navigator. Personalize 60-90 seconds each. Send the script (template 2). Track in the tracker (template 6).
+
+By Friday of week 4, you should have: a segment-isolated persona doc, 50 sent messages with 30+% reply rate, 1-2 signed paid pilots, and 30 cold-outbound prospects with 3-5 booked demos for week 5.
+
+## What this kit is not
+
+The kit is not a substitute for a sales course or a CRM. It will not teach the conversational mechanics of objection-handling, so if you have never run a customer call, read [the Mom Test interview script](/course/tech-for-non-technical-founders-2026/mom-test-interview-script/) and run 10 user calls first. It will not track touch counts past the first 30 customers the way HubSpot, Pipedrive, or Salesforce does - past 30, the Airtable tracker breaks and you graduate to a real CRM. It also does not replace the must-have-segment test from [Chapter 5.1](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/) - if your overall must-have % from template 5 is under 25%, your pipeline will fill, the demos will go fine, and conversions will stall at the deposit conversation. Run the 40% test first; download the kit second.
+
+## How to get the kit
+
+The DPA template (component 3) is copy-pasteable inline above. When the remaining templates ship, they will appear in their matching component sections - no mailing list, no funnel, just the file.
+
+## Where this fits in the course
+
+This is the lead magnet for Module 5 of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) course - the chapter that lands the first paying customer right after the MVP ships. Module 5 runs in four chapters:
+
+- 7.1 [Your First Customer Is Not a Marketing Problem](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/) - run the Sean Ellis 40% test against your 10-30 MVP users.
+- 7.2 [The First Ten Come From People Who Already Know You](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/) - 50-name list, 4 buckets, Monday outreach sequence.
+- 7.3 [Charge Before You Ship](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) - one-page Design Partner Agreement plus Stripe Checkout setup.
+- 7.4 [Going Outbound Without a Sales Team](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/) - filtered cold outbound for customers 11-20.
+
+Module 5 ends here. The kit ships alongside Module 5 as each artifact is ready.
+
+## Built by
+
+[JetThoughts](https://jetthoughts.com), a Rails-first dev shop that has rescued non-technical founders' codebases for 20 years. We published this course because the same five mistakes kept showing up in the rescue calls. The kit ships free for the same reason.
diff --git a/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/kit-sample-row.svg b/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/kit-sample-row.svg
new file mode 100644
index 000000000..7ef406ad3
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/kit-sample-row.svg
@@ -0,0 +1,100 @@
+
+  Sample row from the First 10 Customers Airtable tracker
+  
+    
+  
+
+  First 10 Customers tracker - sample rows from the Airtable template
+
+  
+  
+  Name
+  Company
+  Bucket
+  Loom sent
+  Reply
+  Demo
+  DPA sent
+  Deposit
+
+  
+  
+  Priya Shah
+  Quanta Marketing
+  
+  CHAMPION
+  May 6
+  Yes - May 7
+  May 9
+  May 10
+  $2,400
+
+  
+  
+  Marcus Liu
+  Beacon Analytics
+  
+  HOT
+  May 6
+  Yes - May 8
+  May 12 scheduled
+  -
+  -
+
+  
+  
+  Sarah Okafor
+  Mesa Systems
+  
+  WARM
+  May 7
+  Yes - no fit
+  -
+  -
+  -
+
+  
+  
+  Devon Park
+  Cohort Health
+  
+  HOT
+  May 6
+  Maybe - May 9
+  F/u sent
+  -
+  -
+
+  
+  
+  Ana Reyes
+  Northwall Studio
+  
+  CHAMPION
+  May 6
+  Yes - May 6
+  May 8
+  May 9
+  $1,800
+
+  
+  Color-coded bucket pills. Date-stamped progress. Deposit column sums to your live ARR.
+  Friday afternoon review: how many in each column, which rows stalled, what is your next move.
+
+  
+  
+  Names in this sample are illustrative composites.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/cover.png b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/cover.png
new file mode 100644
index 000000000..da70642ba
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/index.md b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/index.md
new file mode 100644
index 000000000..a67c246df
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/index.md
@@ -0,0 +1,246 @@
+---
+title: "5.3 · The First Ten Come From People Who Already Know You"
+aliases: ["/blog/first-ten-customers-personal-network/"]
+description: "~60% of fast-growing B2B startups got their first 10 customers from personal network. The 50-name list, 4 buckets, and the outreach sequence."
+date: 2026-05-13
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: first-ten-customers-personal-network
+keywords:
+  - first 10 b2b customers
+  - personal network outreach founder
+  - non technical founder sales
+  - design partner outreach
+  - lenny rachitsky first ten customers
+tags:
+  - founders
+  - non-technical-founder
+  - first-paying-customer
+  - sales
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "5.3 · The First Ten Come From People Who Already Know You"
+  og_description: "~60% of fast-growing B2B startups got their first 10 customers from personal network. The 50-name list, 4 buckets, and the outreach sequence."
+cover_image_alt: "JetThoughts blog cover showing a 50-name network list sorted into four outreach buckets, champions on top"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/"
+related_posts: false
+---
+
+> **Module 5 · Step 3 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** must-have-user persona + 1 named segment from [Chapter 5.1](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/) + the channel commitment from [Chapter 5.2](/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/) (if you skipped 5.2, the chapter defaults to LinkedIn DMs for B2B, Reddit DMs for B2C - return to 5.2 to pick deliberately)
+>
+> **Output:** 50 personalized outreach messages sent, with replies tracked in a spreadsheet
+
+> **TL;DR:** Sixty percent of the fastest-growing B2B startups got their first 10 customers from their personal network. Build a 50-name list, sort into four buckets, send personalized messages with a 90-second Loom.
+
+In 2021, Lenny Rachitsky asked 21 of the fastest-growing B2B companies a simple question: where did your first 10 customers come from? The list was not modest - Figma, Stripe, Slack, Airtable, Shopify, Notion, Front, Loom, and thirteen others at similar scale.
+
+He published the answers in [a piece](https://www.lennysnewsletter.com/p/how-todays-fastest-growing-b2b-businesses) every non-technical founder should read before the first ad runs. The headline number: roughly 60% of those first customers came from the founder's personal network, around 35% from filtered cold outbound, and only 5% from inbound, press, or launch events.
+
+> **Important: Your warm network is for SALES, not for VALIDATION.**
+>
+> This chapter is about converting people who already know you into your first PAID PILOT. That is a sales motion, and the warm-network approach is the right move for it.
+>
+> This chapter is NOT a substitute for the Mom Test interviews in [Module 2](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/). Friends, family, and other founders will tell you your idea is great because they are being polite - that is the founder-to-founder echo chamber, and it produces false confidence, not real signal. A true demand signal only arrives when a cold stranger describes the problem in their own words and pays money.
+>
+> If you have not yet run your 10 Mom Test interviews with people who do NOT know you, do that first ([Chapter 2.3a · Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) builds the list, [2.3b · What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) sends the messages). Come back to this chapter when you are ready to SELL, not to validate.
+
+The instinct of the founder out of a dev-shop burn is to skip the 60%. Asking friends to buy feels biased and asking former colleagues feels like cheating, so the voice in your head says real customers come from paid traffic to a clean landing page.
+
+That voice is the same one that told you the MVP would convert at 0.4%. The first 10 customers come from existing trust, and the people most willing to act on that trust are the people who already know you well enough to take a call this week.
+
+This chapter is how you build the list and send the messages.
+
+![Lenny's 60/35/5 breakdown - where the first 10 B2B customers actually came from](lenny-source-bars.svg)
+
+## Why this is the right move, even if it feels wrong
+
+The objection comes up in every founder call: "I do not want to ask friends. It feels like begging."
+
+You are not asking them to buy. You are asking them to be first to try something that solves a problem they already have, at a steep discount, while you fix the rough edges they catch. That is a favor your network owes you about as much as you owe them when they ask for an intro.
+
+The trade is your time and a refundable deposit against a tool that will save them hours from the first week. The people who have the problem take the trade; the people who do not have it were never your customer, so you cut bait fast and move to the next name.
+
+Open your phone. Eight names there that you have not messaged in a year are eight first-paid-pilot candidates - if three of them have the problem your hypothesis names, three pilots can close in your first two weeks of asking.
+
+The other failure mode: a former colleague posts about your tool's exact problem on LinkedIn and you do not respond because you are waiting on your landing-page redesign to be perfect. The redesign is two weeks; the lead is gone today.
+
+> **First: count your actually-applicable names. Then pick a path.**
+>
+> Open LinkedIn. Filter your 1st-degree connections by your must-have segment from Ch 5.1 (title + company size + industry). Count what comes back.
+>
+> | Count | What this means | Your path |
+> |---|---|---|
+> | **30+** | Standard warm motion works. Build the 50-name list as described below. | Continue with the 4-bucket structure. |
+> | **15-29** | Reduced warm motion. Build buckets at smaller sizes: 2 champions + 5 hot + 8 warm + 5 cold. Expected yield: 4-7 replies, 1-2 demos, 0-1 paid pilot. Warm motion alone will not close your first customer; you will need cold outbound (Ch 5.5) in parallel, not sequential. | Build the reduced list AND start the M5.5 cold prep on the same week. |
+> | **Under 15** | Your professional network does not yet contain the ICP segment. Warm motion will not produce your first customer. | Skip the warm-bucket structure entirely. Go directly to Ch 5.5 cold outbound. Use the small-list community fallbacks below (YC batch, Indie Hackers, sector Slack) to seed initial warm-cold messages. |
+>
+> The 50-name structure below is the **best-case path**, not the universal path. An idea-stage founder with a generalist network typically lands in the 15-29 band; budget two months of cold outbound on top of the warm motion to land your first customer in that scenario.
+
+## The 50-name list: 4 buckets
+
+> **Honest calendar for the full send sequence.** The 50-name LIST is one sitting (60-90 min once your LinkedIn export arrives, which itself takes 24 hours). The full SEND sequence (Loom recording + champion + hot + warm + cold messages staggered across days) is 8-12 hours of active effort spread across 7-10 calendar days. Plan two evenings for the list-build and four-to-five evenings for the staggered sends. The chapter framing of "one sitting" applies to the list-building step, not the entire outreach round.
+
+Open a Google Sheet. Six columns: Name, Company, Role, Bucket, Relationship strength, Last contact date. Fill 50 rows in one sitting before you send anything.
+
+| Bucket | How many | Definition |
+|---|---|---|
+| Champions | 5 | Already complained to you about this exact problem. Will pick up your call. |
+| Hot | 10 | In the must-have segment from [Chapter 5.1](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/). Knows you personally. Recent contact under 6 months. |
+| Warm | 15 | Adjacent. Knew you 6-24 months ago. Reasonable bet they have the problem. |
+| Cold | 20 | Dormant LinkedIn 1st-degree. Unclear if they have the problem. |
+
+![The 4-bucket grid - how 50 names get sorted before the first message goes out](network-buckets.svg)
+
+**Where to find the names.** Open LinkedIn. Filter your 1st-degree connections by the criteria that define your must-have segment from [Chapter 5.1](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/). For a B2B-marketer must-have segment, filter on title (Marketing, Growth, Demand Gen, RevOps), company size (50-500 employees), and industry (one vertical first, expand later).
+
+Export the filtered list with [LinkedIn's data export](https://www.linkedin.com/help/linkedin/answer/a566336) - free for everyone, takes 24 hours but you can use yesterday's. Cross-reference your phone contacts, your email inbox, your last three jobs' Slack workspaces if you still have access, and your YC or accelerator batchmate list if you have one.
+
+The 50 names will assemble faster than you expect once the segment filter is set.
+
+**Champions deserve extra thought.** Five champions is a high bar. If you cannot name five people who have complained to you about this exact problem in the last twelve months, you may not have a must-have segment at all - go back and re-read your verbatim Q2-Q3 quotes from the [Chapter 5.1 survey](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/). The champions are the people who said those words to you in real life before the survey existed.
+
+## The outreach template (Loom + Calendly + paid-pilot teaser)
+
+Champions and hot get personalized messages with a recorded Loom. Warm and cold get a name-personalized template. The structure is the same for all four buckets - what changes is the opening line and how much you personalize from your shared history.
+
+### The 4-part message
+
+**Part 1: Earn the open with a specific reference.**
+
+The opener changes by bucket. Pull the reference from whatever shared history is freshest:
+
+| Bucket | Opener template |
+|---|---|
+| Champions | "Hey [name], you mentioned [the exact thing they said] back in [month]. Still happening?" |
+| Hot | "Hey [name], just saw [a specific thing they posted, shipped, or said recently]. Have a question about [the problem]." |
+| Warm | "Hey [name], have not caught up since [the last specific touchpoint]. Working on something I think you might have a take on." |
+| Cold | "Hey [name], [a true one-line reference - 'we were both in the Acme batch,' 'you commented on my LinkedIn post about X']. If no real reference exists, move them out of network outreach and into [Chapter 5.5 cold outbound](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/), not here." |
+
+**Part 2: One line on the problem, in their language.**
+
+Use the verbatim Q3 answers from your [Chapter 5.1 survey](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/). "I am building a tool that lets B2B marketers run an end-to-end attribution model without an analyst." If the words are not theirs, swap until they are.
+
+**Part 3: A Loom video, not a paragraph.**
+
+Record one 90-second Loom before you send. A free Loom account gives you 25 free videos. The Loom shows your product in 60 seconds and you on camera in the other 30. Skip the Loom and write a paragraph instead and you get half the response rate, because the recipient needs to see both your face and the product working in the same 90 seconds.
+
+> **Loom script source: your Ch 5.1 verbatims.** Lines 2-3 of your Loom should NOT be your own marketing voice - they should be the three Q2-Q3 verbatim quotes you exported from the [Ch 5.1 must-have segment test](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/) Google Doc. Read those quotes aloud, then point at the product feature that addresses the pain they describe. Recording in the founder's voice is the failure mode Ch 5.1 was designed to prevent; the Loom is the highest-leverage place to use the verbatims you already have.
+
+**Part 4: A specific ask - 15 minutes, paid pilot teaser.**"15 minutes to walk you through it and see if it solves the [problem]? Open to a paid pilot if it does. Calendly: [link]."
+
+The "paid pilot" hint is load-bearing. You are flagging that this is not a free favor and not a free trial. The full mechanic of the paid pilot is the subject of [Chapter 5.4](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) - keep the teaser short here.
+
+**Total length:** 5-7 sentences. Anything longer and the recipient skims and forgets.
+
+## The send sequence
+
+The sequence in one glance:
+
+1. **Step 1** - List 50 names, sort into the 4 buckets.
+2. **Step 2** - Record the 90-second Loom.
+3. **Step 3** - Send the 5 champion messages and the 10 hot messages.
+4. **Step 4** - Send the 15 warm messages a day or two later.
+5. **Step 5** - Send the 20 cold messages once the first replies are in.
+6. **Step 6** - Review replies, book demos for the following stretch.
+
+You will hear back from 15-25 of the 50 messages once replies settle. That is a 30-50% response rate on a properly built personal-network list, and it is the highest response rate you will ever see again as a founder.
+
+Use it well.
+
+> **Slow-path variant for evenings-only founders** (day job + family time): the staggered cadence assumes daytime availability you do not have. One-evening alternative: in a single 2-hour block, spend the first 30 minutes sorting 50 names into the 4 buckets and recording the Loom (you can re-use the same Loom for all 50). Spend the next 90 minutes personalizing each message's first line (their name + the specific connection or shared interest) and sending all 50 in one batch using LinkedIn DM or Gmail with a templated body. You lose the response-rate uplift the staggered send produces (~30-50% becomes ~20-35%) but you complete the whole sequence in one evening instead of needing several separate workday windows. Book demos for evenings or weekend mornings - your respondents will work with your calendar if your first message was specific enough.
+
+**Track replies in the same Sheet.** Add four columns to the right: Reply received (date), Reply sentiment (yes/maybe/no/silent), Demo booked (date), Pilot proposed (yes/no). When the demo books, paste the Calendly confirmation date. When the pilot conversation happens, advance the row to [Chapter 5.4](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/).
+
+## What the "no" replies actually tell you
+
+A "no" from a champion is the most expensive single piece of feedback you will get all year. Champions said the problem out loud, you built the thing, and they passed. Always reply with a single question: "Help me understand - what changed since [the original conversation]?"
+
+| Pattern | Question to ask | Fix action |
+|---|---|---|
+| **The problem moved** | "Did you solve this another way?" | They built a workaround (spreadsheet, internal tool, hire). Your product was out-paced. Re-read your [Chapter 5.1 segment-isolation results](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/). Check if this generalizes to your segment. |
+| **The buying motion is wrong** | "Who would make this decision?" | They have the problem, but it is not their call. The CFO, CTO, or VP buys it. Get the introduction. Your champion becomes a referrer. |
+| **You missed the brief** | "What did I over-solve or under-solve?" | What you built does not match what they remembered complaining about. This is the most painful answer and the highest payoff: edit your product, verbatim quotes, and persona accordingly. |
+
+A "no" from cold is a non-event. They were never the right name. Move on.
+
+## The hot bucket is where the conversions live
+
+> Most of your booked demos come from champions, but most of your eventual paid pilots come from hot.
+> Champions get on the call out of relationship and curiosity. Hot names are still warm but have less context,
+> which forces you to articulate the value cleanly. That clean articulation is what closes the rest of your pipeline.
+> The hot calls are where you sharpen the pitch you will use for the next 90 customers.
+
+If you have a champion on the call and they say "this would be perfect for [name in hot], do you want an intro," say yes immediately. Champion-routed warm intros convert at 3-4x the cold-warm conversion rate. The cost is one email back to your champion that day.
+
+## When the personal network is genuinely small
+
+Some founders read the bucket structure and panic because their LinkedIn is at 200 connections and their phone has 40 names. The math still works, but the source mix shifts.
+
+| Adjacent source | How it works | Conversion note |
+|---|---|---|
+| **Your accelerator or YC batchmates** | A YC batchmate list is twice the size of your network and pre-warmed by the shared experience. Slack the batch about your launch. | Higher conversion than cold outbound. Shared experience = faster buy-in. |
+| **The community you live in** | Indie Hackers, [r/SaaS](https://www.reddit.com/r/SaaS/), no-code-founders Slack, AI-founders Discord. These are not cold outbound-they are spaces where you have been showing up and building in public for months. | A B2B services founder closed her first paid pilot in 9 days from a single Indie Hackers post about her MVP. |
+
+If neither source applies, skip ahead - your first ten will come from [Chapter 5.5 cold outbound](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/) and the network outreach in this chapter is a smaller share of the work. The default sequence (network first, cold second) holds when the network is big enough to feed 30+ names. Below that, the order is the same but cold outbound starts sooner.
+
+## What to do next
+
+| Step | Action | Output |
+|---|---|---|
+| **1** | Open Google Sheet. Six columns: Name, Company, Role, Bucket, Relationship strength, Last contact date. Fill 50 names across the four buckets. | Complete 50-name list sorted by bucket |
+| **2** | Record one 90-second Loom showing the product and you on camera. | Single Loom link for all outreach messages |
+| **3** | Send the 5 champion messages and the 10 hot messages. Personalized opening for each. Same Loom link for all 15. | 15 outreach messages sent |
+| **4** | Send the 15 warm messages. Name-personalized opener, template-personalized body. | 15 additional messages sent |
+| **5** | Send the 20 cold messages once early replies are in. Hold the bottom 5 for a later batch to soften the volume. | 20 cold messages sent (15 in this batch, 5 held) |
+| **6** | Tally the responses. Book 3-5 demos. Annotate each row with response sentiment and date. | Demo calendar booked; ready for [Chapter 5.4](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) |
+
+The 50-name list template, the Loom outline, and the 4-message template variants (champion / hot / warm / cold) all ship in [the First-Paying-Customer Operating Kit](/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/).
+
+> **When the warm list is "exhausted" and it's time to switch to cold outbound.** Move to [Chapter 5.5](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/) when ALL three of these are true:
+> - All 50 names have been contacted (no "I'll get to the cold bucket later")
+> - At least 10 replies received (so you've sampled the warm motion's signal)
+> - Fewer than 3 demos booked AFTER at least half the responses are in, OR your reply rate on the last 10 messages has dropped below 10%
+>
+> Either of the last two triggers means the warm list is mined. If you only meet 2 of 3, hold; the warm motion is still working. If all 3 fire, the network has given what it can - switch.
+
+## Advanced (optional)
+
+> **Scaling the network motion to 100 customers:**
+> After you close your first 10 paid pilots from the personal network above,
+> layer on the [Y Combinator advice on early sales](https://www.ycombinator.com/library/6g-tactical-advice-for-the-first-sales-hire)
+> and [Paul Graham's "Do Things That Don't Scale"](http://paulgraham.com/ds.html).
+> The Stripe example in Graham's essay - where the Collison brothers installed the product in person for every early customer -
+> matches the relationship logic of this chapter exactly.
+> The main path gets you to 10 customers; the advanced version extends that relational rigor to 100.
+
+Your network is not begging-territory. It is the cheapest customer-acquisition motion you will ever run, and the people in it have already told you they have the problem.
+
+## Further reading
+
+- Lenny Rachitsky, [How today's fastest growing B2B businesses found their first ten customers](https://www.lennysnewsletter.com/p/how-todays-fastest-growing-b2b-businesses) - the source for the 60/35/5 breakdown and the company-by-company first-10 source data.
+- Lenny Rachitsky, [How to win your first 10 B2B customers](https://www.lennysnewsletter.com/p/how-to-win-your-first-10-b2b-customers) - the 7-step playbook from over a hundred B2B founders, including the must-have-user framing.
+- Paul Graham, [Do Things That Don't Scale](http://paulgraham.com/ds.html) - the founding text on early-customer manual recruitment, including the Stripe Collison-brothers installation example.
+- Steve Blank, [Customer Validation](https://steveblank.com/2010/04/12/why-startups-need-a-less-stupid-process/) - the academic frame underneath the practical playbook. Validation precedes scale.
+- First Round Capital, [The First-Round Sales Library](https://review.firstround.com/from-the-first-edition-of-the-founders-handbook-finding-your-first-customers/) - essays from founders on the first-10 motion, useful for sector-specific context.
+- Y Combinator Library, [Tactical advice for the first sales hire](https://www.ycombinator.com/library/6g-tactical-advice-for-the-first-sales-hire) - YC's collection on founder-led sales, including when the relationship motion has to give way to a structured pipeline.
+
+> **Done when:** 50 names are sorted into 4 buckets, your 90-second Loom is recorded, and the first 15 messages (champions + hot) are sent.
+>
+> **Next click:** [5.4 · Charge Before You Ship: The Paid Pilot Contract](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/)
+>
+> **If blocked:** If your warm network is under 15 names after filtering by your must-have segment, skip to Ch 5.5 cold outbound - your personal network won't produce your first customer. Use community fallbacks (YC batch, Indie Hackers, sector Slack) as warm-cold hybrid messages.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: 50-name network list: 5 champions (ex-colleagues who complained about reconciliation for years), 10 hot (controllers from AICPA conferences), 15 warm, 20 cold. Sends Monday. Gets 8 pilot conversations. 5 say yes.
+>
+> **Mia**: 50-name network list: 5 champions (teacher friends with dyslexic kids), 10 hot (parents from Facebook groups who posted about tutoring), 15 warm, 20 cold. Sends Monday. Gets 12 pilot conversations. 7 say yes.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/lenny-source-bars.svg b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/lenny-source-bars.svg
new file mode 100644
index 000000000..c379d8802
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/lenny-source-bars.svg
@@ -0,0 +1,47 @@
+
+  Where the first 10 B2B customers actually came from - Lenny's 21-company study
+  
+    
+  
+
+  "Where did your first 10 B2B customers come from?"
+  N=21 companies including Figma, Stripe, Slack, Airtable, Shopify, Notion, Front, Loom
+
+  
+  
+  ~60%
+  Personal network
+  friends, colleagues, former managers, prior employers
+
+  
+  
+  ~35%
+  Filtered cold outbound
+  LinkedIn DMs, targeted emails, conference handshakes
+
+  
+  
+  ~5%
+  Inbound / press / Product Hunt
+  the channel founders default to, against 1-in-20 odds
+
+  
+  
+  The non-technical-founder reflex is to skip the 60%.
+  "Friends are biased. Real customers come from real marketing."
+  Both halves of that sentence are wrong. The first 10 are a trust transfer.
+  You are not asking them to buy. You are asking them to be first.
+
+  
+  Source: Lenny Rachitsky, "How today's fastest growing B2B businesses found their first ten customers" (2021)
+
diff --git a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/network-buckets.svg b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/network-buckets.svg
new file mode 100644
index 000000000..0f03bf2c1
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/network-buckets.svg
@@ -0,0 +1,56 @@
+
+  The 50-name network list sorted into 4 outreach buckets
+  
+    
+  
+
+  The 50-name network list, sorted
+  Send Monday in this order. Champions before hot. Hot before warm. Cold is the last 20.
+
+  
+  
+  CHAMPIONS (5)
+  5 names
+  Already complained about this problem to you.
+  Will pick up your call. Will refer 2 more.
+  Send Monday 9 AM. Personalized Loom each.
+
+  
+  
+  HOT (10)
+  10 names
+  In the must-have segment from 8.1.
+  Knows you personally (recent contact <6 mo).
+  Send Monday afternoon. Loom + Calendly link.
+
+  
+  
+  WARM (15)
+  15 names
+  Adjacent. Knew you 6-24 months ago.
+  Reasonable bet they have the problem.
+  Send Tuesday. Template OK, name-personalized opener.
+
+  
+  
+  COLD (20)
+  20 names
+  Dormant LinkedIn 1st-degree.
+  Unclear if they have the problem.
+  Send Thursday. Hold the bottom 5 for week 2.
+
+  
+  
+  50 messages out by Friday EOD.
+  Founders consistently get 3-5 pilot conversations from this list. Champions deliver 60-70% of the early conversions.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/architecture-comparison.svg b/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/architecture-comparison.svg
new file mode 100644
index 000000000..8e62ee29d
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/architecture-comparison.svg
@@ -0,0 +1,102 @@
+
+  Healthy Rails monolith vs over-engineered microservice mess for a pre-Series-A startup
+  
+    
+  
+
+  HEALTHY (Rails monolith)
+  ✓
+
+  
+  Rails monolith · one repo
+
+  
+  Hotwire UI
+  (no separate SPA)
+
+  
+  ActiveRecord
+  (business logic)
+
+  
+  Postgres
+  (one DB)
+
+  
+  Sidekiq
+  (background jobs)
+
+  
+  Kamal deploy to
+  Hetzner / Heroku
+
+  1 repo · 1 full-stack dev ships
+  a feature idea-to-production
+
+  OVER-ENGINEERED
+  ✗
+
+  
+  React
+  frontend
+
+  
+  Node API
+  gateway
+
+  
+  Auth
+  microservice
+
+  
+  Elasticsearch
+  cluster
+
+  
+  Kafka
+  event bus
+
+  
+  "Platform team"
+  (2 FTE)
+
+  
+  Service mesh
+  (Istio)
+
+  
+  Redis
+  (3 clusters)
+
+  
+  Vault for
+  secrets
+
+  
+  
+  
+  
+  
+  
+  
+  
+
+  2 platform engineers · 0 features shipped
+  "We need to fix the architecture"
+
+  
+
+  Pre-Series-A, < $1M revenue: the boring choice on the left ships features. The exciting choice on the right ships plumbing.
+  DHH calls the left "the one-person framework." Founders we rescue arrived from the right.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/cover.png b/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/cover.png
new file mode 100644
index 000000000..96a4e634f
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/index.md b/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/index.md
new file mode 100644
index 000000000..f580919e6
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/index.md
@@ -0,0 +1,188 @@
+---
+title: "Glossary · Five Tech Words to Stop Nodding At"
+aliases: ["/blog/five-tech-words-stop-nodding-at/"]
+description: "Refactoring, Docker, tech debt, MVP, architecture - what each one actually means in plain English, plus one BS-detection question your dev shop will hate."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: five-tech-words-stop-nodding-at
+keywords:
+  - tech terms non technical founder
+  - refactoring meaning founders
+  - what is technical debt
+  - MVP definition startup
+  - software architecture for founders
+tags:
+  - founders
+  - non-technical-founder
+  - tech-literacy
+  - dev-shop-management
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "Glossary · Five Tech Words to Stop Nodding At"
+  og_description: "Refactoring, Docker, tech debt, MVP, architecture - what each one actually means in plain English, plus one BS-detection question your dev shop will hate."
+cover_image_alt: "JetThoughts blog cover for Five Tech Words to Stop Nodding At with the five terms printed on the right"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/"
+related_posts: false
+---
+
+> **Course glossary** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) course.
+> Vocabulary the rest of the course assumes you have. Skim once; come back when you hit a word you nodded at.
+
+A founder we picked up in Q1 2026 had nodded at the same word for fourteen months. Every Friday her contractor's PM said "we're refactoring the order flow" and she wrote it down. When her new fractional CTO finally read the repo, he came back with one line: nothing new had shipped to production since month three. **"Refactoring" had cost her $51K and a year of runway.** She had nodded because she did not know what else to do.
+
+Most non-technical founders learn engineering vocabulary under pressure, mid-meeting, with a bill on the table. The agency throws a word, the founder nods, the meeting moves on. By the time the founder figures out what the word actually meant, the next sprint is already approved.
+
+Below is the cheat sheet for the five words that hide the most invoices: refactoring, Docker, tech debt, MVP, architecture. For each you get a plain-English definition, the dishonest version your dev shop probably means when they say it, and one question you can ask in your next standup that the BS-version cannot answer.
+
+![Jargon translator: what your dev shop says vs what it usually means, for refactoring, Docker, tech debt, MVP, and architecture](jargon-translator.svg)
+
+## Why these five words now
+
+The vibe-coding wave made jargon worse. Agencies now stack three vocabularies on top of each other - the old enterprise one (microservices, Docker, refactoring), the AI one (agents, prompts, RAG, MCP), and the no-code one (workflows, automations, integrations). Founders walk into status meetings and hear words from all three at once. The founders we rescue in 2026 did not lose money on vocabulary - they lost it because they nodded at words the agency was using to mean something else. Veracode's 2025 study found 45% of LLM-generated code shipped at least one exploitable security flaw, and that kind of failure hides perfectly inside the word "refactoring" when nobody asks what was changed.
+
+## The Five Words
+
+### 🔧 1. Refactoring
+
+Changing the structure of code without changing what it does for the user. Martin Fowler, who wrote the book on it, [defines refactoring as a behavior-preserving transformation](https://martinfowler.com/bliki/DefinitionOfRefactoring.html) - same behavior before and after, just in cleaner lines. Inside an agency status call, the word usually means "we are rewriting something we shipped earlier instead of admitting we got it wrong the first time."
+
+> **🔍 BS-detection question:** *"Show me the user-facing thing that worked yesterday and still works today, but is now built on the new code."* A real refactor leaves at least one feature exactly as the user saw it. "We are still wiring it back up" means somebody is rewriting on your dime and calling it a tidy-up.
+
+In Rails terms, a real refactor splits a 400-line `OrdersController` into three smaller controllers while the Stripe webhook still hits the same URL and the test suite stays green. JT caps each refactor commit at [three lines of production code](/blog/refactor-step-tdd-three-line-discipline-ruby/) for that reason. A SaaS founder we picked up in Q4 2025 was billed $9K for a "checkout refactor" that turned out to be one merge commit of 3,800 lines, no tests, and the Stripe webhook secret hard-coded into the controller. The checkout broke on stage at her board demo.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TB
+    Start["OrdersController · 400 lines
messy, hard to read"]
+
+    Start --> RealQ{Real refactor?}
+    Start --> FakeQ{Fake refactor?}
+
+    RealQ --> R1["CartController · 120 lines"]
+    RealQ --> R2["CheckoutController · 140 lines"]
+    RealQ --> R3["ReceiptController · 130 lines"]
+
+    R1 --> RW["Same Stripe webhook URL
Same tests stay green"]
+    R2 --> RW
+    R3 --> RW
+
+    RW --> Win["✓ Same behavior for users
Cleaner structure
Three-line commit cap"]
+
+    FakeQ --> F1["OrdersController v2
3,800 lines, no tests"]
+    F1 --> F2["Stripe secret hard-coded
into controller"]
+    F2 --> Lose["✗ Checkout broke at board demo
$9K invoice for the rewrite"]
+
+    classDef good fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef bad  fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a
+    classDef neutral fill:#f5f5f5,stroke:#666,stroke-width:2px,color:#1a1a1a
+
+    class Start,RealQ,FakeQ neutral
+    class R1,R2,R3,RW,Win good
+    class F1,F2,Lose bad
+```
+
+### 🐳 2. Docker
+
+A way to package an app together with the operating-system pieces it needs, so it behaves the same on a developer's laptop, your staging server, and production. The official Docker docs call a container image [a lightweight, standalone, executable package](https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-an-image/) of code, runtime, tools, and settings. Docker is plumbing - useful and invisible when it works, expensive when "Docker work" becomes the headline two weeks running.
+
+Docker shows up in standup the same way every week, but the phrasing tells you whether it is real plumbing or a private cleanup project on your invoice.
+
+> **🔍 BS-detection question:** *"Which feature ships sooner because of this Docker work?"* If the answer is a feature name with a date, it's plumbing doing its job. If the answer is "better infrastructure," ask again next week.
+
+Listen for which side of this table your team lands on:
+
+| Phrase you hear | What it usually means |
+|---|---|
+| "New developer ran `docker compose up` and shipped a feature day one" | Healthy plumbing - the container is doing its job invisibly |
+| "Bumping the Postgres image so the staging migration unblocks" | A named, dated, founder-clickable outcome |
+| "Doing Docker work" (week 2 in a row, no clickable thing) | Something on the server broke, they cannot reproduce locally, they are fighting their own setup |
+| "We are containerizing the architecture" | Resume-driven plumbing - ask which feature ships sooner because of it |
+
+An EdTech founder we picked up paid $7K for "a Docker upgrade" across six weeks; the git history showed one commit changing a single line in `Dockerfile`. The real work was a Postgres migration that had broken staging the day the upgrade ticket opened. They labelled the sprint "Docker work" because it sounded more like infrastructure than "we shipped a bug."
+
+### 💸 3. Tech debt
+
+Code you shipped fast knowing you would have to come back and fix it. Ward Cunningham, who [coined the metaphor in 1992](https://martinfowler.com/bliki/TechnicalDebt.html), called it "shipping first time code is like going into debt" - useful as long as you pay it back promptly, expensive in compounding interest if you ignore it. From an agency, the term usually means "we wrote the original code badly and now we want you to pay us to fix what you already paid us to write."
+
+> **🔍 BS-detection question:** *"Which specific feature on next quarter's roadmap will be cheaper to ship after this debt is paid down, and by roughly how much?"* Real tech debt has a payoff number attached to a named feature. "It will help with everything" means nobody has measured anything yet.
+
+In Rails terms, healthy tech debt sounds specific: "extracting a `Billing::PlanCalculator` class out of `User` unblocks metered billing in Q3." Unhealthy tech debt sounds like "there is a lot of legacy in this codebase" - a feeling the team is asking you to fund. [LitsLink reports developers spend 42% of their time on technical debt and maintenance](https://litslink.com/blog/cost-of-outsourcing-software-development); the founders we rescue rarely see that line on an invoice. They see features taking twice as long as last quarter for no reason anyone can name. JT's [60-day playbook for slow engineering teams](/blog/fixing-slow-engineering-teams-an-extended/) starts by making that line visible.
+
+### 🚀 4. MVP
+
+Eric Ries, who popularised the term in The Lean Startup, defines MVP as [the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort](https://leanstartup.co/resources/articles/what-is-an-mvp/). Validated learning is the point - an MVP that nobody uses taught you nothing. Coming from an agency, the term usually means "the cheapest scope we can finish inside the budget you have left, even if it does not test the business question you actually need answered."
+
+The cleanest way to feel the difference is to look at two specs for the same MVP - the one a real product team writes and the one an agency writes when nobody asks Q4. A B2B HealthTech founder we shipped for in Q2 2025 had both on her desk:
+
+**Real MVP spec (one engineer, six working days, $14K):**
+- One Rails controller (`OnboardingsController`)
+- One Postgres table (`onboardings`)
+- One Stripe checkout link
+- The business question: do paid design partners come back the second week? (Yes - three of fifteen did.)
+
+**The agency version of the same MVP (six weeks, $58K quoted):**
+- Custom admin panel with role-based permissions
+- "White-labellable" theme system for future enterprise tenants
+- Microservices split: signup service + billing service + notification service
+- Two-week "foundations sprint" before any user-facing code
+- The business question: never specified - JT covers this exact failure mode in [our Quality Tax post](/blog/quality-tax-ai-mvp-cost/) on AI-built MVPs costing 2-3x the promised savings
+
+If the spec your team handed you reads like the second one:
+
+> **🔍 BS-detection question:** *"What business question will this MVP answer in the first 30 days after we ship, and how will we know we got an answer?"*
+>
+> That question cannot survive a "white-labellable theme system" on day one.
+
+### 🏗️ 5. Architecture
+
+The big-picture decisions about how the pieces of your app fit together: one big codebase or many small services, what database, what hosting, how the parts talk. Architecture is expensive to change later, which is why agencies love it and founders should be skeptical when it shows up early. From an agency, this often means "we want to use the resume-building tech we have not tried yet, and we will call it a foundational decision so you do not push back" - microservices, Kubernetes, custom event buses, and rewrites in a trendier framework all hide here.
+
+> **🔍 BS-detection question:** *"What are the three simplest architectures we could have picked, and why did we pick this one over them?"* A team that chose well can answer fast. A team that picked because the senior dev wanted to learn it cannot answer - the alternatives never made it into the conversation.
+
+A healthy architecture for a pre-Series-A Rails SaaS is one Rails monolith on Heroku or Hetzner, Postgres, Sidekiq, Hotwire for the UI - one repo, one developer ships a feature end-to-end. DHH calls this the [one-person framework](https://world.hey.com/dhh/the-one-person-framework-711e6318); Basecamp has run on the same shape since 2003. The over-engineered version stacks three Node services, a separate React frontend, an Elasticsearch cluster, a Kafka stream, and a "platform team" of two engineers maintaining plumbing instead of shipping product.
+
+![Healthy Rails monolith on the left (one repo, Hotwire, Postgres, Sidekiq, Kamal deploy) versus over-engineered microservice mess on the right (React frontend, Node gateway, Auth microservice, Elasticsearch, Kafka, service mesh, two-FTE platform team)](architecture-comparison.svg)
+
+## Idea-stage acronyms cheat sheet
+
+The five words above are dev-shop jargon - vocabulary you'll hit in Modules 4-5 (build and ship). Modules 1-3 (hypothesis, validate, design) have their own acronym soup. Skim the list below once; come back when an unfamiliar acronym shows up in a chapter:
+
+| Acronym | Plain English | Where it shows up |
+|---|---|---|
+| **ICP** | Ideal Customer Profile - the specific kind of person your hypothesis names | Ch 1.1, 2.3a |
+| **PMF** | Product-Market Fit - the survey question "would you be very disappointed if you could no longer use this?" 40%+ "very disappointed" = signal | Ch 5.1 |
+| **JTBD** | Jobs To Be Done - what a customer "hires" your product to do (instead of feature list) | Ch 3.1, 3.2 |
+| **MRR** / **ARR** | Monthly / Annual Recurring Revenue - what one customer pays per month or year | Ch 1.1, 5.4 |
+| **ACV** | Annual Contract Value - what one customer pays in year one (deposit math is 10-30% of ACV) | Ch 5.4 |
+| **CAC** / **LTV** | Customer Acquisition Cost / Lifetime Value - what you spend to land one customer vs what they pay you over their lifetime | Ch 5.2, 5.4 |
+| **DPA** | Design Partner Agreement - a one-page contract where a customer pays a deposit to test your product as a co-design partner | Ch 5.4 |
+| **SOW** | Statement of Work - the contract that defines what an agency is paid to deliver | _index, rescue chapters |
+| **PRD** / **Vibe PRD** | Product Requirements Document - the "Vibe" version is a one-pager an AI builder can act on, not a 30-page spec | Ch 3.1 |
+| **TAM** / **SAM** / **SOM** | Total / Serviceable / Serviceable-Obtainable Market - investor-pitch math, not builder math | _index pitch sections only |
+| **Pixel** | A small JavaScript tracking snippet from an ad platform (Meta/LinkedIn/Reddit) - paste it on your page and the platform learns who converted | Ch 1.2a |
+| **NPS** | Net Promoter Score - "how likely are you to recommend us?" 0-10 scale; less useful at idea stage than PMF | Ch 5.1 sidebar |
+| **Retention** | What % of users come back next week / next month - the only metric that proves the product solves a real problem | Ch 5.1 |
+| **Unit economics** | Revenue per customer minus cost to serve per customer - whether the math works at scale | Ch 1.1 Money lens |
+| **Runway** | Months of cash until you must show paying customers or close the company | Ch 4.1 Q3 |
+| **SWOT / PESTEL / Porter's Five Forces** | Three classic strategy-school checklists - VenturusAI runs all three on your hypothesis | Ch 1.1 sidebar |
+| **Wizard of Oz** | A no-code pattern - customer thinks software is running, but you do the work by hand behind the scenes to test demand before building | Ch 4.3a Concierge MVP |
+
+## What to do tomorrow
+
+Print the five BS-detection questions and bring one to your next standup - whichever word your team uses most. The texture of the answer (specific or evasive) tells you what you need to know in under thirty seconds. Forward this post to your fractional CTO or a developer-friend and ask: "Are these the right five words for me to be skeptical of, given my project?" Their list might swap one - either way, the conversation is the win.
+
+If your team's vocabulary makes you nervous, the next layer of the diagnostic is the [eight red flags checklist](/blog/dev-shop-red-flags-checklist/) and the [vibe-coding signals review](/blog/vibe-coding-crisis-ai-code-debt/) - same diagnostic, sharper edges. Want the same five-question shape applied to your weekly status meeting? See the [SCIPAB six-question script](/blog/scipab-tell-better-business-stories-startup-management/).
+
+## Further reading
+
+- Martin Fowler, [Definition of Refactoring](https://martinfowler.com/bliki/DefinitionOfRefactoring.html) - the canonical source on what refactoring is and is not.
+- Ward Cunningham via Martin Fowler, [Technical Debt](https://martinfowler.com/bliki/TechnicalDebt.html) - the original 1992 metaphor.
+- Eric Ries via Lean Startup Co., [What Is an MVP?](https://leanstartup.co/resources/articles/what-is-an-mvp/) - the validated-learning framing.
+- Docker, [What Is a Container Image?](https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-an-image/) - the official docs definition.
+- DHH, [The One Person Framework](https://world.hey.com/dhh/the-one-person-framework-711e6318) - the Rails case for keeping the architecture small.
+- Veracode, [GenAI Code Security Report 2025](https://www.veracode.com/blog/genai-code-security-report/) - 45% of LLM-generated code shipped at least one exploitable flaw.
+- LitsLink, [Cost of Outsourcing Software Development](https://litslink.com/blog/cost-of-outsourcing-software-development) - 42% of developer time goes to technical debt.
diff --git a/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/jargon-translator.svg b/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/jargon-translator.svg
new file mode 100644
index 000000000..957c5d906
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/jargon-translator.svg
@@ -0,0 +1,65 @@
+
+  Jargon Translator: What Your Dev Shop Says vs What It Usually Means
+  
+    
+  
+
+  WHAT THEY SAY
+  WHAT IT USUALLY MEANS
+
+  
+  "We're refactoring
+  the order flow"
+  
+  
+  
+  Rewriting code we shipped before,
+  on your dime, calling it tidy-up
+
+  
+  "We need a
+  Docker upgrade"
+  
+  
+  
+  Something on the server broke;
+  we can't reproduce locally
+
+  
+  "There's a lot of
+  tech debt to pay down"
+  
+  
+  
+  We wrote it badly. Pay us to fix
+  what you already paid us to write
+
+  
+  "Let's just ship
+  the MVP first"
+  
+  
+  
+  The cheapest scope we can finish
+  inside the budget you have left
+
+  
+  "We need to fix
+  the architecture"
+  
+  
+  
+  We want resume-building tech
+  the senior dev hasn't tried yet
+
+  Five words. Five invoices. Bring the question column to your next standup.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/cover.png b/content/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/cover.png
new file mode 100644
index 000000000..fc7950cf7
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/hypothesis-mad-libs.svg b/content/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/hypothesis-mad-libs.svg
new file mode 100644
index 000000000..3f210124a
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/hypothesis-mad-libs.svg
@@ -0,0 +1,19 @@
+
+  
+  If we help
+  
+  customer
+  solve
+  
+  problem
+  with
+  
+  approach
+  they'll choose it over
+  
+  competition
+  because
+  
+  differentiation
+  Five blanks. One sentence. No vagueness allowed.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/index.md b/content/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/index.md
new file mode 100644
index 000000000..37b29d052
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/index.md
@@ -0,0 +1,106 @@
+---
+title: "1.1 · Form Your Founding Hypothesis"
+aliases: ["/blog/form-your-founding-hypothesis-90-minute-sprint/"]
+description: "Write a one-sentence Founding Hypothesis you can falsify in five interviews. The cheapest test in the course."
+date: 2026-05-13
+draft: true
+course_chapter: false
+author: "JetThoughts Team"
+slug: form-your-founding-hypothesis-90-minute-sprint
+keywords:
+  - founding hypothesis template
+  - foundation sprint solo founder
+  - hypothesis before customer interviews
+tags:
+  - founders
+  - non-technical-founder
+  - hypothesis
+  - module-1
+categories: ["Founders"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/"
+related_posts: false
+---
+
+> **Module 1 · Lesson 1.1 · [CORE]** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a rough idea, instinct, or half-built MVP
+>
+> **Output:** a one-sentence Founding Hypothesis you can falsify in five interviews
+>
+> **Progress:** M1 · 1 of 5 · Results so far: none yet  --  this is the start
+
+---
+
+You have an idea. You've told five people about it. They all said "that sounds great"  --  which told you nothing. This lesson replaces polite nods with a single sentence you can actually test.
+
+After this lesson you will be able to: **write a single sentence about your idea that a stranger reads and either says "that's my problem" or "not me"  --  instead of "sounds great."**
+
+---
+
+A **Founding Hypothesis** is a Mad Libs sentence from Jake Knapp and John Zeratsky's *Click* (2025):
+
+> *"If we help [customer] solve [problem] with [approach], they'll choose it over [competition] because [differentiation]."*
+
+Five blanks. One sentence. The discipline is filling all five with specifics, not categories.
+
+**Why this works:** A vague sentence produces polite nods. A specific sentence produces pushback  --  and pushback is the signal:
+
+- ❌ *"We help small businesses save time with automation."*  --  Nobody can argue with this. Nobody can validate it either.
+- ✅ *"If we help solo chiropractors solve insurance-claim resubmission with a one-click resubmit, they pick it over billing services that take 14 days and charge 8% of recovered claims."*  --  A chiropractor either says "I dealt with this last Tuesday" or "that's not my problem." Both are useful.
+
+**What makes a blank specific:**
+
+- **[customer]**: the specific person  --  "solo chiropractors," not "small businesses"
+- **[problem]**: what they tried and failed at in the last 30 days, in their words
+- **[approach]**: the shape of your solution  --  "one-click resubmit," not "AI-powered workflow"
+- **[competition]**: what they currently use (a spreadsheet, a billing service, "doing nothing")
+- **[differentiation]**: why they'd switch  --  faster or cheaper, with numbers
+
+![5 blanks of the Mad Libs hypothesis sentence with a filled example below](hypothesis-mad-libs.svg)
+
+---
+
+## How to Score Your Hypothesis
+
+Score each lens 1-5. Be honest -- this is for you, not an investor deck.
+
+| Lens | Question (score 1-5) |
+|---|---|
+| **Customer** | Would they pick this on a Friday afternoon between meetings? |
+| **Pragmatic** | Can you ship something with what you have today? |
+| **Growth** | How does the customer hear about you, and how many are there? |
+| **Money** | Do the unit economics work? (Would one customer bring in more than they cost to serve? Leave blank if pre-revenue.) |
+
+---
+
+> **Write:**
+>
+> 1. Open a blank note. Write the Mad Libs frame at the top.
+> 2. Fill each blank with the most specific noun you can. If a blank says "small businesses," rewrite it until it names one person in one industry.
+> 3. Score your sentence using the four lenses above.
+> 4. **✅ Success check:** total ≥14/20 (or ≥11/15 if Money is blank) AND no lens below 2.
+> 5. Save the sentence to a Google Doc titled `Founding Hypothesis - [today's date]`. You'll paste it verbatim into Lessons 1.2a, 1.2c, 1.3, and every Module 2 interview.
+
+---
+
+**If your sentence scores below 14 or has a lens at 1.** **Why:** a blank is still a category, not a specific noun. **Fix:** find a verbatim quote from a real person complaining about this problem ([Reddit](https://www.reddit.com/), [G2 reviews](https://www.g2.com/), or a conversation you had). Replace your [problem] blank with their exact words. If you don't have a quote yet, leave the [problem] blank as a placeholder and complete 1.2a  --  you'll fill it after Module 2 interviews.
+
+**If every blank is specific but the sentence still sounds generic.** **Why:** you're writing in market-research language instead of customer language. **Fix:** read the sentence aloud to one stranger. If they say "wait, can you say that again," rewrite the blank they tripped on. Three reads is normal.
+
+---
+
+Read your sentence aloud to yourself. Which blank would you bet $100 is wrong? Write that blank's name at the bottom of your Google Doc. You'll test it first.
+
+---
+
+> **Done when:** one-sentence Founding Hypothesis written, scored ≥14/20 (or ≥11/15 if pre-revenue), no lens below 2, saved in your `Founder OS` folder.
+>
+> **Next click:** [1.2a · Build Your Smoke-Test Page](/course/tech-for-non-technical-founders-2026/smoke-test-build-page/)
+>
+> **If blocked:** see "If this fails" above. If you still can't fill the blanks, run the deep-research prompt on the [full sprint reference](/course/tech-for-non-technical-founders-2026/reference/hypothesis-sprint-full/) to find real customer complaints to anchor your blanks.
+
+---
+
+> **See it in action:** [Module 1 walkthrough: Mia builds TutorMatch](/course/tech-for-non-technical-founders-2026/module-1-walkthrough-mia/)
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) free curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/catching-the-lie.svg b/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/catching-the-lie.svg
new file mode 100644
index 000000000..9e49cf6e9
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/catching-the-lie.svg
@@ -0,0 +1,145 @@
+
+  One Loom for a small full-stack team versus five Looms for a microservice-detached team
+  
+    
+    
+      
+    
+    
+      
+    
+  
+
+  
+  
+  SMALL FULL-STACK TEAM · ONE LOOM
+
+  
+  
+    
+    
+    
+    Loom · 9:42
+    
+    
+    
+    
+    checkout flow · v1
+  
+
+  
+  staging.acme.app
+  /signup → /checkout → /receipt
+
+  
+  
+    
+    
+    
+    sign up
+    user enters
+
+    
+    add to cart
+    click button
+
+    
+    checkout
+    $1 stripe charge
+
+    
+    
+    receipt
+    email sent ✓
+  
+
+  one developer narrates end-to-end · 90 seconds · founder clicks along
+
+  
+  
+  MICROSERVICE-DETACHED TEAM · FIVE LOOMS
+
+  
+  
+    
+    
+      
+      
+      Loom · 6:18
+      
+      
+      order-service
+      orders.api.acme
+    
+
+    
+    
+      
+      
+      Loom · 4:51
+      
+      
+      billing-service
+      billing.api.acme
+    
+
+    
+    
+      
+      
+      Loom · 7:33
+      
+      
+      notifications
+      notify.api.acme
+    
+
+    
+    
+      
+      
+      Loom · 8:02
+      
+      
+      front-end
+      app.acme.dev
+    
+
+    
+    
+      
+      
+      Loom · 5:47
+      
+      
+      infra · gateway
+      gw.k8s.acme
+    
+  
+
+  
+  
+    
+    
+    
+    
+    
+  
+
+  "watch these five videos and we can sync about them next week"
+  this is what you are paying for
+
diff --git a/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/cover.png b/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/cover.png
new file mode 100644
index 000000000..3391cb30b
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/demo-rule.svg b/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/demo-rule.svg
new file mode 100644
index 000000000..0803814a5
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/demo-rule.svg
@@ -0,0 +1,137 @@
+
+  The Friday Demo Rule: 15 minutes, working software only, no slides or Jira screenshots
+  
+    
+  
+
+  
+  FRIDAY 4PM · ALLOWED IN THE ROOM
+
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    15:00
+    hard stop
+    
+    
+    
+  
+
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    staging.acme.app/checkout
+    
+    
+    
+    ✓ $1 test charge processed
+    order #1284 → paid
+    webhook fired ✓
+    receipt → founder@test.com
+    
+    
+    stripe sandbox
+    
+    
+  
+
+  
+  
+    
+    login (one message, one paste)
+    founder@test.com / demo1234
+  
+
+  
+  Working software only.
+  click everything they show you, during the call
+
+  
+  
+
+  
+  NOT ALLOWED IN THE ROOM
+
+  
+  
+    
+    Jira screenshot
+    
+    
+    
+    
+    To Do
+    In Progress
+    Done ×11
+    
+    
+  
+
+  
+  
+    
+    Figma frame
+    
+    
+    
+    
+    
+    
+  
+
+  
+  
+    
+    Slide deck · burndown chart
+    
+    
+    
+    
+    
+    
+  
+
+  
+  If a demo is not ready,
+  say so on Wednesday.
+
+  
+  
+  Friday Demo Rule · 15 minutes · Loom or live · working software only
+
diff --git a/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/index.md b/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/index.md
new file mode 100644
index 000000000..9b963078a
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/index.md
@@ -0,0 +1,133 @@
+---
+title: "6.3 · The Friday Demo Rule: 15 Min Truth Test"
+aliases: ["/blog/friday-demo-rule-founder-progress/"]
+description: "The 15-minute Friday ritual that surfaces fake progress in 4 weeks flat. Loom or live, working software only, no Jira screenshots, no slides, hard stop."
+date: 2026-05-18
+course_chapter: true
+author: "JetThoughts Team"
+slug: friday-demo-rule-founder-progress
+keywords:
+  - friday demo rule
+  - catch fake progress dev team
+  - non technical founder weekly demo
+  - working software demo founder
+  - dev team status call replacement
+tags:
+  - founders
+  - non-technical-founder
+  - course-companion
+  - oversight
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "6.3 · The Friday Demo Rule: 15 Min Truth Test"
+  og_description: "The 15-minute Friday ritual that surfaces fake progress in 4 weeks flat. Loom or live, working software only, no Jira screenshots, no slides, hard stop."
+cover_image_alt: "JetThoughts blog cover for The Friday Demo Rule showing a kitchen-timer set to 15 minutes next to a laptop screen with a clickable staging URL and a struck-through Jira screenshot"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/"
+related_posts: false
+course_nav: false
+---
+
+> **Chapter 5.3 · Step 2 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a team in place + a signed SOW
+>
+> **Output:** a weekly Friday ritual that surfaces fake progress within 4 weeks
+>
+**Supplementary content.** This chapter assumes you have a hired team. If you're still on the [self-serve path](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/), bookmark this and return when you graduate to a hired team.
+
+What were you actually shown on your last status call? A B2B founder we picked up in Q3 2026 sat with that question for ten minutes after a Tuesday call. Her notes from the call said: a burndown chart, a screenshot of a Jira board with eleven cards in "Done", a Figma frame her designer had updated overnight, and a verbal summary that started with "good progress this week." Nothing in her notes was a thing she could click. She had paid **$31K that month** for the team that ran the call, and the call had shown her zero working software.
+
+She wrote one Slack message that night: *"From now on we run a 15-minute Friday demo. Loom or live, your choice. Working software only. I want to click everything you show me."* By Friday of week 3, two of her four developers had quietly left the project; the lead admitted the checkout flow she had been tracking for six weeks was three Postman requests in a Notion doc and a Stripe sandbox key in someone's `.env`. She found that out in 15 minutes, on a recorded call, with no fight.
+
+## Why most weekly status calls fail
+
+The standard weekly call is a slide deck and a Jira tour. The agency lead picks the artifacts, controls the screen, and narrates the week. You leave the call oriented but not informed. Whether anything shipped is a separate question, and the format does not force it. [Atlassian's own writeup on demo meetings](https://www.atlassian.com/agile/scrum/sprint-reviews) flags exactly this drift: status reviews collapse into status theatre when the agenda is "report progress" instead of "show working software." Make the format about clicking, not slides, and the failure modes get loud fast.
+
+## The Friday Demo Rule
+
+One meeting per week. 15 minutes. Friday at 4pm in your timezone. Loom (a recorded video) or live screenshare. Recorded if it is Loom. The rules are not negotiable, which is the whole point.
+
+**Working software only.** Figma frames, Jira screenshots, burndown charts, and "here is what we are about to start" all stay out of the meeting. If the team cannot show you a thing you can click, the answer to "did anything ship this week?" is no - and you got that answer in 15 minutes instead of three sprints.
+
+**You attend with one question in your head.** Can I click everything they show me? You open your laptop, paste each staging URL into your browser as the developer mentions it, and try to reach the screen they just described. If the URL throws a 500 or asks for a login you do not have, interrupt and ask why. Do not save the question for Monday. The point of the recording is so you have proof; the point of the live attendance is so you catch the lie in real time.
+
+**Hard stop at 15 minutes.** Founders we have rescued who let the demo drift to 45 minutes lose the discipline within a month. The cap is what forces the team to pre-stage clickable URLs instead of debugging on the call. If the team needs longer than 15 minutes to show one week of work, something is wrong - and it is usually that nothing is on staging.
+
+![Kitchen-timer set to 15:00 next to a laptop displaying a clickable staging URL with admin login credentials and a passing $1 Stripe test transaction; struck-through icons of a Jira board, a Figma frame, and a slide deck stacked on the right with the caption "not allowed in the room"](demo-rule.svg)
+
+## The 7 questions the team answers
+
+The full Monday-morning Slack template lives in the [Friday Demo Template](/course/tech-for-non-technical-founders-2026/friday-demo-template/) - copy and paste it into Slack on Monday so the team knows the questions before Friday. The seven questions, in the order you ask them on the call:
+
+1. **What shipped this week?** Show the staging URL of one thing the founder can click.
+2. **What did the user do?** Walk the feature as the user touches it - click the buttons, submit the form, show the success and failure screens.
+3. **Where is it live for me?** Send the URL and the test login in one message; the founder repeats the demo on her own laptop within five minutes.
+4. **What did we cut to ship that?** Name what was simplified, removed, or postponed. If nothing was cut, the scope was wrong or the work is not done.
+5. **What is in review but not shipped?** Open pull request, named reviewer. If nobody reviewed it, say so.
+6. **What is blocked, and on whom?** Named person, the answer the team needs from you, the deadline.
+7. **What is the one thing I should worry about for next week?** Not a status update - the actual thing keeping the lead up at night.
+
+The order matters. Question 1 sets the frame: working software, not process. Question 4 catches over-engineering and quiet descopes. Question 7 surfaces real risk before it shows up as a missed sprint. The full template page has the copy-paste Slack message, the hard rules, and the "what to do during the call" section - bookmark it.
+
+## What good looks like vs what bad looks like
+
+The texture of the answers is the signal. Every question has a pass shape and a fail shape, and after four Fridays you will know your team's pattern by sound. For the verbatim Good/Bad examples per question, see the [Friday Demo Template](/course/tech-for-non-technical-founders-2026/friday-demo-template/).
+
+The two patterns worth knowing in your head, not on a template:
+
+**Verb-only answers on Q1.** Bad answers describe completion as a feeling ("we finished the Stripe integration"). Good answers point at a URL and walk you to it. If your team gives you Q1 as a verb without a clickable thing, write it down - three weeks of verb-only Q1 answers is a stalled project wearing busy clothes.
+
+**Same-name reviewer on Q5.** If the same name keeps appearing as the only reviewer for every pull request, you have a bus factor of one. [Will Larson on engineering anti-patterns](https://review.firstround.com/unexpected-anti-patterns-for-engineering-leaders-lessons-from-stripe-uber-carta/) treats the pull request funnel as the load-bearing signal for engineering health. The Friday demo is where you watch that funnel from outside the system. JT's [eight red flags checklist](/blog/dev-shop-red-flags-checklist/) describes the bus-factor failure mode in plain English.
+
+A founder we worked with sat through six weeks of "I will send the URL after the call" before her fractional CTO clicked the link the team finally sent and got a 404. The CTO's first audit found the staging environment had been broken for two months and nobody had escalated it.
+
+```mermaid
+
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#f5f5f5', 'primaryBorderColor':'#666', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+
+flowchart LR
+
+    Mon([Monday 9am
Founder posts the
7-question template
in #dev Slack]) --> Tue([Tuesday-Thursday
Team builds + reviews
against the questions])
+    Tue --> Wed{Wednesday EOD
Anything not
going to be ready?}
+    Wed -->|Yes| Replan([Team replans
before Friday])
+    Wed -->|No| Fri([Friday 4pm
15-min Loom or live
working software only])
+    Replan --> Fri
+    Fri --> Click([Founder clicks
every staging URL
during the call])
+    Click --> Forward([Forward Loom URL
to your inbox
same evening])
+    Forward --> Score{After 4 weeks
review the pattern}
+    Score -->|4 of 4 demos clickable| Healthy([Cadence works
continue weekly])
+    Score -->|2 of 4 or fewer| Investigate([Run the
oversight audit
standup + report + spaceship])
+    classDef good fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef bad  fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a
+    classDef neutral fill:#f5f5f5,stroke:#666,stroke-width:2px,color:#1a1a1a
+    class Mon,Tue,Fri,Click,Forward neutral
+    class Wed,Score neutral
+    class Replan,Healthy good
+    class Investigate bad
+
+```
+
+## What to do tomorrow
+
+Three actions, in order:
+
+1. **Block 15 minutes on your calendar this Friday at 4pm.** Title it "Friday Demo - Working Software Only." Add your team. No agenda doc - the agenda is the seven questions, and they are the same every week.
+2. **Check your last four weekly status calls in your notes app.** Out of those four calls, how many produced a staging URL you actually clicked from your own laptop within 24 hours of the call? If the answer is zero or one, the problem is not your team's effort - it is that the format never asked them for working software. The Friday demo asks for it every week.
+3. **Download the [Friday Demo Template](/course/tech-for-non-technical-founders-2026/friday-demo-template/) and send to your team Monday morning.** The template page has the copy-paste Slack message, the seven questions in order, the hard rules, and the "what good vs bad looks like" examples for each question. Do not paraphrase the rules - paste them. Teams respect the hard structure more than a polite request they can ignore.
+
+By Friday of week 4, you will know whether your dev team is shipping or stalling, and you will not have read a line of code.
+
+## Further reading
+
+- Atlassian, [Sprint Reviews and Demos](https://www.atlassian.com/agile/scrum/sprint-reviews) - the canonical reference on demo meetings and how they drift into status theatre when nobody asks for working software.
+- Eric Ries via Lean Startup Co., [What Is an MVP?](https://leanstartup.co/resources/articles/what-is-an-mvp/) - the validated-learning framing that makes "what did we cut?" a real product question.
+- Will Larson (via First Round Review), [Engineering leadership anti-patterns from Stripe, Uber, Carta](https://review.firstround.com/unexpected-anti-patterns-for-engineering-leaders-lessons-from-stripe-uber-carta/) - on the pull request funnel as the load-bearing signal a Friday demo surfaces from outside the system.
+- DHH, [The One Person Framework](https://world.hey.com/dhh/the-one-person-framework-711e6318) - the Rails case for full-stack developers shipping end-to-end and demoing in one Loom.
+- Martin Fowler, [It's Not Just Standing Up: Patterns for Daily Standup Meetings](https://martinfowler.com/articles/itsNotJustStandingUp.html) - a deep practitioner reference on the pattern of meetings that produce visible working software vs the ones that produce status updates.
+- Atlassian, [Definition of Done](https://www.atlassian.com/agile/project-management/definition-of-done) - the "is it actually done" reference that aligns with the Friday demo's working-software-only rule.
+
+---
+
+Built by JetThoughts as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum. Authored by the JetThoughts team.
diff --git a/content/course/tech-for-non-technical-founders-2026/friday-demo-template/cover.png b/content/course/tech-for-non-technical-founders-2026/friday-demo-template/cover.png
new file mode 100644
index 000000000..e505047e5
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/friday-demo-template/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/friday-demo-template/index.md b/content/course/tech-for-non-technical-founders-2026/friday-demo-template/index.md
new file mode 100644
index 000000000..e23aca999
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/friday-demo-template/index.md
@@ -0,0 +1,134 @@
+---
+title: "Friday Demo Template: Catch Fake Progress in 15 Minutes"
+aliases: ["/blog/friday-demo-template/"]
+description: "The 15-minute Friday script that catches fake progress before it costs you a sprint. Copy/paste into Slack on Monday. Run Friday at 4pm."
+date: 2026-05-13
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: friday-demo-template
+keywords:
+  - friday demo dev team
+  - founder catch fake progress
+  - weekly dev demo script
+  - non technical founder oversight
+  - dev team accountability template
+tags:
+  - founders
+  - non-technical-founder
+  - template
+  - course-companion
+  - oversight
+categories: ["Templates"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/friday-demo-template/"
+related_posts: false
+---
+
+📋 Template companion to the Oversight Rhythm sub-section (Chapter 5.2) of the [From Idea to First Paying Customer course](/course/tech-for-non-technical-founders-2026/). Send to your team Monday. Run Friday at 4pm.
+
+# The Friday Demo Template
+
+A 15-minute Friday script that catches fake progress before it costs you a sprint.
+
+By Friday of week 4 you will know whether your dev team is shipping or stalling. You will not have read a line of code. You will have watched four short demos and clicked four staging URLs. That is the entire system.
+
+> **7 questions, asked in order:** (1) What shipped? (2) What did the user do? (3) Where is it live for me? (4) What did we cut? (5) What's in review? (6) What's blocked? (7) What should I worry about next week?
+
+## Why this exists
+
+A founder we worked with last year was four months and $62K into a six-week MVP. Jira showed nine tickets closed that week. When she asked the team to demo the checkout flow, the lead developer said "it's behind a feature flag, give us until Monday." Monday came: the flag had been on for three weeks. The page threw a 500 on every click. None of the three developers had opened it themselves.
+
+## How to use it
+
+Send the template to your team **Monday morning**, no debate. Frame it as visibility, not micromanagement: you are asking them to show you one working thing per week.
+
+Run the demo **Friday at 4pm**. Fifteen minutes, hard stop. Loom (a recorded video) or live screenshare. You attend with one question in your head: "Can I click everything they show me?" Forward every Loom URL to your own inbox the same evening - three weeks of these become your record when the team disputes the timeline.
+
+## The template (copy and paste this into Slack on Monday)
+
+> Hey team,
+>
+> Starting this Friday at 4pm we are running a 15-minute weekly demo. Loom or live screenshare, your choice. Same questions every week so you can plan around it.
+>
+> Please cover, in this order:
+>
+> 1. **What shipped this week?** Show me the staging URL of one thing I can click. If it is not on staging yet, it does not count as shipped.
+> 2. **What did the user do?** Walk me through the feature as the user touches it. Click the buttons. Submit the form. Show me the success screen and the failure screen.
+> 3. **Where is it live for me?** Send me the URL and the test login in the same message. I should be able to repeat your demo from my laptop within five minutes.
+> 4. **What did we cut to ship that?** Tell me what you simplified, removed, or postponed. If nothing was cut, the scope was probably wrong or the work is not done.
+> 5. **What is in review but not shipped?** Show me the open pull request and tell me who reviewed it. If nobody reviewed it, say so.
+> 6. **What is blocked, and on whom?** Name the person, the answer you need from me, and the deadline you need it by.
+> 7. **What is the one thing I should worry about for next week?** Not a status update. The actual thing keeping you up at night.
+>
+> Hard rules: 15 minutes total, recorded if it is Loom, no slides, no Figma mockups, no Jira screenshots. Working software only. If a demo is not ready, say so on Wednesday so we can replan.
+>
+> Thanks,
+> [Your name]
+
+Do not soften it. Do not add "if you have time" or "would be nice to". The team will respect the hard structure more than a polite request they can ignore.
+
+## What good looks like vs. what bad looks like
+
+**Q1 - what shipped this week?**
+
+> Bad: "We finished the Stripe integration."
+>
+> Good: "Live at staging.app/checkout. Here is a $1 test transaction I just ran. The webhook fired, the order moved to paid, the receipt landed in your inbox."
+
+Bad answers describe completion as a feeling. Good answers point at evidence and walk you to it.
+
+**Q3 - where is it live for me?**
+
+> Bad: "I will send you a Loom of it after the demo."
+>
+> Good: "staging.acme.app/dashboard. Login: founder@test.com / demo1234."
+
+You should be able to click the thing yourself within five minutes. If you cannot, you do not have admin access, the staging environment does not exist, or the feature is not actually deployed. All three are emergencies.
+
+**Q4 - what did we cut to ship that?**
+
+> Bad: "Nothing, we built everything in the spec."
+>
+> Good: "We cut the admin override screen. You will not be able to edit a user's plan from the dashboard until next sprint. Manual fix is to email me, takes me three minutes."
+
+This is the over-engineering check. If your team never cuts anything, they are either building twice as much as needed or they are lying about what is done.
+
+**Q5 - what is in review but not shipped?**
+
+> Bad: "A few things are in PR, I can send you the list later."
+>
+> Good: "PR #847 - signup rate limiting. Marcus reviewed it Tuesday, three changes requested, will merge Monday. PR #851 - admin search. Nobody has reviewed it yet because Marcus is on vacation."
+
+If the same name keeps appearing as the only reviewer, you have a single point of failure - the [JetThoughts red-flags checklist](/blog/dev-shop-red-flags-checklist/) calls this bus factor of one.
+
+## Three things to do during the call
+
+1. **Click the staging URL while they are talking.** Open it on your laptop the moment they share it. If you get a 500, a login error, or "this page can't be reached", interrupt and ask. Do not wait until Monday to find out the URL was a screenshot.
+2. **Ask one follow-up per question.** Not three. If your follow-up gets a paragraph of jargon back, that is information. Save it for next time.
+3. **Write down one number per demo.** "PR #847", "$1 transaction", "47 paying users on the new flow". Three months of one-number receipts beat any retrospective the agency will run on themselves.
+
+## What to do after the call
+
+Forward the Loom URL to your own inbox with the date in the subject line. After three months you have a video record nobody on the team controls.
+
+> **📧 Copy-pasteable follow-up email - forward after each demo:**
+>
+> Subject: `Friday demo - [date] - [one-line summary]`
+>
+> Forwarding the Loom from today's demo. [One sentence on what shipped.] [One sentence on what's blocked.] [One sentence on what's next.]
+>
+> Archive for the Friday demo folder.
+
+If a demo gets skipped or rescheduled twice, write a one-line message:
+
+> **📧 Copy-pasteable 'skipped twice' message:**
+>
+> "Friday demo is the one meeting we do not move. Next Friday at 4pm, what will I see?"
+
+Hold the slot.
+
+If you have watched four Fridays and you still cannot click anything from your own laptop, the problem is not the demo format. Read [our 8 red flags checklist](/blog/dev-shop-red-flags-checklist/) and start the conversation about access, ownership, and code review.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/bad-vs-good-email.svg b/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/bad-vs-good-email.svg
new file mode 100644
index 000000000..61060fed7
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/bad-vs-good-email.svg
@@ -0,0 +1,69 @@
+
+  Bad vs Good: contractor email on the AWS root account compared with the founder's company email on the same account
+  
+    
+  
+
+  AWS root account - who owns the email?
+
+  
+  
+  
+  BAD
+  Hostage situation
+
+  Account email
+  aws@bigdevshop.com
+  
+
+  Billing card
+  **** 4421 (agency AmEx)
+  
+
+  Your access
+  IAM user, never logged into root
+  
+
+  Recovery if they ghost
+  10 minutes for them to lock you out.
+  3-5 business days for AWS support to
+  recover with incorporation papers.
+
+  
+  
+  
+  GOOD
+  You hold the keys
+
+  Account email
+  aws@yourcompany.com
+  
+
+  Billing card
+  **** 0987 (your company AmEx)
+  
+
+  Your access
+  Root password in 1Password + MFA
+  
+
+  Recovery if they ghost
+  Revoke their IAM user. Rotate the
+  root password. Ship a hotfix the same
+  afternoon. They never had the key.
+
+  Same account. Same software. One field changes. Everything downstream changes with it.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/cover.png b/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/cover.png
new file mode 100644
index 000000000..35a5cf40f
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/index.md b/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/index.md
new file mode 100644
index 000000000..7321f9bc5
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/index.md
@@ -0,0 +1,208 @@
+---
+title: "4.2 · Who Owns Your GitHub, AWS, and Database?"
+aliases: ["/blog/github-aws-database-ownership-checklist/"]
+description: "If a contractor's email sits on your AWS root account, you do not actually own your company. A 45-minute Friday audit surfaces every hostage credential."
+date: 2026-05-13
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: github-aws-database-ownership-checklist
+keywords:
+  - aws root account ownership
+  - github org ownership founder
+  - database password ownership
+  - non technical founder ownership audit
+  - dev shop hostage situation
+tags:
+  - founders
+  - non-technical-founder
+  - course-companion
+  - oversight
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "4.2 · Who Owns Your GitHub, AWS, and Database?"
+  og_description: "If a contractor's email sits on your AWS root account, you do not actually own your company. A 45-minute Friday audit surfaces every hostage credential."
+cover_image_alt: "JetThoughts blog cover showing four labeled boxes - Code, Cloud, Secrets, Domain - with red question marks over three of them and one founder email in green"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/"
+related_posts: false
+---
+
+> **Module 4 · Step 2 of 4** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a build-path decision from Chapter 4.1 (self-serve or hire)
+>
+> **Output:** a Day-1 audit confirming you own your code, cloud, and domain before the build starts (or a recovery plan if you don't)
+
+> **TL;DR:** If a contractor's email sits on your AWS root account, you don't own your company. A 45-minute Friday audit surfaces every hostage credential before the build starts.
+
+> **If you signed up for Lovable + Supabase + Stripe yourself (the default Path 2 from Ch 4.1), here is your 5-minute self-check** - the rest of this chapter applies the day you hire a contractor:
+>
+> 1. **GitHub**: account in your name, your email, your password manager. (If you used Lovable's "sign in with Google," your Google account IS the GitHub owner. Confirm.)
+> 2. **Lovable + Supabase + Stripe**: signed up with your personal email, billed to your card. (Not a co-founder's, not a friend's.)
+> 3. **Domain (if purchased)**: registered to your name in your registrar account.
+> 4. **No shared admin passwords**: only you have the master password to each.
+> 5. **2FA on all four** (GitHub, Supabase, Stripe, domain registrar): turned on.
+>
+> Pass all 5? You can skim the rest of the chapter as a future reference. Fail any? Fix that one before continuing - the 12-item audit below is the deeper version.
+
+This audit applies BEFORE you hand over a credit card to your first contractor, agency, or Fractional CTO. It also works as a post-hire rescue, but the cheaper time to run it is on Day 1 - not month 14, when the story below kicks off.
+
+Fourteen months of **$23K monthly invoices**, a Delaware C-corp, 1,800 paying clinics, a Stripe account in the founder's name - and the AWS root password sitting in the agency owner's personal Gmail. The first hour of that health-tech rescue last Q4 was not technical. It was three back-and-forth emails to the agency owner asking him to please change the root account email and send the new password to a Notion doc he could not see. He took six days.
+
+*Ownership*: who controls the GitHub org, the AWS root account, the domain registrar, and the prod database. A Day-1 audit means you can fire your team Tuesday without losing the codebase Wednesday.
+
+Open the AWS console. Top-right corner. Click your account name. Read the email address on the root user. Whose inbox does that land in tonight?
+
+## The 2026 hostage situation looks different
+
+The agencies that hold founders hostage in 2026 are not the same shops that did it in 2020. AI-augmented contractors spin up your entire infrastructure during the Cursor or Claude Code session on Day 1: GitHub org, AWS account, Vercel project, Supabase database, Stripe integration, Sentry, PostHog. They use whatever email was already logged in. Usually their own. The senior dev who set everything up moves to another client in month four. The junior who inherits your project does not know which credentials live where. Six months later, you are paying for accounts that nobody on the current team can administer.
+
+There is a second pattern, even more common: the **cloud-default-account problem**. A contractor opens a fresh AWS account using the company credit card you handed them, then sets the root email to a shared `dev@` mailbox that the agency owns. AWS treats whichever email is on the root as the legal account holder. Your incorporation paperwork is irrelevant if the root email belongs to someone else. [AWS's own root user documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) is blunt about this: the root user has unrestricted access, and recovering control without the root credentials means filing a support ticket with corporate documents and waiting days.
+
+The financial damage is rarely the headline number on the agency invoice. It is the day production breaks at 9pm and you cannot push a fix because you cannot read the prod database password. The week lost to AWS support recovery while your customers see a maintenance page. An $11K legal retainer when the agency stops answering. None of that hits the budget line that says "engineering."
+
+![Four labeled zones a non-technical founder must own: Code (GitHub org and repos), Cloud (AWS root and billing), Secrets (database credentials and API keys), and Domain (registrar and DNS). Each zone shows the failure mode if a contractor email is on it instead of the founder.](ownership-zones.svg)
+
+## What good looks like vs what bad looks like
+
+Every item rhymes the same way when it passes: an email on a domain you control, billing on a card you own, MFA on a phone in your pocket, and a password in a vault you can read. Failure rhymes too: somebody else's email, somebody else's card, and "let me ask Marcus" as the answer to "who can rotate this?"
+
+Three pairs that come up most often in rescue audits.
+
+**Item #4 - AWS root account email**
+
+> Bad: Root email is `aws@bigdevshop.com`. The bill goes to their AmEx ending 4421. You have an IAM user but have never logged in as root.
+> Good: Root email is `aws@mycompany.com`. The password is in your 1Password. MFA is on your phone with backup codes in your office safe. Bill goes to your company card.
+
+If the agency controls the root email, AWS support will treat them as the account holder, not you. The incorporation paperwork in your filing cabinet does not matter to AWS until support has worked through their recovery process - which takes 3-5 business days after you have proven who you are.
+
+![Side-by-side panel showing the AWS root account fields - account email, billing card, your access level, recovery time if the agency disappears - in the bad scenario where everything points at the agency, and the good scenario where everything points at the founder. The Bad column shows aws@bigdevshop.com, agency AmEx, IAM-only access, and a 3-5 day support recovery. The Good column shows aws@mycompany.com, founder AmEx, root password in 1Password with MFA, and same-day recovery by revoking the contractor.](bad-vs-good-email.svg)
+
+**Item #7 - Production database password**
+
+> Bad: "Marcus has it. Slack him and he can DM it to you."
+> Good: "I opened AWS Secrets Manager just now and read it myself. I rotated it once in March when we offboarded the previous DBA."
+
+The Marcus answer is the hostage answer. It does not matter whether Marcus is honest, kind, or available - one person holding the prod DB password is one person away from a production outage you cannot fix. Firing Marcus does not fix it. Putting the credential in a store you administer, with Marcus pulling read access from there, does.
+
+**Item #10 - Domain registrar**
+
+> Bad: Domain renewal notices arrive at `dev@theiragency.com`. You have never logged into Namecheap or GoDaddy in your life.
+> Good: Logged into the registrar with your account. WHOIS shows your name. Auto-renew is on, charged to your card, and you have your phone scanned for MFA.
+
+A domain transfer is the slowest recovery on the list. [ICANN's transfer policy](https://www.icann.org/resources/pages/transfers-2024-en) requires a five-day approval window after the auth code is released, and many registrars add a 60-day post-registration lockout window during which transfers cannot start at all. If the agency holds your domain and refuses to cooperate, your customers are looking at a static placeholder for two weeks while you escalate to ICANN's transfer dispute resolution.
+
+## The 12 items, in four zones (fill-in-the-blank reference)
+
+Those three pairs anchor the pattern; the table below is the fill-in-the-blank version - 12 items, the exact pass criterion for each, the recovery steps when one fails. The full audit lives at the [GitHub / AWS / Database Ownership Checklist](/course/tech-for-non-technical-founders-2026/ownership-checklist/).
+
+> **Acronyms in the table below:** IAM = Identity and Access Management (AWS's user-permissions system, separate from the root account). MFA = Multi-Factor Authentication (the 6-digit code your phone shows when you log in - a second proof beyond your password). WHOIS = the public registry that shows who legally owns a domain. ICANN = the global body that enforces domain-transfer rules (the source of the 14-day wait if your registrar lock isn't released).
+
+| Zone | Item | Pass Criterion |
+|---|---|---|
+| **Code** | GitHub org owner | Your company email, not the agency's |
+| | Repo collaborators | Can be removed by you alone, without permission |
+| | Branch protection on main | Enabled and you can override in an emergency |
+| **Cloud** | AWS root account email | Sits on a domain you control |
+| | Billing card | Yours and you can download every invoice yourself |
+| | IAM admin user | In your name with MFA on, separate from root |
+| **Secrets and database** | Production DB credentials | Readable by you tonight without paging an engineer |
+| | Secrets store | (Secrets Manager, Vault, Doppler) administered by you |
+| | Database backups | Running nightly with a restore runbook you can execute |
+| **Domain and external services** | Domain registrar | WHOIS shows your name and your renewal email |
+| | DNS provider | Logged in under your account with MFA, ready to add an A record now |
+| | Third-party API keys | (Stripe, SendGrid, Twilio, OpenAI, Plaid) on your account, your card |
+
+Two of those twelve are existential. AWS root email controls whether the agency can lock you out in ten minutes. Domain registrar turns into a 14-day ICANN-mandated wait if the agency will not release the auth code. The other ten matter; these two end the company if they go wrong.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#f5f5f5', 'primaryBorderColor':'#666', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    Start(["Friday afternoon. Alone.
Credit card + Notion doc."])
+    Start --> Code{Code: Are you
GitHub org Owner?}
+    Code -->|Yes| Cloud{Cloud: Is the AWS
root email yours?}
+    Code -->|No| FixCode[Slack the lead engineer.
Self-serve org transfer]
+
+    Cloud -->|Yes, with MFA| Sec{Secrets: Can you read
the prod DB password
tonight without asking?}
+    Cloud -->|No| FixCloud[Self-serve email change
or 3-5 day AWS support
recovery with corp docs]
+
+    Sec -->|Yes, from your vault| Dom{Domain: Does WHOIS
show your name +
renewal email?}
+    Sec -->|"'Marcus has it'"| FixSec[Set up Secrets Manager
or 1Password vault tonight.
Migrate this sprint]
+
+    Dom -->|Yes, on your card| Pass[Audit clean.
Quarterly recurring block.
Email investor / board.]
+    Dom -->|No| FixDom[Initiate registrar transfer.
Budget 14 days minimum.
Escalate to ICANN if blocked]
+
+    FixCode --> Recovery[Recovery plan
started this Friday]
+    FixCloud --> Recovery
+    FixSec --> Recovery
+    FixDom --> Recovery
+
+    Recovery --> Escalate{Did the agency
cooperate within 7 days
code / 14 days cloud /
auth code at all?}
+    Escalate -->|Yes| Pass
+    Escalate -->|No| Lawyer[Retain lawyer.
$2K-$5K beats
a stalled checkout]
+
+    classDef good fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef bad  fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a
+    classDef neutral fill:#f5f5f5,stroke:#666,stroke-width:2px,color:#1a1a1a
+    classDef start fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a
+
+    class Start start
+    class Code,Cloud,Sec,Dom,Escalate neutral
+    class Pass good
+    class FixCode,FixCloud,FixSec,FixDom,Recovery,Lawyer bad
+```
+
+## When the audit fails: a recovery plan that takes weeks, not months
+
+Most audit failures are sloppy Day-1 setup, not malice. The agency was moving fast in the kickoff sprint, used whatever email was logged in, and nobody went back to clean it up. The fix follows three steps in this order, and the order matters.
+
+| Step | What to do | Cadence |
+|---|---|---|
+| 1: Stop the bleeding | Get yourself an admin path into every system the agency controls. AWS root password reset to your email. Your name added as GitHub org owner alongside theirs. Your card added as the primary on Stripe, SendGrid, and OpenAI. Do this before the next sprint so you have a quiet window before anyone notices. | This sprint |
+| 2: Extract the IP | Pull a fresh clone of every repo to a private GitHub org under your account. Export the database to an S3 bucket on an AWS account in your name. Document where every secret currently lives and where it will live after the migration. Work patiently on the existing setup. | Next sprint |
+| 3: Legal escalation, only if needed | A reasonable cooperation window looks like 7 days for GitHub org transfer, 14 days for AWS root, and the auth code released at all for the domain. If they stall, retain a lawyer for a one-time $2K-$5K letter referencing your contract's IP-assignment clause. | 7-14 days (or legal engagement) |
+
+The artifact at [/course/tech-for-non-technical-founders-2026/ownership-checklist/](/course/tech-for-non-technical-founders-2026/ownership-checklist/) walks the exact recovery sequence per item, including the AWS support phone script and the registrar auth-code request template.
+
+## What to do tomorrow
+
+| Step | Action |
+|---|---|
+| **Block the calendar** | Calendar invite to yourself titled "Ownership audit." Treat it like an investor meeting. No interruptions. Coffee on, phone on Do Not Disturb. |
+| **Start with AWS** | Open the AWS console first. Top-right, click the account name, click Account. Read the root user email. If it is not on a domain you control, that one item is your audit's first failure. |
+| **Run the 12-item audit** | Download the [GitHub / AWS / Database Ownership Checklist](/course/tech-for-non-technical-founders-2026/ownership-checklist/) and run through it. Record pass/fail for each of the 12 items. Create a one-page summary to forward to your investor or board. |
+| **Triage the failures** | If three or more items fail, cross-reference [the eight dev-shop red flags](/blog/dev-shop-red-flags-checklist/) and consider [the 30-day exit guide](/blog/fire-dev-shop-guide/) next. |
+
+## Advanced (optional)
+
+| Topic | When to scope | When to skip |
+|---|---|---|
+| **Signed key infrastructure** | You have 50+ users AND you handle regulated data. Rotating to asymmetric signing keys (AWS KMS, HashiCorp Vault Transit engine) means revocation actually removes access. | You have <50 users. Defer to month three, not month eighteen. |
+| **Security audit reference** | Before an enterprise prospect sends a SOC2 questionnaire. Run [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) (free for Business/Enterprise) or [Prowler](https://github.com/prowler-cloud/prowler) (open-source). Both produce reports answering 80% of infra questions. | You have no enterprise prospects yet. No need for SOC2 or formal audit. |
+
+Ownership audit done right means no Marcus stands between you and a 9pm Tuesday production fix.
+
+## Further reading
+
+- AWS, [AWS Account Root User documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) - the official explanation of why the root email is the master credential and how account recovery works.
+- ICANN, [Transfer Policy](https://www.icann.org/resources/pages/transfers-2024-en) - the rules every domain registrar must follow when transferring a domain between accounts, including the 60-day lockout and 5-day approval windows.
+- GitGuardian, [The State of Secrets Sprawl 2024](https://www.gitguardian.com/state-of-secrets-sprawl-report-2024) - 12.8 million secrets exposed in public GitHub commits in 2023, with `.env` files as one of the most common leak vectors.
+- Rails Guides, [Security: Custom Credentials](https://guides.rubyonrails.org/security.html#custom-credentials) - the canonical Rails answer to the "where do production secrets live?" question, replacing the old `database.yml` plaintext pattern.
+- Will Larson (via First Round Review), [Engineering leadership anti-patterns from Stripe, Uber, Carta](https://review.firstround.com/unexpected-anti-patterns-for-engineering-leaders-lessons-from-stripe-uber-carta/) - on ownership and accountability in engineering teams, including who holds the keys to production.
+- AWS, [Reset a lost or forgotten root user password](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_change-root.html) - the support process and timeline if you need to recover a root account where someone else controls the email.
+
+> **Done when:** All 12 items on the ownership checklist are audited, failures are documented, and a recovery plan exists for each failure.
+> **Next click:** [4.3a · The Self-Serve MVP Stack: Tools & Setup](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/)
+> **If blocked:** If the AWS root email belongs to someone else and they won't cooperate, start the AWS support recovery process immediately (3-5 business days). Do not build on an account you don't own.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Audits all 12 items. Finds GitHub under his personal email (good), but no AWS account (creates one). Domain auto-renewing on a registrar he forgot the password to. Spends a Friday fixing all three. Now owns everything.
+>
+> **Mia**: Audits all 12 items. Owns her domain (good), has personal GitHub but no org (creates one). No secrets manager - creates a 1Password vault. Spends a Friday afternoon. Now owns everything.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/ownership-zones.svg b/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/ownership-zones.svg
new file mode 100644
index 000000000..8fe5109fd
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/ownership-zones.svg
@@ -0,0 +1,75 @@
+
+  The four ownership zones a non-technical founder must control: code, cloud, secrets, and domain
+  
+    
+  
+
+  The four zones you must own by Friday
+  If a contractor's email is on any one of these, you do not own the company
+
+  
+  
+  
+  ZONE 1
+  CODE
+  GitHub org - repos - branch protection
+  If the agency owns the org, they can
+  delete every repo on Tuesday morning.
+  Owner email = founder@yourcompany.com
+  Members = engineers (any company)
+  Item #1-3 of the audit
+
+  
+  
+  
+  ZONE 2
+  CLOUD
+  AWS root - IAM - billing card
+  Root account email is the master key.
+  Whoever owns it owns the whole stack.
+  Root = aws@yourcompany.com
+  Bill paid by your company AmEx
+  Item #4-6 of the audit
+
+  
+  
+  
+  ZONE 3
+  SECRETS
+  Database creds - API keys - .env
+  If only Marcus knows the prod DB
+  password, you do not have a database.
+  You have a hostage situation.
+  Stored in Secrets Manager / 1Password
+  Item #7-9 of the audit
+
+  
+  
+  
+  ZONE 4
+  DOMAIN
+  Registrar - DNS - 3rd-party SaaS
+  A registrar transfer takes 14 days minimum.
+  If the agency holds your domain hostage,
+  your customers cannot reach you for 2 weeks.
+  WHOIS = your name and your email
+  Item #10-12 of the audit
+
+  12 items. 45 minutes. One Friday afternoon. Your credit card and a Notion doc.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/cover.png b/content/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/cover.png
new file mode 100644
index 000000000..4a1186436
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/index.md b/content/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/index.md
new file mode 100644
index 000000000..e776e36df
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/index.md
@@ -0,0 +1,309 @@
+---
+title: "Hire Track Supplementary Reference"
+aliases: ["/blog/hire-track-supplementary-reference/"]
+description: "When you've reached the ceiling of self-serve and need to hire: where to find developers, the Fractional CTO bridge, interviews that catch AI theater, and how to read an SOW."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: hire-track-supplementary-reference
+keywords:
+  - hire developer non technical founder
+  - fractional cto
+  - hire dev shop sow
+  - vet developer ai theater
+  - where hire developer 2026
+  - ai augmented developer
+tags:
+  - founders
+  - non-technical-founder
+  - hire-track-reference
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "Hire Track Supplementary Reference"
+  og_description: "When you've reached the ceiling of self-serve and need to hire: where to find developers, the Fractional CTO bridge, interviews that catch AI theater, and how to read an SOW."
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/"
+related_posts: false
+---
+
+> **Reference content.** This page is supplementary - return when retention from Module 5 is solid AND you have hit the self-serve ceiling. Until then, [Module 4: Build It Yourself](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) is the path.
+
+> **This page is a reference, not a linear read.** Four topics, jump to your need:
+> - [Where to find developers in 2026](#where-to-find-developers-in-2026)
+> - [The Fractional CTO bridge](#the-fractional-cto-bridge)
+> - [Interviews that catch AI theater](#interviews-that-catch-ai-theater)
+> - [Reading the SOW](#reading-the-sow)
+
+This page consolidates the hire-track material from the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) course into one reference. Read the section you need, skip the rest.
+
+---
+
+## Where to find developers in 2026
+
+The developer hiring market reshaped between 2024 and 2026. Algorithm interviews stopped filtering for the skill that ships product - the model passes them. The question now is whether the candidate can own a system, direct AI tools, and put a thoughtful hand on the output before it merges.
+
+### The 2026 AI-Augmented Developer profile
+
+Pre-seed founders still hire on resume signals that stopped predicting outcomes around 2024. Five criteria are the new screen.
+
+**5 to 10 years of shipped engineering experience.** Not 0-3. The Junior who passes algorithm interviews is the Junior the model now replaces. The 5-10 year engineer knows where the load-bearing decisions live, which is the part the model still cannot do alone.
+
+**Daily user of at least one of Cursor, Claude Code, Aider, or Copilot.** Ask them to walk you through their `.cursorrules` file or their CLAUDE.md. If they cannot, they are not directing the tools, they are watching them.
+
+**Has shipped AI-generated code to production AND reviewed someone else's AI-generated code in pull request.** Both halves matter. Shipping alone produces the 45% security-flaw rate Veracode flagged in their GenAI Code Security Report 2025. Reviewing alone produces a senior who never tests the model's claims.
+
+**Can articulate where the AI is wrong.** A real AI-Augmented Developer will tell you, unprompted, that the model invents npm packages (the slopsquatting attack vector), hallucinates database column names, and confidently rewrites authentication code that ships a CSRF hole. If they tell you the model is "amazing" and stop there, the screen is over.
+
+**Salary band: $85K-$120K Junior with Senior productivity, or $100K-$140K for the AI Integration Engineer specialty.** The old Senior at $235K is a luxury, not a necessity for pre-seed.
+
+### Four geographies
+
+The 2026 hire decision is not "remote vs in office." It is which of four regions the role belongs to.
+
+**Onshore (US / EU) - $130K to $210K+ per year.** 30 to 60 day hire cycle. Pick this when the role demands it: regulated industry (HIPAA, SOC 2 with US-data-residency clauses, fintech with state licensing), security clearance, or a board mandate. Otherwise the cost-to-output ratio is the worst on the map.
+
+**Nearshore (LATAM) - $45 to $100 per hour.** Equivalent to $90K to $200K per year. 2 to 5 day hire cycle. Full timezone overlap with US Pacific through Eastern. English fluency at the level needed for daily standups and Slack. The talent pool is dense in Argentina, Brazil, Mexico, and Colombia. The 2026 default for most US founders who do not have a regulated industry mandate.
+
+**Tier-2 offshore India - $15 to $70 per hour.** Equivalent to $30K to $140K per year. 1 to 5 day hire cycle. The structural shift is away from overheated Bangalore (rates compressed by global hyperscaler offices) toward Tier-2 cities: Jaipur, Kochi, Indore, Coimbatore. Senior engineers with seven to ten years of production ships in these cities accept rates 20% to 30% below Bangalore because the local cost-of-living is lower. The catch: async-first culture. You will not get standups at 9am Pacific. You will get pull requests merged overnight, code reviewed against your CLAUDE.md by morning, and a Slack thread with answers to your async questions before you finish coffee. Pick this for backend-heavy work where async is acceptable.
+
+**Mass-market (Upwork) - $35 to $120 per hour.** Self-vetting required: the marketplace does no quality screen, you become the technical interviewer. Acceptable for point tasks only - a single landing page, a logo, a one-off web scraper. Anything load-bearing (payments, auth, multi-tenant data, a third-party integration with retry logic) belongs on one of the three professional platforms above, not Upwork.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+  Start(["You decided to hire.
one-page brief says backend-heavy."])
+  Start --> Q1{"Regulated industry?
HIPAA / SOC 2 / fintech?"}
+  Q1 -->|Yes| Onshore["Onshore (US / EU).
$130K-$210K/yr. 30-60d hire."]
+  Q1 -->|No| Q2{"Backend-heavy and async OK?"}
+  Q2 -->|Yes| Q3{"Budget per hour?"}
+  Q2 -->|No, need timezone overlap| Nearshore["Nearshore (LATAM).
$45-$100/hr. 2-5d hire."]
+  Q3 -->|"$15-$70/hr"| Tier2["Tier-2 India.
Jaipur / Kochi / Indore / Coimbatore.
NOT Bangalore."]
+  Q3 -->|"$45-$100/hr"| Nearshore
+  Q3 -->|"$130K+/yr"| Onshore
+  Start -.->|"Single point task
(logo, landing page, scraper)"| Upwork["Upwork.
$35-$120/hr. Point tasks only."]
+  classDef start fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a
+  classDef question fill:#fff5f5,stroke:#cc342d,stroke-width:2px,color:#1a1a1a
+  classDef onshore fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a
+  classDef nearshore fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+  classDef tier2 fill:#f5e9ff,stroke:#7c3aed,stroke-width:2.5px,color:#1a1a1a
+  classDef upwork fill:#fffbe6,stroke:#bf8a00,stroke-width:2.5px,color:#1a1a1a
+  class Start start
+  class Q1,Q2,Q3 question
+  class Onshore onshore
+  class Nearshore nearshore
+  class Tier2 tier2
+  class Upwork upwork
+```
+
+### Seven platforms ranked
+
+The hiring market for AI-Augmented Developers in 2026 lives across seven platforms. Pick two based on your geography decision above. Post the role on both, and do not waste a Friday on a tour of all seven.
+
+- **[Toptal Fractional Executives](https://www.toptal.com/fractional/cto)** - Senior + screened, 3-5 day hire cycle, $90-$200/hr. Best for Senior fractional roles where the cost of a wrong hire would dwarf the platform markup.
+- **[Bolster](https://bolster.com/marketplace/fractional-cto/)** - the largest curated fractional executive marketplace. Strong for fractional CTO and VP Engineering.
+- **[GoCoFound](https://gocofound.com/)** - fractional CTO and fractional product specifically. Smaller pool, sharper match for pre-seed founders.
+- **[LatHire](https://www.lathire.com/)** - LATAM nearshore developers, full-time and contract. Pre-screens for English fluency and engineering depth.
+- **[AI People Agency](https://aipeople.agency/)** - AI-native engineer screening. Sub-48-hour candidate slates for AI Integration Engineer and AI Quality Engineer roles.
+- **[Seedium](https://seedium.io/)** - AI-first software agency. Project work via SOW, not headcount.
+- **[Upwork](https://www.upwork.com/)** - mass-market freelance for point tasks only.
+
+**Job description that screens for the right signal:** Five lines: (1) 5-10 years engineering, (2) daily Cursor or Claude Code or Aider user, (3) shipped Rails / Django / Laravel apps to production, (4) reviewed AI-generated code in pull request, (5) can articulate where the model is wrong. Skip "5+ years of React and Node." Skip "Big Tech experience preferred." Both screens filter against the wrong signal in 2026.
+
+---
+
+## The Fractional CTO bridge
+
+You do not need a 50% co-founder. You need 5 hours a week of senior judgment to tell you when the architecture is about to break, the contractor is about to propose a rewrite you do not need, or the PR that just merged shipped a CSRF hole. That job costs $400 to $600 a week, pays in cash, and is terminable on 30 days' notice.
+
+### The 5 jobs the Fractional CTO does
+
+**Architecture review - 1 hr/wk.** Every Monday morning, the Fractional CTO opens the codebase and reads what shipped last week. They look at the data model, the route table, the queue setup, and the third-party integrations. They tell you in one paragraph in a Notion doc: "this should be Rails, not microservices; here is why." They catch the moment your contractor proposes a separate React frontend talking to a Node API talking to a Python ML service for an app with 18 paying users.
+
+**PR review - 2 hrs/wk.** Every pull req your contractor opens passes through the Fractional CTO before merge. They catch the API key checked into the repo, the n+1 query in line 47, the missing CSRF token, the auth bypass on the admin route, the abstraction nobody asked for. Veracode's GenAI Code Security Report 2025 found 45% of LLM-generated code shipped at least one exploitable security flaw. PR review is the one thing that catches this before prod.
+
+**Hiring filter - 1 hr/wk during hiring sprint.** When you go to hire your first contractor or full-time engineer, the Fractional CTO runs the tech screen. They read the candidate's last three GitHub commits. They ask the four technical questions you cannot ask. The cost of one wrong-fit hire at month three is two months of runway. The cost of the Fractional CTO doing the screen is one hour at $80 to $120.
+
+**Vendor BS detection - as needed.** When the agency proposes Kubernetes for 200 users, the Fractional CTO sits in the call and says "why?" When the contractor proposes GraphQL because "REST is old," the Fractional CTO says "show me the monorepo plan." They are the senior voice in a room where you are otherwise the only buyer in front of three people pitching.
+
+**Founder coaching - 1 hr/wk.** Every Friday, 30 to 60 minutes. The Fractional CTO translates "the queue is backed up because Resque is dropping jobs" into "promise the May demo for May 12, not May 5." They make the engineering reality legible to your roadmap. The reverse is also true: they hear you describe the customer's pain and tell you which feature is one day of work and which is three weeks.
+
+### Five criteria for hiring a Fractional CTO
+
+Most "Fractional CTO" listings on LinkedIn are either career CTOs in transition (overpriced for pre-seed) or junior engineers padding their title (under-skilled for the role).
+
+**1. 10+ years engineering at Series A-C startups.** Big-tech-only resumes solve different problems. They know how to scale to a billion users. They do not know how to keep a 200-user app alive on a Heroku bill of $89/mo. Series A-C is the sweet spot.
+
+**2. First engineer at 2+ startups.** The "first engineer" experience is the closest analog to what your Fractional CTO will do for you. They have set up the GitHub org from scratch, picked the database, written the deployment script, and argued with a non-technical founder about the roadmap. Two times is enough; one time is luck.
+
+**3. Will commit to a recurring weekly slot.** "Available when needed" is the failure mode. You want a recurring 30-minute architecture review every Monday and a 60-minute founder coaching every Friday. Both blocks on their calendar. If the candidate is not willing to commit to recurring slots in the first call, they are pricing in your churn.
+
+**4. References from non-technical founders specifically.** Ask for two non-technical-founder references. Call both. Ask: "Did the Fractional CTO ever push back on a feature you wanted to ship? What happened?" If the answer is "they always shipped what I asked for," that is a no-hire signal.
+
+**5. $400-$600/wk for 5 hrs is the 2026 market range.** [Bolster's marketplace data](https://bolster.com/marketplace/fractional-cto/) and Toptal Fractional Executives put the range at $80 to $120 per hour for a competent Fractional CTO. 5 hours per week lands at $400 to $600. Above $1,000 per week you are paying for a name brand or a CTO over-spec for pre-seed. Below $300 you are buying a junior engineer with the title inflated.
+
+### Where to find them
+
+- **LinkedIn**: search "Fractional CTO" + your industry. Send 10 short DMs that name the project and the budget. Reply rate is around 30%.
+- **Y Combinator alumni network**: post in the founder Slack. The talent pool here is dense.
+- **Platforms**: [Toptal Fractional Executives](https://www.toptal.com/fractional/cto), [Bolster](https://bolster.com/marketplace/fractional-cto/), [GoCoFound](https://gocofound.com/). Each pre-screens. You pay a markup, you save a week of vetting.
+- **Indie Hackers Fractional channel**: free, slower, founder-to-founder. Best for SaaS micro-startups.
+- **Your investor network**: one email to your lead angel often produces 2 to 4 warm intros within 48 hours.
+
+> **JetThoughts is not a Fractional CTO provider.** We are an engineering services shop (full-team rescues, rebuilds, technical coaching). The platforms above host specialized fractional executives screened on the criteria in this section. This chapter teaches you how to hire one well; we do not sell the role.
+
+**Week 1 onboarding:** Sign the MSA on Day 0. Day 1: share the Validated Problem Statement and one-page brief. Add them to the private GitHub org with `Triage` repo permissions (can review pull requests but cannot merge code) - not `Admin`, not `Write`. Day 3: first 30-minute architecture review. They write one paragraph in a shared Notion doc: "what I would change, what I would leave alone." Day 7: first PR review. Their comments should be in plain English so you understand the trade-off. End of Week 4: ask them the Friday-coaching question. "Should I hire any contractors yet?" If the answer is hand-wavy, you have hired wrong; replace.
+
+### The Fractional CTO's first 4 weeks (parallel to your Module 5 first-paying-customer push)
+
+**Read this before you decide whether to hire** - it shows what the FCTO's first 4 weeks look like alongside your Module 5 work, so you can evaluate whether the timing makes sense and what you should expect from the engagement. The FCTO arrives the week one or two Ch 4.4 ceiling signals flip red (Ch 4.4 has a 5-signal scoreboard; "red" means a signal has been firing for 4+ weeks). They are NOT building features alongside you - they are reading what already shipped, naming what is about to break, and deciding salvage vs rebuild. The four-week onboarding runs in parallel to your Module 5 outreach so neither stream blocks the other:
+
+| Week | Fractional CTO ships | You ship | Why parallel |
+|------|----------------------|----------|--------------|
+| **Week 1** | One-page architecture assessment in a shared Notion doc: "the shed is holding" OR "we need a house in 8 weeks." Names the highest-risk ceiling signal and the patch cost. | Send the 50-name personal-network outreach from Ch 5.3. | The architecture verdict is the input to your runway math; your outreach is the input to your revenue math. Both need to happen before week 5. |
+| **Week 2** | Watch Supabase logs for RLS violations, slow queries, error rates as your first 10 invited interviewees create accounts. Patches one critical bug ONLY if data-corruption risk. | Book the first 2-3 demo calls from Ch 5.3 replies. Run them. | The Fractional CTO reads the signal of your first 10 real users; you read the signal of your first 2-3 demo prospects. |
+| **Week 3** | Ships ONE small hardening change to staging: faster dashboard query, fixed RLS policy, or webhook idempotency check. Not a feature - a stabilizer. | Send the first Ch 5.4 Design Partner Agreement to a hot lead. | One stabilization stream + one revenue stream = the founder gets paid pilots without the contractor getting tempted into feature work. |
+| **Week 4** | Friday-coaching call: "based on the first 4 weeks, here is the 90-day plan." Either (a) keep self-serve + Fractional CTO bridge for 3 more months, (b) hire a full engineer this month, or (c) rebuild from scratch on Rails/Django/Laravel in 8-12 weeks. | Close the first paid pilot from Ch 5.4. Stripe deposit clears. | Both streams converge: the Fractional CTO's 90-day plan and your first revenue are the two inputs to the next hire decision. |
+
+The trap to avoid: the Fractional CTO who arrives in Week 1 and immediately recommends "rewrite the whole thing in Rails." That candidate sees vibe-coded MVPs as broken not salvageable; the recommendation usually means they want the bigger billable engagement. Push back: "what is the ONE ceiling signal we can patch in Supabase this week to give us 90 more days to decide?" A real Fractional CTO has the patch ready by Friday.
+
+### The monthly architecture review habit (the one thing the Fractional CTO does every month)
+
+First Monday of every month, 60 minutes, the Fractional CTO and you read the Ch 4.4 5-signal scoreboard together. The standing agenda:
+
+1. Re-score the 5 signals against last 30 days of usage data, OpenAI invoice, support tickets, schema changes, and customer security/compliance asks. 20 minutes.
+2. Compare to last month's score. Did any signal flip from green to yellow, or yellow to red? Did any flip back? 10 minutes.
+3. Pick ONE thing to harden this month. Not three. One. Examples: add caching to the dashboard, write the RLS policy test, set up an audit log. 15 minutes.
+4. Decide: bridge for another month, hire a full engineer, or start the rebuild conversation. Document the decision in the same Notion doc. 15 minutes.
+
+The scoreboard becomes the standing artifact. By month 3 you can see whether you are stabilizing (signals flipping back to green), holding (no change), or sliding (signals progressing red). Three consecutive months of one signal at red without patching = it is time to hire. Two consecutive months of all signals at green = the Fractional CTO bridge worked and you can scale back to monthly check-ins only.
+
+### Production hardening checklist: what your Fractional CTO will look for
+
+Five hardening checks a competent Fractional CTO will run in the first 30 days. **Read this BEFORE the hiring conversation so you know the names**, not so you execute the engineering yourself - the steps below need hands-on database + production access most non-technical founders don't have. When the FCTO's week-1 report mentions any of these, you'll know what they mean and the conversation about which one to patch first takes 10 minutes instead of 45.
+
+**1. Row-Level Security (RLS) policy testing.** RLS is the database rule that says "Coach A can read only Coach A's rows." Every RLS policy you (or the FCTO) wrote in Supabase needs a test query proving it works - the FCTO opens the Supabase SQL editor, signs in as Coach A, and tries to read Coach B's data. If the query returns rows, the policy has a hole. This 5-minute check prevents the cross-tenant data leak that ends pilots. The FCTO's first ship is usually patching any failing policy.
+
+**2. Webhook idempotency.** A webhook is an automatic message from one service (Stripe, Resend, etc.) to your app. "Idempotent" means it's safe to fire the same message twice - the second hit doesn't double-charge or double-update. Stripe retries on any non-2xx response (network blip, timeout, deploy mid-call) so the handler must be defensive. The FCTO's check: every webhook handler starts with "have I already processed this event ID?" - if yes, return success immediately without re-running the update.
+
+**3. Database backup restore runbook.** Your Supabase project auto-backs up to S3 nightly. The month you need the backup is not the month to discover the restore doesn't work. The FCTO runs a full restore to a staging Supabase project once a month, signs in as a customer, confirms the data is there, and documents the step-by-step in a shared Google Doc. You inherit the runbook so you can re-run the drill if the FCTO leaves.
+
+**4. Secret rotation recovery flow.** When a contractor leaves on Thursday with your Supabase password in their personal 1Password vault, the FCTO runs the recovery sequence: (a) revoke all API keys in the Supabase / Stripe / OpenAI dashboards immediately, (b) backup the whole database to S3, (c) open a Supabase support ticket for the old password reset, (d) check the audit log for what got read during the unrevoked window. Rotating secrets is easy; recovering the logs of who accessed what is the part most founders miss when they try this themselves.
+
+**5. AI inference rate-limit handling.** If your Lovable form calls OpenAI or Anthropic on submit, you need a request queue. The FCTO's pattern: your Lovable form does NOT call the API directly; it writes a job to a Supabase queue table; a background worker pulls from the queue, hits the API, stores the result. When the API rate-limits you (every API does eventually), the queue backs up gracefully instead of timing out in the user's face. This is one of the FCTO's standard first-week ships.
+
+These five are the gap between "works in test mode for one founder clicking around" and "works in production for 47 paying customers on a Tuesday morning." Knowing the names is the founder's job; running the checks is the FCTO's.
+
+---
+
+## What stack to ask your hired team to use
+
+You are not picking the stack alone - your Fractional CTO or hired engineer makes the technical call. But you need the vocabulary to (a) have an informed conversation, (b) recognize when a contractor proposes the hipster-of-the-month stack that nobody can hire for in 6 months, and (c) push back without escalating to a holy war. The frame below is what we recommend out of 20 years of rescue calls.
+
+### Default: Rails (Ruby on Rails)
+
+Rails is the JetThoughts default and the Indie Hackers / DHH / Pieter Levels community standard. The reasoning is empirical, not religious: Rails ships fast, one engineer can operate the full stack end-to-end, the conventions are tight enough that the next engineer you hire reads the codebase in a day, and the deployment story (Heroku, Fly.io, Render) costs $7-$50/month at pre-seed scale. Basecamp ([DHH's *One-Person Framework* essay](https://world.hey.com/dhh/the-one-person-framework-711e6318)) is the case study: 50M+ users on a Rails monolith run by ~20 engineers. At your scale (47-5,000 paying users) one Rails engineer can ship + operate the whole thing.
+
+**Why Rails wins for the non-technical founder's hired team:** the hire pool is deep (15+ years of Rails engineers), the framework opinions are tight (less time arguing about conventions, more time shipping), background jobs / email / file uploads / authentication / payment / admin / search are all batteries-included rather than 12 separate npm packages, and the Rails community produced the rescue patterns we see work in production (Pundit for authorization, Devise for auth, Sidekiq for jobs, ActiveAdmin for staff tools).
+
+### Acceptable alternatives, with caveats
+
+| Stack | When it's right | Caveat |
+|-------|----------------|--------|
+| **Laravel** (PHP) | Your hired team is PHP-comfortable; you need WordPress integration; you're in a market with deeper Laravel hiring than Rails (Europe, Indonesia, Brazil) | Same conventional-monolith strengths as Rails. PHP hosting is cheaper. Hiring outside Rails-strong markets is often easier in Laravel. |
+| **Django** (Python) | Your product has serious ML / data / scientific workloads; the team will use Python for the model pipeline anyway and consolidation reduces cognitive load | Slightly less batteries-included than Rails; admin panel + auth + ORM are strong; the migration story is bumpier. Ship Django when ML is the moat, not "we like Python." |
+| **Next.js + Postgres** (frontend monolith with API routes) | Your product is content-heavy, SEO-critical, and the build is mostly screens with light backend | Next.js is excellent for static-heavy products. It becomes a footgun when the backend grows: API-route monoliths trap you in serverless cold starts and React-only data-fetch idioms. Cap Next.js at the marketing site + light dashboard. |
+
+### Explicit "do NOT accept" patterns
+
+If your contractor or FCTO proposes any of these in week 1, push back hard. They are real architectural choices, but not for your scale and not for the non-technical founder context:
+
+- **Microservices for 200 users.** Microservices solve a coordination problem teams of 50+ have. At 1 contractor + 1 non-technical founder, microservices add 5x the operational complexity for zero scaling benefit. Counter-proposal: one monolith, period.
+- **Separate React frontend + separate Node API + separate Python ML service for a single workflow.** Three deployments, three CI pipelines, three on-call rotations, three places auth has to be enforced. At pre-seed, this is the rebuild-in-9-months pattern we see most often. Counter-proposal: one Rails or Django app that does everything; add the second service only when a real bottleneck appears.
+- **GraphQL because "REST is old."** GraphQL solves a frontend-team coordination problem you don't have. It also makes caching, monitoring, and rate-limiting harder. REST is fine for 0 to 50K users. Counter-proposal: REST with sensible JSON; add GraphQL the day a frontend team asks for it.
+- **Kubernetes / Docker Swarm for an MVP.** Container orchestration is correct for 20+ services across 3 environments. It is wrong for "1 web process + 1 database + 1 cron job." Counter-proposal: Heroku, Fly.io, Render, or a single Hetzner VPS with a deploy script.
+- **Hand-rolled auth ("we'll just build login").** Auth is where rescue calls start. Counter-proposal: Devise (Rails), django-allauth (Django), or Auth.js (Next.js). Buy the proven implementation; never build your own.
+
+### The 3-question script for the contractor stack conversation
+
+When you interview a contractor or FCTO, ask these three questions before signing anything. The right answers map to the recommendations above; the wrong answers are the red flags.
+
+1. **"What stack would you build this in, and why?"** Good answer: "Rails (or Laravel/Django depending on team) - I can ship a working signup + paywall + one workflow end-to-end in 4-6 weeks solo, and the hire pool for the next engineer is deep." Bad answer: a 3-stack architecture diagram, or "whatever you prefer." The first signals over-engineering; the second signals they have no opinion (which means they'll default to what's trendy).
+2. **"If we hit 5,000 paying users, what breaks first?"** Good answer: a specific component (database read replicas, background job queue, image processing). Bad answer: "we'll rewrite in [new stack] then." Rewrite-driven engineers are expensive.
+3. **"How many other engineers can I hire who would be productive in this stack within 30 days?"** Good answer: a real number for your market (Rails: thousands worldwide; Laravel: similar; Django: similar; Elixir or Clojure: dozens; Rust web framework: a handful). Bad answer: vagueness, or "we don't need to think about that yet."
+
+The Indie Hackers community spent the last decade learning what one-person and two-person engineering teams can sustain. The answer almost always rhymes with Rails / Laravel / Django + Postgres + a single hosted deployment + boring open-source libraries. Trust the empirical evidence; resist the JavaScript fashion cycle.
+
+---
+
+## Interviews that catch AI theater
+
+Every engineer claims AI fluency on a 2026 resume. Most are typing prompts, accepting suggestions, and pushing the diff to PR. Veracode measured what that produces: 45% of LLM-generated code shipped at least one exploitable security flaw. The market split into two populations behind the same resume language. The 80% run AI theater - they accept the model's first suggestion, never disagree, and never check the dependency. The 20% direct the model - they read the diff, reject most of it, and catch the hallucinated package before it merges.
+
+For the verbatim 7-question script + per-question Pass/Fail rubric + scoring sheet, see the [Hiring Interview Script](/course/tech-for-non-technical-founders-2026/hiring-interview-script/) template. Below is the brief on when and why to use it.
+
+### When to run the 7-question screen
+
+Run it after the resume passes, before any technical take-home. The 30-minute screen sits between phone screen (culture/role context) and the deeper paired-coding session you do with finalists. Three of seven questions are about AI tooling, four about engineering judgment - the split mirrors what an AI-Augmented Developer actually does in a week.
+
+### Why these seven questions, not a different seven
+
+The seven questions are organised around what costs the most when a candidate fakes it.
+
+- **Workflow + cost (Q1, Q2)** catch the candidate who has never set up a `.cursorrules` file or seen a personal Anthropic invoice. That candidate will silently run your monthly AI bill from $200 to $4,800 in their first sprint.
+- **Verification + slopsquatting (Q3, Q4)** catch the candidate who outsources PR review to the model. That is the candidate whose name ends up next to the CSRF hole in your incident postmortem.
+- **Accountability + refactor (Q5, Q6)** catch the candidate who has never owned a system through a production incident or a non-trivial rewrite. The "I refactor as I go" answer is the kind of rewrite that kills startups.
+- **Disagreement (Q7)** is the one question that actually splits the population. AI theater candidates accept the model's first suggestion. AI direction candidates read the diff, reject most of it, and can show you the PR comment where they did it.
+
+### The scoring discipline
+
+Score within five minutes of hanging up - not after the next call. Use the three-axis sheet in the script (Specificity, System judgment, Communication). The one rule worth repeating: do not let a strong Communication score override a failed Q7. Q7 is the load-bearing question; if they cannot show one PR where they disagreed with the model, the answer to every other question was a story.
+
+Send the polite-no email the same evening, not Friday: "Thank you for the time. We are pausing the search to refine our requirements. We will keep your details on file."
+
+---
+
+## Reading the SOW
+
+*"Vendor shall be deemed to have delivered a milestone upon deployment to the Client-accessible staging environment."* That is the single most expensive sentence a founder will sign this year. It moves the trigger for a milestone payment from "the feature works for users" to "the agency pushed code to a URL." A SaaS founder we worked with in Q1 2026 had $78K of milestone invoices clear under that one line before her fractional CTO opened the staging URL and watched it 500 on the second click.
+
+Her general counsel had cleared the SOW the night before signing. He had flagged liability and the IP assignment, fixed both, and called it done. The milestone-acceptance clause sat three pages later and he had skimmed it. Generalist lawyers cover the catastrophic clauses. Agency templates leak money through the operational ones in between.
+
+### Eight clauses that quietly cost you money
+
+| Clause | What it should say | Red flag wording | What to redline |
+|---|---|---|---|
+| **1. Scope definition** | A feature list at "Rails 7 app with sign-up, contractor-match, payments, hundred-row admin" with a per-feature day estimate | "Scope to be defined sprint by sprint" / "agile discovery throughout" | Demand the feature list and day estimate before you sign. The SOW is a blank cheque without it. |
+| **2. Milestone acceptance** | Milestone passes when CI is green on main, you have clicked the feature end-to-end on staging, AND you have confirmed delivery in writing | Milestone "delivered upon deployment to the Client-accessible staging environment" with a 5-day silent-acceptance window | Write acceptance criteria into the SOW. Convert silent acceptance to active sign-off. |
+| **3. Change-request process** | Capped at 10% of SOW value, written estimate naming developer and hours per change | Open-ended hourly at $185/hr with verbal approval | Strike "verbal approval." Add the 10% cap and the written-estimate requirement. |
+| **4. IP and code ownership** | Milestone-based assignment: upon payment of each milestone, the code for that milestone is yours, irrevocably | Ownership transfers "upon receipt of all amounts due under this Agreement" | Strike "all amounts due." Replace with milestone-by-milestone IP transfer so payment disputes do not become hostage situations. |
+| **5. Third-party dependencies** | Every account (AWS, Stripe, OpenAI) on your company email from day one, paid by your card, agency on IAM sub-access only. Monthly pass-through capped with founder approval | Pass-through at cost + 15% with accounts under the agency's email | Demand account ownership from day one. Add the founder-approval gate. (One founder caught a $4,800 surprise OpenAI line by enforcing this.) |
+| **6. Termination triggers** | Quality trigger (2 consecutive missed acceptance criteria), slip trigger (>21 days without revised plan), termination-for-convenience with defined exit fee, 30-day handover obligation | "Terminate only for material breach" with 30 days to cure | Add the quality, slip, and convenience triggers. Lock in the 30-day handover. |
+| **7. Post-launch warranty** | Warranty starts the day deliverables are first served to live paying users, runs 90 days | Warranty clock starts at "Delivery" and runs 30 days (can expire before users see the feature) | Anchor warranty start to production launch, not delivery. Extend to 90 days. |
+| **8. Dispute resolution** | Non-binding mediation step before arbitration, neutral venue, prevailing-party fee-shift (loser pays winner's attorney fees) | Binding arbitration in the agency's home county, each party bearing own costs | Add mediation step. Switch to neutral venue. Add fee-shift. |
+
+### The milestone-acceptance redline
+
+Of the eight, milestone acceptance is where founders consistently lose the most money, and it is the clause your general counsel is the most likely to skim.
+
+The fix is one paragraph. A milestone is delivered when (a) the acceptance criteria listed in Exhibit B pass in CI, (b) the Founder or her delegate has clicked the feature end-to-end on the staging URL, and (c) the Founder has signed off in writing within seven business days. The acceptance criteria belong in the SOW, not in a Slack message after the work is done. The five-day silent-acceptance window becomes a seven-day active-acceptance window. The invoice does not clear until the Founder signs.
+
+If the agency pushes back on this language, that is the conversation you want to have before signing, not after $78K has been wired.
+
+### When the SOW is already signed
+
+If you have already signed and a few of the eight clauses are tilted against you, the work is recoverable but harder. Put a dollar number next to each clause before the next renegotiation conversation. Which clauses are biting you now (dollar cost from milestones already paid against staging-only delivery), and which can wait (warranty windows that have not yet triggered). Push back on the milestone-acceptance and termination-trigger clauses first - they have the highest dollar exposure per sprint.
+
+---
+
+## Next steps
+
+If you are reading this because you are ready to hire, the sequence is:
+
+1. Pick your geography and two platforms from the hire section above. Post the role this week.
+2. If you have budget for it, hire the Fractional CTO before the first developer starts. The $400-$600 per week for architecture review and PR coverage pays back in the first sprint.
+3. Run every candidate through the seven-question interview. Score within five minutes of the call. Do not let good conversation scores override a failed Q7.
+4. Before you sign any SOW, read the milestone-acceptance clause word by word. If it says "upon deployment to staging," strike it and replace it with the paragraph above.
+
+The [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) course covers the full sequence from problem validation through your first paying customer.
diff --git a/content/course/tech-for-non-technical-founders-2026/hiring-interview-script/cover.png b/content/course/tech-for-non-technical-founders-2026/hiring-interview-script/cover.png
new file mode 100644
index 000000000..598d6e8d0
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/hiring-interview-script/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/hiring-interview-script/index.md b/content/course/tech-for-non-technical-founders-2026/hiring-interview-script/index.md
new file mode 100644
index 000000000..817bd8ebf
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/hiring-interview-script/index.md
@@ -0,0 +1,204 @@
+---
+title: "Hiring Interview Script: 7 Questions in 30 Minutes"
+aliases: ["/blog/hiring-interview-script/"]
+description: "Send to engineering candidates 24 hours before the call. 7 questions that catch AI theater in 30 minutes. Pass / Fail score in real time."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: hiring-interview-script
+keywords:
+  - hiring interview script
+  - founder engineer interview template
+  - ai augmented developer interview
+  - 7 questions developer hiring
+  - non technical founder interview script
+tags:
+  - founders
+  - non-technical-founder
+  - template
+  - course-companion
+  - hiring
+categories: ["Templates"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/hiring-interview-script/"
+related_posts: false
+---
+
+📋 Template companion to the [Hire Track Supplementary Reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#interviews-that-catch-ai-theater). Send to candidate 24 hours before the call. Score each answer Pass / Fail in real time.
+
+> This template is the canonical source for the 7 hiring interview questions. The [Hire Track Supplementary Reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/) post links here for the full Q&A.
+
+> **📋 Copy-pasteable pre-interview email - send to candidate 24 hours before the call:**
+>
+> Subject: `[Date] interview prep - 7 questions`
+>
+> Hi [first name],
+>
+> Looking forward to our call [tomorrow / Tuesday]. Here are the 7 questions we will work through together. Please come prepared to share your screen for Q3 and Q7.
+>
+> [Paste Q1-Q7 from below - the bold headers only, not the scoring criteria.]
+>
+> The call runs 30 minutes: 5 min intro, 20 min on the questions, 5 min for your questions. Talk soon.
+>
+> [Your name]
+
+# The Hiring Interview Script - 7 Questions in 30 Minutes
+
+*Send Sunday night. Run Tuesday and Wednesday. Hire decision in your hand by Friday.*
+
+## The 7 questions at a glance
+
+| # | Question (compressed) | What it tests |
+|---|---|---|
+| 1 | Workflow: Jira ticket to merged code, with AI in the loop | Tools named by version, real PR from last week |
+| 2 | Cost: $/dev/month on AI tokens, who pays it | Specific dollar range, pulled before the call |
+| 3 | Verification: what the senior reviewer checks on AI PRs | Opens a real PR on screen, names line-level checks |
+| 4 | Slopsquatting: how do you stop a hallucinated package | Named defense, uses the word, cites the source |
+| 5 | Accountability: last AI-generated-code incident you owned | Date in last 6 months, root cause, workflow change after |
+| 6 | Refactor: last one you led, what stayed/changed/broke | Named system, kept-changed-broke-safety-net structure |
+| 7 | Disagreement: PR review where you said no to the AI | Real PR on screen, specific technical reason, one of many |
+
+## Why this exists
+
+A pre-seed B2B SaaS founder we picked up in Q3 2026 had been three weeks into onboarding her second LATAM hire when the first signs landed. The candidate had cleared the standard 60-minute behavioural interview - tools named, Cursor seat shown, GitHub profile reviewed. By week three he had merged 4 PRs. Her fractional CTO opened the first one and found a `gem 'stripe_connect_v2_helper'` line that did not exist on Rubygems; the second PR had a hardcoded JWT secret in `config/secrets.yml`; the third was a copy-paste of the first with the variable names changed. The contractor was replaced inside ten days, but the cost of the on-ramp, the onboarding hours, and the rollback was real. The 7-question version of the interview below would have caught the gap on the original 30-minute call. The fail signals were there in Q3, Q4, and Q7. Nobody asked them.
+
+## How to use this
+
+Send the seven questions in writing 24 hours before the call with one sentence: *"We will work through these together on Tuesday; please come prepared."* Do not soften it. Candidates who decline to prepare are telling you the answer to the interview before it starts.
+
+Run the call on a 30-minute Zoom block. Five minutes for intro and role context, twenty for the seven questions (about three minutes each), five for their questions and a close. Score Pass / Fail in real time on the scorecard at the bottom of this page. Add the three sub-scores within five minutes of hanging up - not Friday, not next week. Specificity, system judgment, communication. Above 7 = book the reference call before you close the laptop. Below 5 = polite-no email by tomorrow morning.
+
+If a candidate refuses to share their screen for Q3 or Q7, that is a Fail on both questions automatically. The interview is over. End on time anyway, send the polite-no, move on.
+
+## The 7 questions - copy and paste
+
+### Q1. The workflow question
+
+> "Walk me through how you take a Jira ticket and end up with merged code, when AI is in the loop. Name the tools, the prompt patterns, and the human review gates. Use a real ticket you closed last week."
+
+- **Pass:** tools named by version (Cursor + Claude 4.5 Sonnet, Claude Code, Aider, Copilot Enterprise) + a written sequence (failing test first → prompt → generate → review → PR with `Assisted-by:` tag → merge) + a real PR number from last week
+- **Fail:** "I let Cursor handle the boilerplate" / "depends on the ticket" / no real PR / generic monologue about how AI helps them think
+
+### Q2. The cost question
+
+> "What does the average dev on your team spend on AI tokens per month, and who pays it? What does your Cursor seat plus your API usage cost you personally last month?"
+
+- **Pass:** per-developer dollar range ($80-$300/month) + pulled the number off their last receipt before the call + budget alert on their personal API account
+- **Fail:** "my company pays for it" / "I don't really track that" / "it's pretty cheap"
+
+### Q3. The verification question
+
+> "When AI generates a 200-line PR, what does the senior reviewer actually check? Walk me through one PR you reviewed last week and tell me what you looked for."
+
+- **Pass:** opens an actual PR on screenshare + reads it line by line + names checks (diff matches spec, no hardcoded secrets, tests are real not after-the-fact, new packages exist on Rubygems / PyPI / npm)
+- **Fail:** "I trust the model most of the time" / "Cursor catches the obvious stuff" / "we rely on CI"
+- **Hard fail:** refuses to share screen
+
+### Q4. The slopsquatting question
+
+> "In April 2025 a security researcher published findings that AI assistants suggested over 200 package names across Rubygems, PyPI, and npm that did not exist. Attackers register those names and wait for developers to install the typo. How do you prevent installing a hallucinated package in your own work?"
+
+- **Pass:** specific defense (allowlist, Socket / Snyk on every PR, manual verification step) + uses the word "slopsquatting" without prompting + cites the Bleeping Computer or Infosecurity Magazine writeup
+- **Fail:** "I check the package name looks right" / "Cursor only suggests real packages" / "I have not run into that"
+
+### Q5. The accountability question
+
+> "When AI-generated code causes a production incident, who is on the hook? Walk me through the last AI-generated-code incident you owned. What happened, when, what you changed afterwards."
+
+- **Pass:** specific incident with date in last 6 months + one-paragraph root cause + named senior who reviewed the PR + workflow change made the week after
+- **Fail:** "I have never had an AI-related incident" (lying or never shipped) / "AI code is the developer's responsibility" (translation: not mine) / "we blamed Cursor and moved on"
+
+### Q6. The refactor question (NEW for individual hires)
+
+> "Walk me through the last refactor you led. What stayed, what changed, what broke briefly, and how you knew it was safe to ship."
+
+- **Pass:** specific refactor with named system + describes what they kept (public API contract, test suite as safety net), what they changed (data model, migration, service boundaries), what broke briefly (4pm staging deploy, flaky test) + names the safety net (green CI, feature flag, rollback, canary)
+- **Fail:** "I refactor as I go" / "I rewrote the whole module" / "the product team did not let me refactor"
+
+### Q7. The disagreement question (NEW for individual hires)
+
+> "Show me a PR review you wrote in the last 30 days where you disagreed with the AI's suggestion. Tell me what the AI suggested, why you disagreed, and what you shipped instead."
+
+- **Pass:** shares screen + opens GitHub or GitLab + scrolls to a real PR + reads the comment they left out loud + the disagreement is technical and specific (hallucinated gem swapped for stdlib, N+1 fix, security flag caught) + this is one of several they could have picked
+- **Fail:** "I usually agree with the model" / "I cannot think of one off the top of my head" / 40 seconds of silence and a promise to email a link "when they find one"
+- **Hard fail:** refuses to share screen
+
+## What good looks like vs what bad looks like
+
+The passing-candidate pattern: they pull up artifacts on screenshare without prompting. They read PRs out loud. They name dollar amounts to the dollar. They quote the date of the last incident from memory. They reference [the Assisted-by: kernel rule](/blog/ai-code-ownership-accountability/) on Q5 without you bringing it up. They have a laptop full of receipts.
+
+The AI-theater pattern: they answer in the abstract. "We use AI to deliver faster value." "Cursor is a great accelerator." When you ask for a real PR or a real receipt, the answer is "I will follow up." That follow-up does not arrive.
+
+One concrete contrast on Q7:
+
+> Bad: "I usually agree with what Cursor suggests; it has a high standard."
+> Good: "PR #1438 last Wednesday - Cursor wanted to add `gem 'jwt-decoder-v2'` for the token validation. That gem does not exist on Rubygems and the standard library `OpenSSL::JWT` already does the job. I left a comment asking the developer to use the stdlib. The merge was clean by Friday."
+
+## The scorecard - score in real time
+
+| # | Question (one-line) | Pass / Fail | Notes |
+|---|---|---|---|
+| Q1 | Workflow: Jira ticket to merged code, named tools | ☐ Pass ☐ Fail | |
+| Q2 | Cost: $/dev/month on AI tokens, who pays it | ☐ Pass ☐ Fail | |
+| Q3 | Verification: what reviewer checks on AI PRs | ☐ Pass ☐ Fail | |
+| Q4 | Slopsquatting: how do you stop a hallucinated package | ☐ Pass ☐ Fail | |
+| Q5 | Accountability: last AI-code incident you owned | ☐ Pass ☐ Fail | |
+| Q6 | Refactor: last one you led, what stayed/changed/broke | ☐ Pass ☐ Fail | |
+| Q7 | Disagreement: PR review where you said no to the AI | ☐ Pass ☐ Fail | |
+
+Then add the three axis scores (each 0-10):
+
+- **Specificity (0-10):** real PR numbers, real dollar amounts, real incident dates. Hand-waving = 2. Numbers and names = 8. Walkthrough on screenshare with the actual artifact = 10.
+- **System judgment (0-10):** Q6 and Q7 test this directly. Real refactor + real PR-review disagreement = 8+. Deflects either = below 5.
+- **Communication (0-10):** would they answer your founder questions in plain English? Would the [three-questions standup](/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/) format work with this person?
+
+Total = sum of three. Convert to a 1-10 by dividing by three. See the [What to do after](#what-to-do-after) section below for the action per band.
+
+## After the call: write the 3-sentence summary
+
+Within 5 minutes of hanging up, while the answers are still fresh, write a 3-sentence summary in your candidate Notion doc. Use this template:
+
+```
+Candidate: [name] · Date: [YYYY-MM-DD] · Score: [N]/10
+
+Sentence 1 (signal): The strongest signal from the call was [specific
+moment - the PR they opened, the receipt they pulled, the disagreement
+they read out loud, OR the hand-wave they gave when asked for one].
+
+Sentence 2 (gap): The gap that gave me pause was [specific moment - the
+question they could not answer, the artifact they could not produce,
+the dollar number they did not know].
+
+Sentence 3 (decision): I am [booking a reference call / sitting on this
+overnight / sending a polite no] because [the signal/gap above clearly
+puts them in the [hire / maybe / no-hire] band].
+```
+
+Three sentences. No more. The decision is in your gut by minute 28 of the call; the writing is just to lock it in before Friday's calendar fills with other meetings.
+
+If you booked a reference call, the next step is the [SOW reading guide](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#reading-the-sow). The interview is the people screen. The SOW is the money screen. Both clear before you sign.
+
+## What to do after
+
+- **Above 7:** book the 30-minute reference call with two of the candidate's prior clients or managers. Ask three questions: what AI-related incidents did they own, what was the OpenAI line on their monthly invoice, did they ever ship a PR with `Assisted-by:` in the commit log on request.
+- **5 to 7:** schedule one 45-minute follow-up technical session, working through one of your real product flows on screenshare. If they cannot attend within seven days, that tells you their actual availability. Drop or proceed.
+- **Below 5:** send the polite-no the same evening. One paragraph:
+
+> **📧 Copy-pasteable polite-no email:**
+>
+> Subject: `[Date] interview - follow-up`
+>
+> Hi [first name],
+>
+> Thank you for the time today. We are pausing the search to refine our requirements. We will keep your details on file.
+>
+> Best,
+> [Your name]
+
+Do not negotiate.
+
+The 30-minute interview is cheaper than the wrong hire it prevents. A bad three-month hire on a $90/hour LATAM contract costs $43K plus the onboarding hours and the rollback. The seven questions cost 30 minutes.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/how-this-course-works/cover.png b/content/course/tech-for-non-technical-founders-2026/how-this-course-works/cover.png
new file mode 100644
index 000000000..06719ed14
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/how-this-course-works/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/how-this-course-works/index.md b/content/course/tech-for-non-technical-founders-2026/how-this-course-works/index.md
new file mode 100644
index 000000000..dc613985c
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/how-this-course-works/index.md
@@ -0,0 +1,209 @@
+---
+title: "How This Course Works"
+aliases: ["/blog/how-this-course-works/"]
+description: "The complete journey from idea to first paying customer at a glance: 5 modules, 20 chapters, 6 artifacts, and the AI tools that accelerate each stage."
+date: 2026-06-04
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: how-this-course-works
+keywords:
+  - non technical founder course overview
+  - startup validation system 2026
+  - idea to first paying customer flow
+  - founder course curriculum map
+  - business idea validation tools
+tags:
+  - founders
+  - non-technical-founder
+  - course-overview
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "How This Course Works - From Idea to First Paying Customer"
+  og_description: "The complete journey at a glance: 5 modules, 20 chapters, 6 artifacts, and the AI tools that accelerate each stage."
+cover_image_alt: "Course overview diagram showing the 5-module journey from idea to first paying customer"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/how-this-course-works/"
+related_posts: false
+---
+
+> **Chapter 0** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **What this is:** the map. Read this once before Module 1, come back when you need to see where you are.
+
+> **TL;DR:** Five modules, twenty chapters, six artifacts. Each module's output is the next module's input - from rough idea to signed paid pilot. The map: read once, come back when lost.
+
+This course takes a non-technical founder from a rough idea to a signed paid pilot - on evenings and weekends, with or without engineers. Each chapter names the tool it uses and what the tool costs at that step; most tools have a free tier. Below: the flow, the tools, the artifacts you'll compile, and how the stages connect.
+
+> **Calendar reality - full-time vs evening-only.** The per-module wall times below assume a founder with daytime availability. An evening-only founder (2-4 hr/week, the pattern this course is built for) typically needs 1.5-3x the calendar at each module. Build your plan against the evening-only band; finishing early is a bonus.
+
+---
+
+## The Big Picture
+
+![5-module pipeline: Module 1 Hypothesis & Smoke Test → Module 2 Validate the Problem → Module 3 Design from Evidence → Module 4 Build It Yourself → Module 5 First Paying Customer](module-pipeline.svg)
+
+Five modules. Twenty chapters. Six artifacts you can hand to an investor or a co-founder. Each module's output is the next module's input.
+
+---
+
+## The 5 Modules at a Glance
+
+### Module 1 - Hypothesis & Smoke Test
+**You have:** a rough idea or instinct.
+**You walk away with:** a one-sentence Founding Hypothesis + a live landing page with a Stripe price button.
+**Time:** ~7 days, evenings and weekends.
+
+| Step | What You Do | Key Tool |
+|---|---|---|
+| 1.1 | Write your Founding Hypothesis (Mad Libs sentence) | Notebook + kitchen timer |
+| 1.2 | Build a landing page to test demand | Carrd or Neeto (free tier) |
+| 1.3 | Add a Stripe price button to measure payment intent | Stripe Payment Links (free) |
+
+**Before you write the hypothesis:** run a 30-minute Perplexity search first. Ask it to find the top 5 user complaints about existing solutions in your niche, citing G2 and Capterra reviews. Use the exact vocabulary from real complaints in your hypothesis blanks. If nobody is complaining about the problem anywhere online, the hypothesis is already in trouble.
+
+> **AI research layer (pre-hypothesis):** Perplexity (free tier) + Trend Seeker (free daily limit). Purpose: confirm people are actually searching for or complaining about the problem BEFORE you write a hypothesis about it. Verbatim quotes from Reddit and G2 feed directly into your landing page headline.
+
+---
+
+### Module 2 - Validate the Problem
+**You have:** a Founding Hypothesis.
+**You walk away with:** 10 Mom Test interview transcripts + a validated problem statement + a 2-hour clickable prototype tested with 5 people.
+**Time:** ~2-3 weeks, evenings and weekends.
+
+| Step | What You Do | Key Tool |
+|---|---|---|
+| 2.1 | Learn the 5 Mom Test rules (ask about past, not future) | Mom Test Interview Script |
+| 2.2 | Rehearse your questions with an AI persona | Claude or ChatGPT (free) |
+| 2.3 | Find and book 10 ICP interviews (ICP = Ideal Customer Profile - the specific kind of person your hypothesis names) | Reddit, LinkedIn, X, UserInterviews.com |
+| 2.4 | Build a throwaway 3-screen clickable prototype | Lovable (free tier) |
+
+**The Mom Test is irreplaceable.** AI tools can tell you what people say online, but they cannot tell you whether a specific human will open their wallet. Without the interviews, you're building features for a problem nobody confirmed exists.
+
+> **After interviews, before the brief:** run your refined hypothesis through IdeaProof (70 free credits, no credit card). Its 4-model ensemble (Claude, GPT, Gemini, Grok) stress-tests your business logic and catches legal, economic, and competitive blind spots you haven't considered.
+
+---
+
+### Module 3 - Design from Evidence
+**You have:** 10 interview transcripts + prototype feedback.
+**You walk away with:** a one-page Product Brief written from real customer vocabulary.
+**Time:** ~3-5 days.
+
+| Step | What You Do | Key Tool |
+|---|---|---|
+| 3.1 | Write a one-page Product Brief - "Vibe PRD" (PRD = Product Requirements Document; the "Vibe" version is a one-pager an AI builder can act on, not a 30-page spec for a 6-person team) | Vibe PRD Template |
+| 3.2 | Quality-check: rewrite features as outcome-shaped job stories | Claude or ChatGPT (free) |
+
+The brief is the handoff document. It goes to Lovable, a hired developer, or a fractional CTO. It prevents over-engineering because it describes what the customer needs to accomplish, not what features to build. Every feature in the brief must trace back to a verbatim quote from a Module 2 interview.
+
+---
+
+### Module 4 - Build It Yourself
+**You have:** a one-page Product Brief.
+**You walk away with:** a build decision + a live MVP at a staging URL, with you owning every account.
+**Time:** ~2-4 weeks.
+
+| Step | What You Do | Key Tool |
+|---|---|---|
+| 4.1 | Decide: self-serve, fractional CTO (a part-time senior engineer who owns architecture but doesn't write all the code), or hired team | Build Path Decision Worksheet |
+| 4.2 | Lock ownership: GitHub, AWS, domain, database in your name | Ownership Checklist |
+| 4.3 | Ship the MVP: Lovable + Supabase + Stripe | Lovable + Supabase + Stripe (free tiers) |
+| 4.4 | Spot the 5 ceiling signals that mean it's time to graduate beyond no-code | - |
+
+> **Before you write code: the $0 Concierge MVP.** If you're not ready to commit to a full Lovable build, use Tally + Zapier (or Make.com) + Airtable to simulate your product's backend. Collect customer requests through a Tally form, route them to Airtable via Zapier, and process them manually. The customer experiences a working product. You validate demand before writing a line of code. All three tools have free tiers.
+
+---
+
+### Module 5 - First Paying Customer
+**You have:** a live MVP at a real URL.
+**You walk away with:** one signed paid pilot ($500+ deposit) + a repeatable outbound channel.
+**Time:** ~2-4 weeks.
+
+| Step | What You Do | Key Tool |
+|---|---|---|
+| 5.1 | Run the Sean Ellis PMF test (PMF = Product-Market Fit; one survey question: "how would you feel if you could no longer use this product?" 40%+ "very disappointed" = signal) on your earliest users | PMF survey template |
+| 5.2 | Pick one outreach channel and commit before scaling | Channel selection framework |
+| 5.3 | Convert warm personal network into first paid pilots | Personalized DMs |
+| 5.4 | Sign a Design Partner Agreement - "DPA" (a short contract where a customer pays a deposit to test your product as a co-design partner; cheaper and faster than a full enterprise contract) - with a refundable deposit | DPA template + Stripe |
+| 5.5 | Go cold outbound: 30 filtered messages, book 1-2 pilots | LinkedIn Sales Navigator or manual |
+
+**Important distinction:** Your warm network is for your first PAID PILOT (a sales motion - valid). Your warm network is NOT for problem validation (an echo chamber - invalid). Friends and other founders will tell you your idea is great because they're being polite. Only cold strangers who describe the problem in their own words and pay money produce a real signal.
+
+> **Going further:** After your first paid pilot, the course has continuation chapters for churn triage, pivot-or-persevere decisions, hiring, management (Friday Demo Rule, Weekly Dev Report), and AI-era topics (token bill auditing, slopsquatting, agency AI questions).
+
+---
+
+## The Tool Stack: When to Use What
+
+These are the tools the course references - AI research tools, no-code builders, and infrastructure. Most have free tiers sufficient for the validation stage.
+
+

+Pre-Hypothesis Research (before Module 1) - 3 tools
+
+| Tool | What It Does | When to Use | Cost |
+|---|---|---|---|
+| **Perplexity** | AI search engine that bypasses paywalls, aggregates competitor complaints | Map the market, find what users hate about existing solutions | Free tier |
+| **Trend Seeker** | Semantic search across Reddit/forums for demand signals | Confirm people are actually searching for solutions to your problem | Free daily limit |
+| **Reddinbox** | Automated Reddit/Quora search for high-commercial-intent phrases | Find posts where people explicitly ask "how to automate X" or "sick of doing Y" | Setup required |
+
+

+
+

+Hypothesis Stress-Testing (during Module 2) - 3 tools
+
+| Tool | What It Does | When to Use | Cost |
+|---|---|---|---|
+| **ValidatorAI** | Dialog-based AI advisor, rates your idea and finds blind spots | Rapid "devil's advocate" feedback before interviews | Unlimited free |
+| **IdeaProof** | 4-model ensemble (Claude, GPT, Gemini, Grok) cross-validates business logic | After Mom Test interviews, before writing the Product Brief | 70 free credits |
+| **Preuve AI** | Evidence-based scoring from 40+ live data sources with citations | Before building, when you need a data-backed viability check | Free basic score |
+
+

+
+

+Build & Launch (Modules 1, 4, 5) - 6 tools
+
+| Tool | What It Does | When to Use | Cost |
+|---|---|---|---|
+| **Carrd / Neeto** | One-page landing page builder | Smoke test (Module 1) | Free tier (subdomain) |
+| **Stripe Payment Links** | Hosted checkout without writing code | Price hypothesis test (Module 1), paid pilot deposit (Module 5) | Pay-as-you-go (2.9% + $0.30) |
+| **Lovable / Bolt.new** | AI app builder from text prompts | Clickable prototype (Module 2), MVP build (Module 4) | Free tier |
+| **Supabase** | Hosted Postgres + auth + realtime | MVP backend (Module 4) | Free tier |
+| **Tally + Zapier + Airtable** | "Wizard of Oz" no-code stack (a fake-it-till-you-make-it pattern: the customer thinks software is running, but you do the work by hand behind the scenes to test demand before you build the real thing) | Concierge MVP before committing to a code build (Module 4 alt path) | Free tiers |
+| **WorthBuild** | Auto-parses social media for leads, generates personalized outreach messages | After validation, setting up first-customer pipeline (Module 5) | 1 free check/mo |
+
+

+
+

+
+## The Course's Rule: Kill Bad Ideas Fast
+
+Every module has a gate. If the data doesn't support your hypothesis, you stop and either pivot or kill the idea. The gate sends you back if the data doesn't support the hypothesis.
+
+| Module | The Gate | Signal to Proceed |
+|---|---|---|
+| 1 | Landing page conversion | ≥3% of cold visitors click your CTA |
+| 2 | Mom Test interviews | ≥7 of 10 interviewees have spent time or money on the problem |
+| 3 | Product Brief quality check | Every feature traces back to a verbatim interview quote |
+| 4 | MVP at staging URL | You own every account; the app loads; one core flow works end-to-end |
+| 5 | First paid pilot | Signed DPA + $500+ Stripe deposit received |
+
+If you fail a gate, the system requires you to go back, not forward. Six weeks and zero budget lost is the cheapest failure you'll ever buy. The alternative is years and tens of thousands of dollars building something nobody wants.
+
+

+
+---
+
+## Start Here
+
+Read the overview once. Then start at [Module 1, Chapter 1.1: Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/). Come back to this page when you need to see where you are in the full route.
+
+If you're not at the idea stage - you have a half-built MVP, an inherited codebase, or a team that's already failing - skip the linear path and go to the [If Your Team Is Already Failing](/course/tech-for-non-technical-founders-2026/#if-your-team-is-already-failing) section on the course landing page.
+
+> **Done when:** You have read the full route and know which module to start with.
+> **Next click:** [1.1 · Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/)
+> **If blocked:** If your idea is too vague to fill the hypothesis blanks, start at the [If Your Team Is Already Failing](/course/tech-for-non-technical-founders-2026/#if-your-team-is-already-failing) section on the course landing page.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum. Research sources: June 2026 AI validation tools market analysis, 29 sources across Indie Hackers, Reddit, Product Hunt, and VC.ru.*
diff --git a/content/course/tech-for-non-technical-founders-2026/how-this-course-works/module-pipeline.svg b/content/course/tech-for-non-technical-founders-2026/how-this-course-works/module-pipeline.svg
new file mode 100644
index 000000000..a1f2774bc
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/how-this-course-works/module-pipeline.svg
@@ -0,0 +1,123 @@
+
+  5-module course pipeline: Hypothesis → Validate → Design → Build → First Paying Customer
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
+  
+
+  
+  The 5-Module Pipeline
+  Each module's output is the next module's input — from rough idea to signed paid pilot
+
+  
+  
+  Module 1
+  Hypothesis
+  & Smoke Test
+  
+  ~7 days
+  
+  Artifact:
+  Hypothesis +
+  Smoke Test
+  STAGE 1
+
+  
+  
+    
+    
+  
+  →
+
+  
+  
+  Module 2
+  Validate the
+  Problem
+  
+  ~2-3 weeks
+  
+  Artifact:
+  10 Interviews +
+  Problem Stmt
+  STAGE 2
+
+  
+  
+    
+    
+  
+
+  
+  
+  Module 3
+  Design from
+  Evidence
+  
+  ~3-5 days
+  
+  Artifact:
+  Product Brief /
+  Vibe PRD
+  STAGE 3
+
+  
+  
+    
+    
+  
+
+  
+  
+  Module 4
+  Build It
+  Yourself
+  
+  ~2-4 weeks
+  
+  Artifact:
+  Live MVP at
+  real URL
+  STAGE 4
+
+  
+  
+    
+    
+  
+
+  
+  
+  Module 5
+  First Paying
+  Customer
+  
+  ~2-4 weeks
+  
+  Artifact:
+  Signed Paid
+  Pilot
+  DONE
+
+
diff --git a/content/course/tech-for-non-technical-founders-2026/module-1-walkthrough-mia/index.md b/content/course/tech-for-non-technical-founders-2026/module-1-walkthrough-mia/index.md
new file mode 100644
index 000000000..ea13c9b3e
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/module-1-walkthrough-mia/index.md
@@ -0,0 +1,99 @@
+---
+title: "Module 1 Walkthrough: Mia Builds TutorMatch"
+description: "Follow Mia through Module 1 as she writes a Founding Hypothesis, builds a smoke-test page, installs tracking, runs cold traffic, and price-tests  --  all before writing a line of product code."
+date: 2026-06-11
+draft: true
+slug: module-1-walkthrough-mia
+---
+
+> **Module 1 walkthrough · Mia** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> *Illustrative composite based on patterns from real founder builds, not a single client story.*
+
+Mia is a former special-ed teacher who watched parents of kids with dyslexia and ADHD burn evenings Googling "tutor near me," calling dead numbers, and settling for whoever answered the phone. Her idea: a marketplace where parents search by specialty and get matched with a vetted tutor in 48 hours.
+
+---
+
+## [Lesson 1.1: Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/)
+
+**Input:** A rough idea and three years of watching parents struggle.
+
+**Challenge:** Mia's first draft of her hypothesis was: "If we help parents find tutors, they will choose us over Google." Every blank was a category, not a noun. She knew it was useless before she finished writing it.
+
+**Action:** She went to r/Dyslexia and r/ADHD and searched "tutor." She found a parent who wrote: *"I've called 11 tutoring centers this month. Five never called back. Three said they don't specialize in dyslexia. Two had waitlists. One told me their 'learning differences' program was a generic curriculum with a different label."* Mia copied that verbatim into her [problem] blank. The [customer] blank became "parents of kids 8-14 with dyslexia/ADHD." The [competition] became "Googling and calling dead numbers."
+
+**Result:** Her final hypothesis read: *"If we help parents of kids 8-14 with dyslexia/ADHD solve finding a vetted specialist tutor with a search-by-specialty marketplace, they will choose it over Googling and calling dead numbers because it matches them in 48 hours with parent reviews."* She scored it: Customer 5/5, Pragmatic 4/5, Growth 3/5, Money 3/5. Total: 15/20. Weakest blank: Growth  --  she doesn't know if parents search by specialty or by location.
+
+---
+
+## [Lesson 1.2a: Build the Page](/course/tech-for-non-technical-founders-2026/smoke-test-build-page/)
+
+**Input:** A one-sentence Founding Hypothesis with Growth as the weakest blank.
+
+**Challenge:** Mixo's first draft gave her a headline that read "Smart Tutoring Solutions for Modern Families." A parent scrolling Instagram at 10pm would not recognize themselves in that sentence. She regenerated twice.
+
+**Action:** She pasted her hypothesis into ChatGPT: *"Turn this hypothesis into 3 outcome-focused value props, max 6 words each."* The output: "Specialist tutor in 48 hours," "No more dead phone numbers," "Parent-reviewed, not algorithm-matched." She replaced the hero image with a photo of a parent on the phone at 9pm  --  the exact pain her hypothesis named. She stripped Pricing, FAQ, and Testimonials blocks that Mixo added. CTA: "Get matched with a specialist."
+
+**Result:** She sent the URL to her neighbor, who has a son with ADHD. "In three seconds, who is this for and what does it do?" The neighbor said: "Parents of dyslexic kids  --  you find them tutors fast." Three seconds. Clarity test passed.
+
+Now she needs to know who visits.
+
+---
+
+## [Lesson 1.2b: Wire Tracking](/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/)
+
+**Input:** A live landing page at `tutormatch.mixo.io`.
+
+**Challenge:** Mia had never touched a tracking tool. She didn't know what a "snippet" or "head-tag" was, and the idea of pasting code into her page builder made her nervous.
+
+**Action:** She signed up at clarity.microsoft.com, copied the snippet, pasted it into Mixo's Custom Code → Header field. Then she created a GA4 property at analytics.google.com, copied the Measurement ID, and pasted it in the same head-tag field. The lesson said her channel-specific pixel (Meta Pixel) gets installed in 1.2c after she picks her channel — she'd return to business.facebook.com then.
+
+When she checked Clarity five minutes later, it still showed "No data yet." She had pasted the Clarity snippet in the body field instead of the head-tag field. One field higher in Mixo's settings, refresh, and the recording appeared. Twenty-five minutes total, including the fix.
+
+**Result:** She opened her page in an incognito window. Within 60 seconds, Clarity showed her own session recording. GA4's Realtime report showed one active user. Both verified. She made a note: install Meta Pixel in 1.2c. Done.
+
+---
+
+## [Lesson 1.2c: Run the Smoke Test](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/)
+
+**Input:** A live page with Clarity + GA4 installed. Meta Pixel still needed.
+
+**Challenge:** Her Growth lens scored 3/5. She doesn't know whether parents search by "dyslexia tutor" (specialty) or "tutor near me" (location). Her Meta ad creative would test both — but which to lead with? She also had $400 total to spend, needed to install her Meta Pixel (deferred from 1.2b), and was nervous about burning budget with no signal.
+
+**Action:** First, she installed her Meta Pixel — business.facebook.com → Events Manager → create pixel → copy snippet → paste in Mixo's head-tag field. Same process as Clarity in 1.2b, under two minutes. Incognito check: pixel fired. Then she picked Meta Ads (B2C consumer, $0.90 CPC target) and followed the campaign creation recipe from the channel guide. She ran two ad variants, $200 each: one targeting "dyslexia tutor" search interest, one targeting "ADHD tutor + [city]" geography. She launched on a Monday and did not touch the page for seven days. No headline rewrites. No bid adjustments.
+
+**Result:**
+- Ad 1 (specialty search): 6.5% conversion. **Strong.**
+- Ad 2 (location search): 3.5% conversion. **Iterate band.**
+- Combined: 4.8% across all 300 visits. Specialty outperformed location by nearly 2x.
+
+Her weakest Growth blank was partially answered: parents search by specialty, not by location. The specialty variant alone cleared at 6.5%  --  even though combined was only 4.8%. Her decision: advance to the price test (Lesson 1.3), and keep the location variant as a test for later.
+
+---
+
+## [Lesson 1.3: Price Hypothesis](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/)
+
+**Input:** A live page with 300 cold visits and a 4.8% combined conversion rate (6.5% on the winning variant).
+
+**Challenge:** Mia had no idea what parents pay for tutoring. Her Money lens scored 3/5 because she guessed $25/session based on what her old school charged for after-school programs  --  not what parents actually paid private tutors.
+
+**Action:** She set up a Stripe account on Friday night, uploaded her ID, and was approved by Tuesday. She created a Payment Link at "$99 founding member  --  4 months access at $25/mo equivalent" (one-time, per the lesson's one-time advice). Button copy: "Find your kid's specialist  --  $99 founding member rate." She added a "Full refund within 30 days if we don't ship" line in the footer. Below the button: "Not ready? Join the free waitlist instead." For the redirect, she used the Mixo path: redirect to her main page URL (the lesson said same-URL tracking is rougher but works for a first test).
+
+**Result:** 6% of visitors clicked the Stripe link, 6 completed payments at $99 each  --  a strong price signal for a pre-product page. Her Money lens was wrong  --  parents pay more than $25. She notes this for Module 2 interviews: ask parents what they currently spend on tutoring, not what they'd pay for a marketplace.
+
+---
+
+## What Mia Walked Away With at the End of Module 1
+
+- **Founding Hypothesis:** One sentence, five specific blanks, scored 15/20. Weakest blank: Growth (specialty vs. location).
+- **Live landing page:** `tutormatch.mixo.io` with a headline that passed the 3-second clarity test.
+- **Tracking:** Clarity + GA4 installed (1.2b), Meta Pixel installed (1.2c), all verified.
+- **Conversion data:** 4.8% combined (6.5% on specialty variant). Growth blank partially answered: parents search by specialty.
+- **Price signal:** 6 completed Stripe payments at $99. Parents will pay more than $25.
+- **Founder OS folder:** All five lesson outputs saved in one Google Drive folder.
+
+**Next: Module 2, where Mia interviews 10 parents using the Mom Test.** Her interview script will test whether parents have ever spent real money on a specialist tutor search  --  the [problem] blank  --  and what they currently pay, to tighten her Money lens.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) free curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/cover.png b/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/cover.png
new file mode 100644
index 000000000..82686dc63
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/good-vs-bad-answers.svg b/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/good-vs-bad-answers.svg
new file mode 100644
index 000000000..72581e77f
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/good-vs-bad-answers.svg
@@ -0,0 +1,76 @@
+
+  Mom Test answers - polite hypothetical vs specific past behavior
+  Bad answer: yeah I would totally pay for that. Good answer: last Tuesday 9pm I spent 40 minutes copying spreadsheets and called my CFO. The good answer has a date a time a tool a person a duration and feeling.
+  
+    
+  
+
+  
+
+  Same interviewee. Same problem. Opposite signal.
+  The question wording decides which answer you get.
+
+  
+  
+  
+  vs
+
+  
+  
+  BAD - polite hypothetical
+
+  You asked:
+  "Would you pay $49/month for a tool
+  that automates this reporting?"
+
+  They said:
+  "Yeah I'd totally pay for that!
+  Sign me up when it ships."
+
+  What you learned:
+  - No date, no real story
+  - No quantified pain
+  - No workaround mentioned
+  - Hypothetical commitment
+
+  Score: 2/10
+  Interviewee was kind.
+  They will not pay you.
+  8 of these = 0 customers.
+
+  
+  
+  GOOD - past behavior
+
+  You asked:
+  "Tell me about the last time
+  you ran a board report. Walk me
+  through what you did."
+
+  They said:
+  "Last Tuesday 9pm I spent 40 min
+  copying spreadsheets into a deck.
+  Called my CFO. I felt stupid."
+
+  What you learned:
+  - Date, time, tool, person, duration
+  - Emotional flag: "felt stupid"
+  - A real recent incident
+  - Workaround named (CFO did it)
+
+  Score: 8/10
+  Real felt problem.
+  7+ of these = validated.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/index.md b/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/index.md
new file mode 100644
index 000000000..e3dc80f03
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/index.md
@@ -0,0 +1,224 @@
+---
+title: "2.1 · The Mom Test: Ask About the Past, Not the Future"
+aliases: ["/blog/mom-test-ask-about-past-not-future/"]
+description: "Chapter 2.1 of the From Idea to First Paying Customer course. The 5-question Mom Test script that prevents your interviewees from being polite - past-behavior validation for non-technical founders."
+date: 2026-05-13
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: mom-test-ask-about-past-not-future
+keywords:
+  - mom test customer interviews
+  - ask past behavior not hypothetical
+  - founder interview script
+  - validate without lying
+  - customer interview questions 2026
+tags:
+  - founders
+  - non-technical-founder
+  - customer-research
+  - validation
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "2.1 · The Mom Test: Ask About the Past, Not the Future"
+  og_description: "Chapter 2.1 of the From Idea to First Paying Customer course. The 5-question Mom Test script that prevents your interviewees from being polite - past-behavior validation for non-technical founders."
+cover_image_alt: "JetThoughts cover showing five Mom Test question cards stacked vertically with pass and fail signals on each card"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/"
+related_posts: false
+---
+
+> **Module 2 · Step 1 of 4** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a Founding Hypothesis sentence (from Ch 1.1) + 3 ICP characteristics (ICP = Ideal Customer Profile - the specific kind of person your hypothesis names; introduced in Ch 1.1)
+>
+> **Output:** the 5-question Mom Test template + a draft question list (5-8 questions) ready to sharpen in Ch 2.2 and then run in real interviews after Ch 2.3 (a + b) recruitment. The scoring rubric becomes your reference card once you have transcripts in hand.
+
+> **TL;DR:** Five questions, all anchored in past behavior. Ask what they did last Tuesday, not what they'd do with a hypothetical product. Skip to: [The 5 questions ↓](#the-5-questions) · [The 3 emotional flags ↓](#the-3-emotional-language-flags) · [What to do tomorrow ↓](#what-to-do-tomorrow).
+
+> **Where you are in the round:** If you do not have interview transcripts yet, read straight through. After your Ch 2.3 (a + b) interviews, return to [Mom Test Synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) to score your transcripts and decide build/pivot/kill.
+
+Run eleven interviews where the only question is "would you pay for this?" and you'll close the week with nine yeses and an empty launch. The hypothetical question produces the polite shape - the answer says nothing about what the person actually did last Tuesday.
+
+The technique below switches every question to the past tense. What did you do last time? What did it cost? Show me the spreadsheet. Past-tense questions force the answer back into reality; whoever pays in the past keeps paying in the future, and whoever did nothing in the past will do nothing in the future no matter what they tell you over coffee.
+
+For the verbatim script + reference card, see [Mom Test Interview Script](/course/tech-for-non-technical-founders-2026/mom-test-interview-script/). This chapter teaches *why* those five questions work and how you'll score each call once interviews are done.
+
+Next, sharpen your draft list with [AI personas in Ch 2.2](/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/), then recruit 10 interviewees in [Ch 2.3 (a + b)](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/).
+
+![Five Mom Test question cards stacked: last-time, cost, workaround, priority, buying committee. Each card shows the pass and fail signal.](mom-test-script.svg)
+
+Rob Fitzpatrick's book [The Mom Test](https://www.momtestbook.com/) (2013) named the technique that prevents the polite-yes problem.
+
+The core idea: ask interviewees to recount what they actually did the last time the problem happened, not what they think they'd do about a product you describe to them.
+
+## The 5 questions you'll be tempted to ask (and why each one fails)
+
+Before the working script, look at the questions a non-technical founder almost always writes on the first attempt. Each one feels like it's getting to the truth; each one is engineered to surface a polite lie.
+
+| The question you'd write | Why it produces polite-yes | Fitzpatrick's past-behavior rewrite |
+|---|---|---|
+| "Do you find [problem] frustrating?" | Leading. The interviewee hears that you want a yes; their politeness reflex supplies one. | "Tell me about the last time [problem] happened." |
+| "Would you use a tool that solved [problem]?" | Hypothetical-future. Their answer is a guess about a person who doesn't exist yet (their future self imagining a product that doesn't exist yet). | "Walk me through what you did the last time you tried to handle [problem]." |
+| "How important is solving [problem] for you?" | Asks for a self-rating, which everyone inflates. People rate everything 7/10 to avoid sounding rude. | "What did the workaround cost you - in time, money, or sanity - the last time?" |
+| "Would you pay $X for a solution?" | Pricing hypothetical. They have no skin in the game; saying yes costs them nothing. | "What have you already tried, paid, or built to deal with it?" |
+| "Does this idea sound good to you?" | Compliment-fishing. The interviewee can't refuse without being mean to you. | "On a scale of 1-10, how would you rank fixing [problem] this year against the other 3 things on your list?" |
+
+Every bad question above asks the interviewee to predict the future, rate something abstractly, or evaluate your idea - three different ways of asking them to imagine a future they have not lived yet. The rewrites all ask them to recount a specific past event instead, so the answer comes from memory and not from politeness.
+
+## The 5 questions
+
+The script runs in order. Each question funnels the interviewee deeper into a real memory of the problem. Read the questions as written - small wording changes ("would you" instead of "did you") flip the answer back into hypothetical polite, which is exactly the failure mode you are paying 30 minutes to avoid.
+
+#### Q1: "Tell me about the **last time** [problem] happened. Walk me through what you did."
+
+- **What it catches**: whether the problem actually happens, how often, what mechanic the interviewee uses. A real story has a date and a tool.
+- **Pass**: specific recent story. *"Last Tuesday at 9pm I spent 40 minutes copying numbers from three spreadsheets into a slide for the board."* Date, time, tool, duration, feeling.
+- **Fail**: vague generality. *"Yeah I usually struggle with reporting."* No date, no mechanic - autopilot polite mode.
+- **Follow-up**: *"Walk me through that specific Tuesday again. What did you do first?"*
+
+#### Q2: "What did that **cost** you - in time, money, or sanity?"
+
+- **What it catches**: whether the pain is quantifiable. Separates "this is annoying" from "I'd pay $200/month to make this stop."
+- **Pass**: a number with a unit. *"Two hours every Tuesday for six months."* / *"My CFO bills $200/hour and spent four hours on it last week."*
+- **Fail**: *"It costs us time."* / *"It's frustrating."* Unquantified. Polite about a problem they don't actually feel.
+- **Follow-up**: *"If you had to put a dollar figure on it - or hours, or 'I'd quit my job over this' - what's the number?"*
+
+#### Q3: "What have you **tried already** to fix this?"
+
+- **What it catches**: existing workarounds. A hack, a paid tool, a hired VA, two spreadsheets duct-taped = real. Nothing tried = theoretical.
+- **Pass**: a named tool, a hired person, a custom script. *"I pay $79/month for Zapier to copy QuickBooks to Google Sheets. It breaks every two weeks. My VA on Upwork fixes it."*
+- **Fail**: *"Nothing yet."* / *"We just deal with it."* / *"I've been meaning to look into something."*
+- **Follow-up**: *"What broke about the workaround? Why are you still talking to me about this?"* The crack is the gap your product would fill.
+
+#### Q4: "On a scale of **1-10**, how big a problem is this compared to everything else on your plate?"
+
+- **What it catches**: urgency against the interviewee's whole problem stack. A 9 is a sales conversation. A 4 is a pat on the head and zero dollars.
+- **Pass**: a 7 or higher **with a comparison**. *"This is an 8. The only thing higher is hiring my next engineer."*
+- **Fail**: a 5-6 with soft justification, or a bare "probably a 7" with no comparison (the polite-default 7 - treat as a 5 until Q5 proves otherwise).
+- **Follow-up**: *"What's at 10 for you right now? What would have to happen for this to climb to that 10 spot?"*
+
+#### Q5: "**Who else** on your team feels this? How do they handle it?"
+
+- **What it catches**: the buying committee + workarounds other people in the company already built. In B2B, your interviewee is not the only nodder when the invoice arrives.
+- **Pass**: a specific colleague named + their workaround. *"My ops manager Jess feels this worse than I do - she keeps a parallel Google Sheet because she doesn't trust the finance numbers from accounting."*
+- **Fail**: *"I'm the only one who deals with this."* / *"Everyone else is fine."*
+- **Follow-up**: *"Could you introduce me to Jess?"* An interviewee who won't make a 30-second intro probably won't pay you $49/month either.
+
+![Side-by-side comparison of a bad polite hypothetical answer and a good specific past-behavior answer, with what each tells you in the margin.](good-vs-bad-answers.svg)
+
+## The 3 emotional-language flags
+
+While the script runs, your job is to listen for three patterns. These flags do more work than the words "yes" and "no" the interviewee gives you.
+
+| Flag | Example Phrases | What it signals |
+|---|---|---|
+| **Frustration language** | "I hate this." "It drives me crazy." "Every single week." "I can't believe we still do it this way." | If the interviewee uses words with feeling, the problem is felt. Polite interviewees suppress feeling - the opposite of what validation needs. |
+| **Workaround language** | "I've been meaning to..." "We hacked together..." "I pay [tool] $X for this." "My VA does it manually." | Workarounds prove the problem is real because the interviewee already spent time or money on a solution that doesn't fully work. The workaround budget is the line item your product would replace. |
+| **Urgency language** | "Last week." "This morning." "I missed my kid's birthday because of this." | A problem that happened today is felt more sharply than a problem that happens "sometimes." Time-anchored urgency is the strongest signal in the set. |
+
+**Scoring the flags:** A passing call has 3 or more flags spread across the five answers. A failing call has 0 or 1 - the interviewee is being polite to you. Two flags is ambiguous; treat as a 5/10 default.
+
+## The interview flow
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    Start(["Call starts.
Script open on second screen."])
+    Start --> Q1[Q1 - Last time it happened?]
+    Q1 --> Listen{Listen for emotional
language flags}
+    Listen -->|0-1 flags| Generic[Generic polite mode
Ask the follow-up]
+    Listen -->|2+ flags| Real[Real felt problem
Move to Q2]
+    Generic --> Q1
+    Real --> Q2[Q2 - What did it cost?]
+    Q2 --> Q3[Q3 - What have you tried?]
+    Q3 --> Q4[Q4 - 1-10 vs everything else?]
+    Q4 --> Q5[Q5 - Who else feels this?]
+    Q5 --> Score{Score the call
1-10}
+    Score -->|7+ with comparison
3+ flags| Validated[Strong signal
Ask for intro and prototype]
+    Score -->|5-6 or weak
1-2 flags| Weak[Polite default
Score as 5]
+    Score -->|0-4 or 0 flags| Fail[No felt problem
Discount the call]
+    Validated --> Next[10 calls done
7+ scores of 7+ means validated]
+    Weak --> Next
+    Fail --> Next
+
+    classDef start fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a
+    classDef q fill:#fff5f5,stroke:#cc342d,stroke-width:2px,color:#1a1a1a
+    classDef decision fill:#faf5ff,stroke:#a855f7,stroke-width:2px,color:#1a1a1a
+    classDef pass fill:#f0f9f0,stroke:#2e7d32,stroke-width:2px,color:#1a1a1a
+    classDef warn fill:#fffbe6,stroke:#bf8a00,stroke-width:2px,color:#1a1a1a
+    classDef fail fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#1a1a1a
+
+    class Start start
+    class Q1,Q2,Q3,Q4,Q5,Real q
+    class Listen,Score decision
+    class Validated,Next pass
+    class Weak,Generic warn
+    class Fail fail
+```
+
+Stick to the order. Improvise mid-call ("oh that reminds me of my product idea") and you contaminate the rest of the transcript - the interviewee starts answering the pitch instead of describing their own life. Read the questions as written, take notes by hand, score after.
+
+## What to do tomorrow
+
+Three actions. In order.
+
+| Action | Why it matters | Gotcha to avoid |
+|---|---|---|
+| **Print [the Mom Test interview script artifact](#the-mom-test-interview-script-artifact) and open it on a second screen during the call.** Read the questions as written. | The wording does the work - if you paraphrase, you slip back into polite-yes mode and waste the call. | Don't improvise mid-call. Read as written. |
+| **Take notes by hand, not by typing.** | Hand-writing slows you down enough that you stop transcribing and start listening for the three emotional flags. Typing during a call turns you into a court reporter. | Don't try to transcribe everything. Write the Q4 score and the flag count, not the full transcript. |
+| **Score the call 1-10 within 5 minutes of hanging up.** Use Q4 plus your emotional-flag count. | If you score later, you will round up. By interview 10 you have a validation total, not 10 unsorted transcripts. | Don't defer scoring. Your gut scoring in the moment is more honest than the one after a week of wanting the number to be higher. |
+
+Sometimes Q1 is wrong - the problem context is too narrow - and a broader framing wakes the interviewee up.
+
+The [stop-looking-for-product-market-fit guide](/blog/stop-looking-for-product-market-fit-startup-tutorial/) covers what the validation signal does and doesn't tell you about whether you have product-market fit (spoiler: a validated problem is necessary, not sufficient).
+
+## The Mom Test interview script artifact
+
+The artifact at **[/course/tech-for-non-technical-founders-2026/mom-test-interview-script/](/course/tech-for-non-technical-founders-2026/mom-test-interview-script/)** carries the same 5 questions verbatim, the follow-ups, the pass/fail signals, the 3 emotional-language flags, and the scoring rubric.
+
+**Save your draft list before moving on.** Open a new Google Doc titled `Mom Test draft - [date]` in the same `Founder OS` folder as your Founding Hypothesis. Copy the 5 verbatim questions from the artifact, then add 2-3 ICP-specific probes of your own (e.g., for a chiropractor ICP: "Walk me through your last insurance-claim resubmission. When did it happen?"). That 5-8 question list is the input Ch 2.2 expects you to sharpen against AI personas.
+
+**How to use it:** Print the artifact. Keep it open on your second monitor during all 10 interviews. The artifact is the screen-side reference while this post is the explanation of why it works.
+
+After 10 calls, you have either 10 scored transcripts that converge on a real problem (proceed to [Chapter 2.4: Clickable Prototype Validation](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/)) or 10 transcripts that don't (re-frame the ICP and run another 10).
+
+Fake the convergence to start building anyway, and you join the long line of post-mortem threads about wasted MVP spend. The [quality tax for AI MVPs](/blog/quality-tax-ai-mvp-cost/) is what happens when you ship against a hypothesis nobody confirmed.
+
+> Most customer interviews fail because the interviewees are polite. Better questions outperform better people.
+>
+> Anchor every question in a specific past moment - last Tuesday at 9pm, the last invoice, the last time the spreadsheet broke - and the polite-mode answers run out fast.
+
+> **Optional: AI devil's advocate before your first interview.** [ValidatorAI](https://validatorai.com) (free, unlimited use, no credit card) gives you an adversarial dialog: paste your draft question list, and it pushes back the way a skeptical interviewee would.
+>
+> It flags hypothetical questions, leading phrasing, and assumptions buried in your wording. Unlike Ch 2.2 persona rehearsal (which tests questions against simulated ICPs), ValidatorAI tests the questions themselves - are they built to surface real past behavior or polite agreement?
+>
+> Run it once before your first interview. It takes 5 minutes and catches the most common failure mode: a question list that produces coherent answers from anyone, regardless of whether they actually have the problem.
+
+After all 10 interviews, return to [Mom Test Synthesis: Build, Pivot, or Kill](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) to score your transcripts, count strong signals, and make the build / pivot / kill decision. That page has the 3-step synthesis, the decision flowchart, and the good-vs-bad problem statement examples.
+
+## Further reading
+
+- Rob Fitzpatrick, [The Mom Test (book site)](https://www.momtestbook.com/) - the canonical reference. The book runs 130 pages and explains why "would you pay for X?" is the most popular question and the worst.
+- Y Combinator, [How to Talk to Users (Startup Library)](https://www.ycombinator.com/library/6g-how-to-talk-to-users) - YC's distilled rules for the same conversation, free and 20 minutes.
+- Steve Blank, [The Four Steps to the Epiphany - Customer Discovery](https://steveblank.com/category/customer-development/) - the original customer-development methodology Fitzpatrick's script sits inside.
+- Teresa Torres, [Continuous Discovery Habits](https://www.producttalk.org/continuous-discovery-habits/) - what these interviews become after the validation phase, when you run them weekly forever.
+- Mom Test summary by Yann Klis, [The Mom Test - 1-page summary](https://yannklis.com/posts/the-mom-test/) - a compressed cheat sheet for anyone who can't read the full book this week.
+- Lenny Rachitsky, [Customer interviewing 101](https://www.lennysnewsletter.com/p/the-ultimate-guide-to-conducting) - the operational version of the Mom Test rules with sample scripts.
+
+> **Done when:** You understand the 5 Mom Test questions, can spot hypothetical phrasing, and have a draft question list (5-8 questions) anchored in past behavior.
+>
+> **Next click:** [2.2 · Sharpen Your Question List with AI Personas](/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/)
+>
+> **If blocked:** If the technique isn't clicking, open the [Mom Test Interview Script](/course/tech-for-non-technical-founders-2026/mom-test-interview-script/) artifact - it has the 5 questions verbatim. Print it, practice on a friend, then return.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Runs 10 interviews with accounting firm controllers. Q2 hits hard: "My CFO bills $200/hr and spent 4 hours on reconciliation last week - that's $800." Scored 8/10 on 7 interviews. Validated.
+>
+> **Mia**: Runs 10 interviews with parents from Facebook groups. Q3 surfaces the real pain: "I missed a $2,000 client deadline because I was on hold with a tutoring center." Scored 9/10 on 8 interviews. Strongly validated.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/mom-test-script.svg b/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/mom-test-script.svg
new file mode 100644
index 000000000..591d5c872
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/mom-test-script.svg
@@ -0,0 +1,74 @@
+
+  The Mom Test 5-question script - past-behavior interview questions
+  Card 1 last-time question. Card 2 cost in time money sanity. Card 3 what have you tried already. Card 4 1-10 priority. Card 5 who else on your team.
+  
+    
+    
+      
+    
+  
+
+  
+
+  The Mom Test interview script - 5 questions, read as written.
+  Anchors in past behavior. Listens for emotional language. Scores 1-10.
+
+  
+  
+  Q1
+  The last-time question
+  "Tell me about the last time [problem] happened. Walk me through what you did."
+  PASS: A date, a time, a tool, a person. "Last Tuesday 9pm I called my CFO..."
+  FAIL: "Yeah I usually struggle with this." No date, no story.
+
+  
+
+  
+  
+  Q2
+  The cost question
+  "What did that cost you - in time, money, or sanity?"
+  PASS: A number with a unit. "2 hours every Tuesday for 6 months." "$800 in CFO time."
+  FAIL: "It costs us time." Unquantified. Polite about an unfelt problem.
+
+  
+
+  
+  
+  Q3
+  The workaround question
+  "What have you tried already to fix this?"
+  PASS: A named tool or hired person. "I pay Zapier $79/mo. My VA fixes it weekly."
+  FAIL: "Nothing yet." "We just deal with it." No workaround = no urgency.
+
+  
+
+  
+  
+  Q4
+  The priority question
+  "On a 1-10 scale, how big is this compared to everything else on your plate?"
+  PASS: 7+ with a comparison. "This is 8. Only hiring is higher."
+  FAIL: A polite 7 with no comparison. "Probably a 7." Default kindness, not urgency.
+
+  
+
+  
+  
+  Q5
+  The buying-committee question
+  "Who else on your team feels this? How do they handle it?"
+  PASS: Names a colleague + their workaround. "Jess keeps a parallel sheet she trusts more."
+  FAIL: "Just me." Either small/local or they don't know how the team works.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/mom-test-interview-script/cover.png b/content/course/tech-for-non-technical-founders-2026/mom-test-interview-script/cover.png
new file mode 100644
index 000000000..7c78479e3
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/mom-test-interview-script/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/mom-test-interview-script/index.md b/content/course/tech-for-non-technical-founders-2026/mom-test-interview-script/index.md
new file mode 100644
index 000000000..8233f3941
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/mom-test-interview-script/index.md
@@ -0,0 +1,157 @@
+---
+title: "Mom Test Interview Script: 5 Questions for Past Behavior"
+aliases: ["/blog/mom-test-interview-script/"]
+description: "Rob Fitzpatrick's Mom Test technique as a copy-pasteable 5-question script. Read on a second screen during the call. Score each interview 1-10."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: mom-test-interview-script
+keywords:
+  - mom test interview script
+  - founder customer interview
+  - rob fitzpatrick mom test
+  - validate without polite lying
+  - past behavior interview
+tags:
+  - founders
+  - non-technical-founder
+  - template
+  - course-companion
+  - validation
+categories: ["Templates"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/mom-test-interview-script/"
+related_posts: false
+---
+
+📋 Template companion to the [Chapter 2.1 post](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/). Open on a second screen during the call. Read questions verbatim.
+
+# The Mom Test Interview Script - Ask About the Past, Not the Future
+
+*Five questions that get the interviewee to tell you what they actually did, not what sounds polite.*
+
+> **The 5 Mom Test questions, in order:**
+> Q1. Tell me about the last time [problem] happened. Walk me through what you did.
+> Q2. What did that cost you - in time, money, or sanity?
+> Q3. What have you tried already to fix this?
+> Q4. On a scale of 1-10, how big a problem is this compared to everything else on your plate?
+> Q5. Who else on your team feels this? How do they handle it?
+
+For the ed-tech founder story that motivated this script, see the [lesson chapter](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/).
+
+Rob Fitzpatrick's book *The Mom Test* (2013) named the technique: ask about past behavior, not future intent. The questions on this page are the script. You keep them open on a second screen during the call, read them as written, and listen for emotional language while you take notes by hand.
+
+## How to use this
+
+Open this page on a second screen during the call. Read the questions as written - small wording changes ("would you" instead of "did you") flip the answer from past behavior back into polite hypothetical, which is the exact failure mode you are trying to avoid.
+
+Take notes by hand, not by typing. Hand-writing slows you down enough that you stop transcribing and start listening for the three emotional flags below. Score each call 1-10 at the end, using Q4 and the flag count together. By interview 10, you have a validation score, not 10 unsorted transcripts.
+
+Time budget: 25 minutes for the questions, 5 minutes for scoring notes. Total 30 minutes booked, 20 minutes of real talking. Do not go over. Run 60 minutes and you start pitching your idea in minute 35 and contaminate the sample.
+
+## The 5 questions - copy and paste
+
+### Q1 - The last-time question
+
+*Anchors in a real episode - story over preference.*
+
+> "Tell me about the last time [problem context] happened. Walk me through what you did."
+
+**Pass signal:** A specific story with a date, a time of day, a tool they opened, a person they messaged. "Last Tuesday at 9pm I spent 40 minutes copying numbers from three spreadsheets into a slide for the board. I called my CFO and she pulled the numbers from QuickBooks for me."
+
+**Fail signal:** Vague generality. "Yeah, I usually struggle with reporting." "It happens all the time." No date. No mechanic. The interviewee never opens an actual memory.
+
+**Follow-up:** "Walk me through that specific Tuesday again. What did you do first?"
+
+### Q2 - The cost question
+
+*Quantifies the pain - an unquantified problem won't get paid for.*
+
+> "What did that cost you - in time, money, or sanity?"
+
+**Pass signal:** A specific number with a unit. "Two hours every Tuesday night for the last six months." "My CFO bills $200/hour and she spent four hours on it last week." "I missed my daughter's bedtime three Mondays in a row."
+
+**Fail signal:** "It costs us time." "It's frustrating." "It's a lot." Unquantified. The interviewee is being polite about a problem they don't actually feel.
+
+**Follow-up:** "If you had to put a number on it - dollars, hours, or 'I'd quit my job over this' - what would the number be?"
+
+### Q3 - The workaround question
+
+*Surfaces existing workarounds - a non-tried problem is a non-felt problem.*
+
+> "What have you tried already to fix this?"
+
+**Pass signal:** A named tool, a hired person, a custom script, a workaround that took setup time. "I pay $79/month for Zapier to copy QuickBooks to Google Sheets. It breaks every two weeks. I have a VA on Upwork who fixes it."
+
+**Fail signal:** "Nothing yet." "We just deal with it." "I've been meaning to look into something." A non-tried problem is a non-felt problem. There are exceptions (regulated industries, security, etc.) but the default reading is: no workaround means no urgency.
+
+**Follow-up:** "What broke about the workaround? Why are you still talking to me about this?"
+
+### Q4 - The priority question
+
+*Calibrates urgency against the interviewee's whole problem stack - most "would be great if" problems land at 4.*
+
+> "On a scale of 1-10, how big a problem is this for you compared to everything else on your plate?"
+
+**Pass signal:** A 7 or higher with a comparison. "This is an 8. The only thing higher is hiring my next engineer." A 9 or 10 is rare and a strong signal.
+
+**Fail signal:** A 5 or 6 with a soft justification ("it's annoying but we cope"). A 7 or 8 with no comparison to anything else - that's the polite-default score, not real urgency.
+
+**Follow-up:** "What's at 10 right now? What would have to happen for this problem to climb to that 10 spot?"
+
+### Q5 - The buying-committee question
+
+*Surfaces the buying committee and workarounds other people on the team already own.*
+
+> "Who else on your team feels this? How do they handle it?"
+
+**Pass signal:** Names a specific colleague and their workaround. "My ops manager Jess feels this worse than I do - she keeps a separate Google Sheet that mirrors the one finance uses, because she doesn't trust the finance numbers."
+
+**Fail signal:** "I'm the only one who deals with this." "Everyone else is fine." Either the problem is local and small, or the interviewee doesn't know how their team operates. Both are weak signals.
+
+**Follow-up:** "Could you introduce me to Jess? I'd like to hear how she built that workaround."
+
+## The 3 emotional-language flags
+
+While you are reading the questions, listen for three patterns in their answers. These flags do more work than the words "yes" and "no."
+
+**Frustration language.** "I hate this." "It drives me crazy." "Every single week." "I can't believe we still do it this way." If the interviewee uses words with feeling, the problem is felt. Polite interviewees suppress feeling, which is exactly why you ignore polite answers.
+
+**Workaround language.** "I've been meaning to..." "We hacked together..." "I pay [tool] $X for this." "My VA does it manually." Workarounds prove the problem is real because the interviewee already spent time or money on a solution that doesn't fully work. The workaround is the budget you can pitch into.
+
+**Urgency language.** "Last week." "This morning." "I missed my kid's birthday because of this." A problem that happened today is felt more sharply than a problem that happens "sometimes." Time-anchored urgency is the strongest signal in the set.
+
+A passing call has 3+ flags across the five answers. A failing call has 0-1 flags - the interviewee is being polite to you. Two flags is ambiguous; treat as a 5/10 score.
+
+## What good looks like vs what bad looks like
+
+**Q1 - Bad answer:** "Yeah I usually struggle with reporting."
+
+**Q1 - Good answer:** "Last Tuesday at 9pm I spent 40 minutes copying numbers from three spreadsheets into a slide for the board. I called my CFO. She had QuickBooks open, pulled the numbers in 90 seconds. I felt stupid."
+
+The good answer has a date, a time, a tool, a person, a duration, and feeling. The bad answer is a polite generality. Same problem, same interviewee - the wording of the question and your willingness to wait for a real story is the difference.
+
+**Q4 - Bad answer:** "Probably a 7."
+
+**Q4 - Good answer:** "This is a 4. Hiring my next engineer is at 9, fundraising is at 8, payroll automation is at 5. Your thing would be useful but I am not going to pay to fix it this quarter."
+
+The good answer is honest and ranks the problem against real competitors for the interviewee's attention. It might sting. That sting is the data. A polite 7 with no comparison is the most common failure - the interviewee is being kind because you are a real person who showed up to ask.
+
+**Closing - Bad:** "So if I built this, would you pay $49/month?"
+
+**Closing - Good:** "Thank you. Two more questions: who else on your team should I talk to about this, and would you be willing to look at a 5-minute prototype in two weeks?" - then ask for the introduction and the calendar slot before you hang up.
+
+The bad closing pulls them back into hypothetical preference and gives you a useless "I'd consider it." The good closing converts the call into the next two assets: an introduction (Q5 working in production) and a commitment to look at a prototype (the asks-for-effort test from Fitzpatrick's book).
+
+## What to do after the call
+
+- **Score the call 1-10 within 5 minutes of hanging up.** Use Q4 plus your emotional-flag count. Write the score in your notes file. If you score later you will round up.
+- **If you have 7+ scores on 7 out of 10 interviews:** the problem is validated. Move to the Validated Problem Statement template (synthesis section of Chapter 2.1).
+- **If you have fewer than 5 scores of 7+:** the problem is too weak. Re-evaluate the ICP, the problem framing, or the question wording before booking another 10 calls. Sometimes Q1 is wrong (the problem context is too narrow) - retry with broader phrasing first.
+- **Forward the transcripts to your fractional CTO or independent advisor** before you make the build/no-build call. Two readers catch what one misses.
+
+Skip this script and run "feature interest" interviews ("would you pay for X?") and you almost always launch into silence. The Mom Test isn't a productivity trick. It is the only way to keep your interviewees from being polite while you are gambling six months of your life on what they said.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/cover.png b/content/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/cover.png
new file mode 100644
index 000000000..06719ed14
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/index.md b/content/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/index.md
new file mode 100644
index 000000000..df93986dd
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/index.md
@@ -0,0 +1,132 @@
+---
+title: "2.1b · Mom Test Synthesis: Build, Pivot, or Kill"
+aliases: ["/blog/mom-test-synthesis-build-pivot-kill/"]
+description: "After your 10 Mom Test interviews: score each transcript, count strong signals, and decide build, pivot, or kill. The 90-minute synthesis that turns raw transcripts into a validated problem statement."
+date: 2026-05-13
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: mom-test-synthesis-build-pivot-kill
+keywords:
+  - mom test synthesis
+  - score customer interviews
+  - build pivot kill decision
+  - validated problem statement
+  - founder interview analysis
+tags:
+  - founders
+  - non-technical-founder
+  - customer-research
+  - validation
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "2.1b · Mom Test Synthesis: Build, Pivot, or Kill"
+  og_description: "After your 10 Mom Test interviews: score each transcript, count strong signals, and decide build, pivot, or kill. The 90-minute synthesis."
+cover_image_alt: "Mom Test synthesis cover showing the build/pivot/kill decision tree after 10 interviews"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/"
+related_posts: false
+---
+
+> **Module 2 · After Step 1** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** 10 scored Mom Test transcripts (from [Ch 2.1](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/)) + completed interviews (from [Ch 2.3 (a + b)](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/))
+>
+> **Output:** a build / pivot / kill decision + a one-page validated problem statement
+
+> **TL;DR:** Score 10 transcripts, count strong signals, make one of three calls. 90 minutes. The decision you avoid here costs you a quarter of build time later.
+
+> **You should be here AFTER your Ch 2.3 (a + b) interviews are done.** If you don't have 10 scored transcripts in hand, return to [Ch 2.1](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) for the technique, then [Ch 2.3 (a + b)](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) for recruitment. This page is the synthesis pass - you cannot complete it without real interview data.
+
+After all 10 interviews are done, you have scored transcripts in a folder and a number. Synthesis is the 90-minute step that turns those transcripts into the one-page validated problem statement you'll carry into Module 3. Skip this step and go straight to Lovable, and you have not validated anything - you have a folder and a hypothesis.
+
+## The 3-step synthesis
+
+Synthesis runs on three moves. You don't need a framework. You need 90 minutes alone with the 10 transcripts, a printed template, and the willingness to write down a number that might be a 3.
+
+**Step 1 - Score each interview 1-10.** Open the transcripts in order. For each call, read your handwritten Q4 score and your emotional-flag count from the [Ch 2.1 script](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/). Combine the two into one number from 1 to 10. A score of 7+ means the interviewee gave you a 7 or higher on Q4 with a comparison (the polite-default 7 with no comparison rounds to 5) and at least 3 emotional-language flags across the five answers. A 4 to 6 means partial signal - a real story but a weak workaround, or a high Q4 score with zero frustration language. Below 4 means polite-yes mode: vague Q1 answers, "nothing yet" on Q3, a hedged Q4 number under 7.
+
+Write the number on the first page of each transcript within 5 minutes of hanging up. The score you write immediately is more honest than the one you'd write after a week of wanting the number to be higher.
+
+**Step 2 - Count the strong signals.** On a single sheet of paper, list the 10 scores in a column. Circle every score that is 7 or higher. That circled count is your strong-signal number.
+
+The pattern matters more than the average. Eight 7+ scores and two 3s is a strong signal - you found a problem two ICPs share. Five 7+ scores and five 5s is muddled - the ICP definition is too broad. Three 9s and seven 4s is the dangerous one: you talked to your three best friends in the industry and they validated the idea while seven strangers told you the truth.
+
+**Step 3 - Write the one page.** Open the [Validated Problem Statement Template](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/) on a second screen. Fill it in within 30 minutes. Five sections, no exceptions: who has the problem (named persona, named industry, strong-signal count); what it costs them (time, money, and one specific quote from a real transcript - avoid "frustrating" and "time-consuming"); what they've tried (named workarounds and why each failed - these are your real competitors); why now (the trigger event or market shift that makes this solvable in 2026); how big is the pain (average score plus strong-signal count - print both, not just the average). A single side of paper. If you spill onto a second page, the persona is too broad or the pain is too vague.
+
+## The decision: build / pivot / kill
+
+Your strong-signal count from Step 2 routes you to one of three outcomes.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    Start(["10 Mom Test transcripts.
90 minutes alone, pen + printed template."])
+    Start --> S1[Step 1
Score each interview 1-10]
+    S1 --> S2[Step 2
Count strong signals 7+]
+    S2 --> S3[Step 3
Write the one page]
+    S3 --> S4{Strong signals
in 10 calls?}
+    S4 -->|7 or more| Build[BUILD
Move to Chapter 3.1
Write the Product Brief]
+    S4 -->|4 to 6| Pivot[PIVOT
Run 5 more interviews
Refine the ICP first]
+    S4 -->|Fewer than 4| Kill[KILL
Find a different problem
Restart at Ch 2.3a]
+    Build --> Sign[Show to 2 advisors.
Get 2 signatures before building.]
+    Pivot --> Sign
+    Kill --> Sign
+
+    classDef start fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a
+    classDef step fill:#fff5f5,stroke:#cc342d,stroke-width:2px,color:#1a1a1a
+    classDef decision fill:#faf5ff,stroke:#a855f7,stroke-width:2px,color:#1a1a1a
+    classDef build fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef pivot fill:#fffbe6,stroke:#bf8a00,stroke-width:2.5px,color:#1a1a1a
+    classDef kill fill:#ffebee,stroke:#c62828,stroke-width:2.5px,color:#1a1a1a
+    classDef sign fill:#f5f5f5,stroke:#555,stroke-width:2px,color:#1a1a1a
+
+    class Start start
+    class S1,S2,S3 step
+    class S4 decision
+    class Build build
+    class Pivot pivot
+    class Kill kill
+    class Sign sign
+```
+
+**7+ strong signals: build.** You have a problem that 70%+ of a stranger sample confirmed with felt urgency. The validated problem statement is your input to [The One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/).
+
+Before you start writing code, run the 3 pre-orders test: ask 3 of your strongest-signal interviewees for a pre-order, a paid letter of intent, or a deposit. Strangers who told you their problem score is a 9 should be willing to put a small commitment behind it. If 3 of your top 5 say yes, you have validation with money attached - the strongest signal there is. If 0 of 5 say yes, the 7+ scores were politer than you thought.
+
+**4-6 strong signals: pivot.** The signal is partial. Most often this is an ICP problem, not a problem problem. Pick the cleanest segment, sharpen the ICP definition, run 5 more interviews against that narrower group. Don't build yet. The 5 sharper interviews cost you a week. A built MVP against a fuzzy ICP costs you a quarter.
+
+**Below 4 strong signals: kill.** Strangers were polite. The market said no in the only way the market knows how to say no before a launch: by not feeling the pain enough to put a number on it. Write down what you learned about the wrong ICP, the wrong framing, or the wrong trigger event. Start [Find 10 People With the Problem](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) again with a different hypothesis.
+
+## What good looks like vs what bad looks like
+
+**Bad problem statement (vague, unfilled):**
+> Founders need a better way to validate their startup ideas. Many of them waste time and money.
+
+**Good problem statement (specific, named, signed):**
+> Pre-seed B2B SaaS founders running their own discovery do customer interviews, but 9 of 10 (per our 10-call sample, Apr-May 2026) use hypothetical-future questions and get polite-yes answers. The average interviewee currently spends 6-12 hours running interviews and learns the problem wasn't real only after their first launch flops - typical sunk cost is 6 weeks of build time plus $15K-$30K of contractor spend. Workarounds tried: YC Library essays (too high-level), $1,500 SurveyMonkey panel (taught one founder I spoke with nothing in the survey style), free templates downloaded but not used. Why now: AI-built MVPs accelerated this failure mode - the prototype lands in 4 days instead of 12 weeks, so the validation gap surfaces faster. Pain average 7.6/10 across 10 calls, 8 strong signals.
+
+The good answer has named industry, dated sample, named workarounds with named failure modes, a quantified cost, a why-now, and a strong-signal count. A peer can argue with it. If your statement has the word "many" or "a lot," cross it out.
+
+The [Validated Problem Statement Template](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/) is the artifact for this section. Print it, fill it in 30 minutes, get 2 signatures, and the problem validation checkpoint is closed.
+
+Writing the one-page statement is the validation step. Ten transcripts in a folder don't count - until you've scored them, counted the strong signals, and written down what the pattern says, you have raw material and a hypothesis, not a validated problem.
+
+---
+
+> **Done when:** You have a build / pivot / kill decision backed by your strong-signal count, and a one-page validated problem statement.
+> **Next click:** If build - [2.4 · Build a Clickable Prototype](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/) to test the shape with 5 of your strongest-signal interviewees, then [3.1 · The One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/). If pivot - return to [2.3a · Find 10 People: Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) to rebuild your list around a sharper hypothesis (same hypothesis, different list). If kill - the hypothesis is wrong, not the list; return to [1.1 · Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) and rewrite the weakest blank using verbatim quotes from your dead transcripts, then re-run 2.3a.
+> **If blocked:** If the numbers aren't adding up, re-read [Ch 2.1's scoring rubric](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) - the Q4 score and flag-count combination is what separates a 7 from a 5.
+
+---
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas** (ReconcileBot, B2B SaaS): scored 7 of 10 controllers at 8/10 or higher. Strong-signal count = 7. Verdict: BUILD. Writes the validated problem statement using a verbatim quote ("CFO billed $800 last week on a 4-hour reconciliation") and moves to 2.4 prototype.
+>
+> **Mia** (TutorMatch, B2C marketplace): scored 8 of 10 parents at 9/10 or higher. Strong-signal count = 8. Verdict: BUILD. Validated problem statement anchors on a verbatim quote ("missed a $2,000 project deadline on hold with a tutoring center") and moves to 2.4 prototype.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/cover.png b/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/cover.png
new file mode 100644
index 000000000..a5d1b0d2e
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/index.md b/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/index.md
new file mode 100644
index 000000000..f75b46ea7
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/index.md
@@ -0,0 +1,229 @@
+---
+title: "5.1 · Your First Customer Is Not a Marketing Problem"
+aliases: ["/blog/must-have-segment-pmf-test/"]
+description: "Before spending a dollar on ads, run the Sean Ellis 40% test against your earliest users. The non-technical founder's pre-paid-traffic gut check."
+date: 2026-05-13
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: must-have-segment-pmf-test
+keywords:
+  - sean ellis 40 percent test
+  - product market fit survey non technical founder
+  - must have user persona
+  - pre paid ads validation
+  - first paying customer founder course
+tags:
+  - founders
+  - non-technical-founder
+  - first-paying-customer
+  - sales
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "5.1 · Your First Customer Is Not a Marketing Problem"
+  og_description: "Before spending a dollar on ads, run the Sean Ellis 40% test against your earliest users. The non-technical founder's pre-paid-traffic gut check."
+cover_image_alt: "JetThoughts blog cover showing a Sean Ellis 40% gauge with a red threshold line separating product problem from must-have user"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/"
+related_posts: false
+---
+
+> **Module 5 · Step 1 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a live MVP + 10-30 users who touched it. **Don't have 10-30 yet?** Invite your Module 2 Mom Test interviewees + your [1.2b smoke-test email list](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) (typically 15-50 signups) to your staging URL as the warm seed. If under 10 users still touched it, run [Ch 2.3b outreach](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) for 10 more before re-attempting this survey.
+>
+> **Output:** a written must-have-user persona with 3 verbatim quotes and one named segment to target
+
+> **TL;DR:** Before spending a dollar on ads, survey your earliest users. If fewer than 40% would be "very disappointed" if your product vanished, you have a product problem, not a marketing problem.
+
+Your Lovable MVP went live last month. Forty people from your beta list poked at it. The dashboard says 0.4% conversion on $4,200 of Meta ads, and the instinct says "scale the top of funnel."
+
+The dashboard will tell you the same thing it would have told you if you had called five of those forty users first: most never opened the app twice. The $4,200 bought you a number you could have gotten for free.
+
+The real question after the MVP ships is whether the people who already touched it would notice if it vanished tomorrow. If less than 40% would be very disappointed, no amount of ad spend will turn that group into customers. Paid traffic does not fix a product problem; it routes more users into something they will not return to.
+
+> **What your first-pass numbers will probably look like (and that is not a failure signal).** An idea-stage founder with 4-6 onramp users typically sees one of three patterns on the first survey run:
+> - All "somewhat disappointed" or "not disappointed" → directional KILL. Run more interviews before re-attempting.
+> - 2-3 "very disappointed" out of 6 → directional MAYBE. Almost certainly a sample-size problem, not a product problem; book 5-10 more users.
+> - 4+ "very disappointed" out of 6 → directional YES. Advance to M5.2 with the caveat above.
+>
+> A 25-40% reading at small sample size is not a failure. It is the normal state of a brand-new product with a brand-new founder. The Sean Ellis test is calibrated for ≥ 20 respondents with months of usage; your first-pass run is a forecast, not a verdict. Treat looping back to M2.3 outreach for more user sessions as the default first-pass move, not a setback.
+
+## The 40% test, in one paragraph
+
+Sean Ellis ran growth at Dropbox, LogMeIn, and Eventbrite. While he was building the playbook for those three, he kept noticing the same dividing line between products that ignited and products that needed life support. He surveyed every product's existing users with a single load-bearing question: "How would you feel if you could no longer use [product]?" The answer is one of four: very disappointed, somewhat disappointed, not disappointed, no longer use it. If at least 40% of users said "very disappointed," the product was almost always able to grow on outbound and word of mouth alone. Under 40%, growth stalled until the product changed. Ellis explained the cutoff and the survey wording on Lenny Rachitsky's podcast in 2023 ([transcript and replay here](https://www.lennysnewsletter.com/p/the-sean-ellis-test-for-product-market)).
+
+![Sean Ellis 40% gauge - the threshold that decides whether paid ads will work or burn](sean-ellis-gauge.svg)
+
+## Why you, the non-technical founder, get this wrong
+
+You just shipped your first Lovable MVP and 40 people from your beta list poked at it. The natural urge is to start collecting traction numbers immediately - surveys feel like a delay, ads feel like progress. And because you cannot read the codebase, "the conversion rate is 0.4%" sounds like a UX problem (a thing you can act on) instead of a product problem (a thing you cannot diagnose). Ad spend feels safer than going back into the build.
+
+The Twitter threads make it worse. On day 90 after launch, every thread is some growth marketer explaining that the founder of a now-public company spent $4M on Meta in the first six months. The threads do not mention that the founder ran the 40% test in week one and got 56% on a sample of 22.
+
+Ask yourself the must-have rate before you ask anything else. The pattern across the burned-thousands-on-paid-ads stories is the same: a number that was never measured. Sometimes the rate is under 25% overall - genuine "no must-have user" territory. Sometimes one segment scores high and another scores low, but the ad targets the wrong half because the high-need segment is harder to reach. Knowing the number before the ad spend is the difference between an expensive lesson and a cheap one.
+
+## How to run the test, end to end
+
+The KISS path is a free Typeform or Tally form and a CSV export. No Rails webhook, no Postgres table, no engineer.
+
+### Step 1 - Who you survey
+
+You need enough responses from people who have used your product recently to spot a segment pattern; a few dozen is the floor. Pull the list from whatever you have:
+
+- The MVP database (sign-up table). For a Lovable, Bubble, or Supabase build, export `users` as CSV.
+- Your beta waitlist if it converted to active users.
+- The trial list if you ran paid trials.
+
+If you only have ten users, that is fine. Sean Ellis has written that even ten responses are directional. Ten of ten "very disappointed" is a louder signal than 40 of 100. You are not running a peer-reviewed study; you are looking for a dividing line.
+
+Strip out two groups before you send:
+
+- Anyone who signed up and never logged in twice. They never used the product, so the question is unanswerable.
+- Friends and family who you onboarded as moral support. They will all say very disappointed and tell you nothing.
+
+What is left is your sample. Annotate each row with the user's job title and company size before you send, so the CSV export later can be sliced by segment in one filter.
+
+### Step 2 - The 5 questions, verbatim
+
+
+Open Typeform or Tally. Five questions, in this order. Wording matters - changing a word changes the answer.
+
+> **Q1.** How would you feel if you could no longer use [product]?
+> *(Multiple choice: Very disappointed / Somewhat disappointed / Not disappointed / No longer use [product])*
+>
+> **Q2.** What type of person do you think would most benefit from [product]?
+> *(Short text - 1 sentence. Reveals who the must-have segment thinks the target is.)*
+>
+> **Q3.** What is the main benefit you get from [product]?
+> *(Short text - 1 sentence. The verbatim language for your next ad copy if you do run paid later.)*
+>
+> **Q4.** How have you tried to solve this problem before? What did you switch from?
+> *(Short text - 2 sentences. Tells you the competitive set the user actually compares against.)*
+>
+> **Q5.** What is your job title and company size?
+> *(Two short text fields. Drives the segment slice in step 4.)*
+
+That is the survey. Do not add a sixth question. Do not change Q1 to "How disappointed would you be" - the original wording forces the user to pick a side. Tinker with the question and you consistently report softer numbers because you introduced a hedge.
+
+### Step 3 - Send it
+
+Email subject line that works in 2026: *"Quick 90-second question about [product]"*. Body, three lines:
+
+> Hi [first name], building [product] and trying to figure out who really uses it. Would you spend 90 seconds on this? [link]
+>
+> No pitch. No follow-up. I read every response by hand.
+>
+> Thanks, [your name]
+
+Send the first batch to your largest user cluster. Re-send a few days later to anyone who has not opened. You will hit a 30-50% response rate on a list under 100, which is enough.
+
+### Step 4 - Score it
+
+Export the CSV. Pivot on Q1 by segment from Q5. You are computing one number per segment:
+
+```
+must_have_pct = ("Very disappointed" count) / (total responses excluding "No longer use it")
+```
+
+The "no longer use it" answers come out of the denominator. They are churned users, not should-be-paying users.
+
+Pull three numbers:
+
+1. **Overall must-have %.** The headline figure.
+2. **Per-segment must-have %.** Slice by job title and by company size. One segment will almost always be higher than the average. That is your must-have segment.
+3. **Three verbatim Q2-Q3 quotes from your must-have segment.** Paste them into a Google Doc. Those quotes are your persona description, your ad copy, and your cold-email subject line for the next chapter.
+
+![Segment isolation Venn - what an average hides and what one slice reveals](segment-isolation.svg)
+
+### Step 5 - The decision tree
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    A[Run the 5-question survey] --> B{Overall must-have %}
+    B -->|Under 25%| C[Stop. Product problem.
Talk to 5 'very disappointed' users.
Find what you missed.]
+    B -->|25-40%| D{Any segment over 40%?}
+    B -->|Over 40%| E[You have a must-have user.
Chapter 5.2 outreach starts here.]
+    D -->|Yes| F[Target that segment.
Rebuild the persona on those quotes.]
+    D -->|No| G[Refine the product first.
Re-run after the next release.]
+    classDef redbox fill:#fff5f5,stroke:#cc342d,stroke-width:2px;
+    classDef purplebox fill:#fbe9ff,stroke:#a855f7,stroke-width:2px;
+    class C,G redbox;
+    class E,F purplebox;
+```
+
+> *Re-run cadence: re-run while the must-have rate is climbing and after every major release once it holds above 40% for two consecutive runs. If a re-run drops, read the "somewhat disappointed" Q2-Q4 verbatims first - the diagnostic is in there.*
+
+> **Sample-size honesty.** The Sean Ellis 40% threshold is statistically directional at **≥ 10 respondents**, useful at **20+**, and segment-sliceable at **30+**. Under 10 respondents your result is a hypothesis, not a verdict. If you have 6 users say "very disappointed" and 4 say "somewhat disappointed", the 40% threshold says PASS - but with a ±40 percentage-point confidence band around that number, you do not know whether real demand is 20% or 80%. Treat any reading under 10 respondents as **directional only**: use it to prioritize the next outreach batch, not to advance into Module 5.3 with confidence.
+
+> **Sample under 10 respondents (special case):** segment-slice math does not work. Do NOT classify by 25-40% bands. Instead:
+> - **0-2 "very disappointed"**: treat as directional NO. Book more user sessions before re-running.
+> - **3-4 "very disappointed"**: directional MAYBE. Book 5-10 more users, re-run.
+> - **5+ "very disappointed" out of 6**: directional STRONG YES. Advance to M5.2 but caveat your channel decisions - the segment language is hypothesis, not verified.
+
+## What "under 40%" actually means
+
+Under 40% means you have a product problem, not a marketing problem, and the Q2-Q4 verbatims tell you which one.
+
+| Pattern | Diagnostic | Fix | Re-entry point |
+|---|---|---|---|
+| **You built for the wrong segment** | The product works, but the people you onboarded do not have the pain. Your Q5 slice shows: one segment is at 55%, the rest are at 5%. | Stop selling to the audience and start selling to the segment. | [Chapter 5.2](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/) personal-network outreach to the right segment. |
+| **You built the right thing, but it is not finished** | The Q3 verbatims are hedged ("it is nice to have," "I would use it if it had X"). The main benefit answers lack conviction. | Go back into the build and finish the thing. | Schedule a [Friday demo](/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/) with the next release. |
+| **The pain is real, but your product is not the relief** | The Q4 verbatims name a workaround that is already 80% of the job (a spreadsheet, an existing tool, a person they pay). | Either niche into the 20% the workaround does not cover, or pivot. | [Chapter 2.1](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/#synthesis-write-down-what-you-heard-decide-whats-next) validated-problem statement. |
+| **The product solves the pain, but the workflow is too long** | Users say "very disappointed" but session logs show they bailed before the payoff. Funnel collapses between signup and the "30-minute save" moment. | UX cut, not a strategy pivot. Shorten the path to the first win. | Retest after shortening the funnel; re-run the 40% test after the next UX release. |
+
+## When founders should skip the test
+
+| Condition | What to do instead |
+|---|---|
+| **Under 10 users** | Run [Chapter 2.3b outreach](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) (with the list-building method from [2.3a](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) if you don't already have a 30-name list) and book 10 more user calls before re-attempting the test. The test requires 10-30 users who actually touched the MVP to be meaningful. |
+| **Pre-launch** | Use the [Mom Test interview script](/course/tech-for-non-technical-founders-2026/mom-test-interview-script/) instead. The 40% test asks "if you could no longer use the product" - if the user never used it, the answer is meaningless. |
+
+## Advanced (optional)
+
+> **Layering on segment isolation for 100+ users:**
+> After you run the 40% test once and close your first paid pilot,
+> read Sean Ellis's original [*Hacking Growth*](https://hackinggrowth.org/)
+> and the [Superhuman PMF Engine](https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit/).
+> Both combine the 40% test with structured segment-isolation workflows.
+> The main path above is enough for the Module 5 decision;
+> the advanced version becomes relevant after your first 10 customers ship.
+
+## What to do next
+
+| Step | Action | Output |
+|---|---|---|
+| **1** | Export your users CSV. Strip the friends-and-family and the never-returned users. Open Typeform or Tally. Type the five questions verbatim. | Typeform/Tally survey ready to send |
+| **2** | Send the email to the list. Subject: *"Quick 90-second question about [product]"*. Re-send a few days later to non-openers. | 30-50% response rate expected |
+| **3** | Export the responses CSV. Compute overall must-have % and per-segment must-have % (by job title and company size). | One-page scorekeeping: headline %, top segment %, three verbatim quotes |
+| **4** | Paste three Q2-Q3 verbatims from your top segment into a Google Doc. Review which segment hit 40%+ (or if none did). | Persona writeup ready for Chapter 5.2 or decision on pivot |
+| **5** | If above 40% in any segment, move to [Chapter 5.2 personal-network outreach](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/). If below 40% across all segments, book five "very disappointed" user calls and re-read [Chapter 2.1 Mom Test](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/). | Decision made; next chapter unlocked OR product refinement scheduled |
+
+The full survey template (the 5 questions in a Typeform-import-ready format, the per-segment scoring spreadsheet, and the persona-writeup template) ships in [the First-Paying-Customer Operating Kit](/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/).
+
+Treat the answer as a stop sign rather than a market-research instrument. Under 40% means the next thing on your calendar should be five user calls, not a Meta Ads brief.
+
+## Further reading
+
+- Lenny Rachitsky, [The Sean Ellis test for product/market fit](https://www.lennysnewsletter.com/p/the-sean-ellis-test-for-product-market) - the original 40% framing, with Sean's own commentary on what the number means and does not mean.
+- Sean Ellis and Morgan Brown, [*Hacking Growth*](https://hackinggrowth.org/) - the book that explains the survey-driven north-star approach Ellis built at Dropbox, LogMeIn, and Eventbrite.
+- Lenny Rachitsky, [How to win your first 10 B2B customers](https://www.lennysnewsletter.com/p/how-to-win-your-first-10-b2b-customers) - companion piece that maps the must-have-user concept to the first-ten-customer playbook.
+- Steve Blank, [The Customer Development Manifesto](https://steveblank.com/2010/01/25/the-customer-development-manifesto-reasons-for-the-revolution-part-1/) - the foundational framing for "get out of the building and validate before building." The Sean Ellis test is the post-build analog.
+- Rahul Vohra, [How Superhuman built an engine to find product-market fit](https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit/) - the segment-isolation playbook layered on top of the 40% test.
+- Rob Fitzpatrick, [*The Mom Test*](https://www.momtestbook.com/) - the pre-launch validation companion. Once your 40% test is above the line, the Mom Test questions are the ones you ask the 10 must-have users on their next call.
+
+> **Done when:** You have run the 5-question Sean Ellis survey, computed the overall and per-segment must-have %, and have 3 verbatim Q2-Q3 quotes from your top segment.
+> **Next click:** [5.2 · Choose Your Channel Before You Send One Message](/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/)
+> **If blocked:** If under 10 users responded, your sample is too small to read. Book 5-10 more user sessions using the Ch 2.3 (a + b) outreach playbook and re-run the survey.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Runs the Sean Ellis survey on his 24 smoke-test signups. Segments by firm size: 50-150 employee firms score 45% "very disappointed" without it. 150-200 employee firms score 28% - they have in-house tools. Narrows to 50-150 employee firms.
+>
+> **Mia**: Runs the Sean Ellis survey on her 21 smoke-test signups. Segments by child age: parents of kids 8-14 with dyslexia score 52% "very disappointed." Parents of kids 14+ score 31% - they've found workarounds. Narrows to parents of kids 8-14 with dyslexia/ADHD.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/sean-ellis-gauge.svg b/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/sean-ellis-gauge.svg
new file mode 100644
index 000000000..5b45e37bc
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/sean-ellis-gauge.svg
@@ -0,0 +1,59 @@
+
+  The Sean Ellis 40% threshold: where founder paid-ads instinct fails and where it does not
+  
+    
+    
+      
+    
+  
+
+  "Very disappointed if this disappeared tomorrow"
+  Sean Ellis 40% test - survey your first 10-30 users before spending a dollar on ads
+
+  
+  
+  0%
+  25%
+  40%
+  60%
+  100%
+
+  
+  
+  40% line
+
+  
+  
+  UNDER 40%
+  Product problem.
+  More ads will not fix this.
+  Talk to your "very disappointed" users.
+
+  
+  
+  40% OR HIGHER
+  You have a must-have user.
+  Now find more of them.
+  Outreach beats paid ads at this stage.
+
+  
+  If you ran ads first:
+  
+  you would burn $3K-$5K
+  finding out the same thing.
+
+  
+  
+  5 questions. 24-48 hour run. Free Typeform or Tally.
+  Re-run every 6 weeks until the must-have % stops climbing or holds steady above 40%.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/segment-isolation.svg b/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/segment-isolation.svg
new file mode 100644
index 000000000..165ea0b78
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/segment-isolation.svg
@@ -0,0 +1,45 @@
+
+  Segment isolation: the must-have % hidden inside an average
+  
+    
+  
+
+  Average 28% looks like failure.
+  Slice by segment and one bucket is 64%.
+  Same 28 responses. Different conclusion. The 64% segment is who you ship to next.
+
+  
+  
+  B2B Marketers
+  64% must-have
+  9 of 14 said "very disappointed"
+  Use it daily. Already replaced a tool.
+
+  
+  
+  Solo Founders
+  14% must-have
+  1 of 7 said "very disappointed"
+  Tried it once. Forgot it existed.
+
+  
+  
+  Agencies
+  0% must-have
+  0 of 7. Already have an internal tool.
+
+  
+  Now you know:
+  → Target B2B marketers next.
+  → Stop chasing solo founders for now.
+  → Agencies were never your buyer.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/cover.png b/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/cover.png
new file mode 100644
index 000000000..384d31758
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/good-vs-bad-prd.svg b/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/good-vs-bad-prd.svg
new file mode 100644
index 000000000..fbeb0c7fd
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/good-vs-bad-prd.svg
@@ -0,0 +1,90 @@
+
+  Bad Vibe PRD vs Good Vibe PRD - side-by-side comparison of a vague brief and a specific one.
+  A side-by-side comparison. Left card is the bad Vibe PRD: a single line saying "Build a CRM" with no persona, no context, no metric, no no-go list. Right card is the good Vibe PRD with the five sections filled in - named persona, 60-second user context, one paragraph of build scope, one success metric, a no-go list of five items.
+  
+    
+  
+
+  
+
+  
+  Vibe PRD - Bad vs Good
+
+  
+  
+
+  
+  BAD
+
+  "Build a CRM"
+
+  1. The problem
+  (blank)
+
+  2. The user + context
+  "Founders need a better way to
+  manage customer relationships."
+
+  3. What you're building
+  "A modern CRM with great UX,
+  integrations, and AI features."
+
+  4. Success metric
+  "Lots of happy users."
+
+  5. What you're NOT building
+  (blank)
+
+  Result: Lovable builds a settings
+  page, 17 toggles, and a dashboard.
+  Nothing the persona actually does.
+  Quarter wasted on the wrong demo.
+
+  
+  
+
+  
+  GOOD
+
+  Stripe - QuickBooks reconciler
+
+  1. The problem
+  Pre-seed SaaS founders, 6 hrs/week
+  on Stripe - QB reconciliation.
+  8/10 confirmed, May 2026 sample.
+
+  2. The user + context
+  Founder, 9pm Tuesday, browser,
+  Stripe + QB tabs open. Wants to
+  be done in 10 min, not 40.
+
+  3. What you're building
+  Paste Stripe payout CSV. Get
+  QB journal CSV back. USD only.
+  Magic-link auth. No CSV stored.
+
+  4. Success metric
+  10 of first 20 signups convert
+  1+ file in 30 days. Event:
+  conversion_completed.
+
+  5. What you're NOT building
+  Multi-currency - multi-Stripe -
+  auto-sync - settings page - roles
+  - mobile beyond 1024px - marketing
+  site beyond signup.
+  Result: 4-day ship. Real test in 30 days.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/index.md b/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/index.md
new file mode 100644
index 000000000..d5899019b
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/index.md
@@ -0,0 +1,199 @@
+---
+title: "3.1 · The One-Page Product Brief (Vibe PRD)"
+aliases: ["/blog/one-page-product-brief-vibe-prd/"]
+description: "The five sections your Lovable prompt or hired junior actually needs. Free Chapter 3.1 of the From Idea to First Paying Customer course."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: one-page-product-brief-vibe-prd
+keywords:
+  - vibe prd template founder
+  - one page product brief
+  - non technical founder prd
+  - ai product spec lovable
+  - founder vibe coding spec
+tags:
+  - founders
+  - non-technical-founder
+  - course-companion
+  - product
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "3.1 · The One-Page Product Brief (Vibe PRD)"
+  og_description: "The five sections your Lovable prompt or hired junior actually needs. Free Chapter 3.1 of the From Idea to First Paying Customer course."
+cover_image_alt: "JetThoughts cover showing a one-page product brief on a notebook with five labeled sections and a side-by-side bad vs good example"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/"
+related_posts: false
+---
+
+> **Module 3 · Step 1 of 2** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a one-page validated problem statement (from [Ch 2.1b · Mom Test Synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/), after running interviews in Ch 2.3a + 2.3b) + verbatim "describe in one sentence" vocabulary (from your [Ch 2.4 prototype sessions](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/) - Section 3 of the brief uses these exact words)
+>
+> **Output:** a one-page Product Brief (Vibe PRD) you can hand to Lovable or a hired team
+
+> **TL;DR:** One page, five sections. The problem (verbatim from interviews), the user's 60-second context, the one workflow, the one metric, and what you're NOT building. Hand it to Lovable or a contractor tomorrow morning.
+
+Sarah, an EdTech founder we audited in Q2 2026, had 17 settings toggles in her admin UI. In a one-day spec review we found 12 had no backend code and 2 crashed on toggle. The Vibe PRD she wrote next listed 5 settings she actually needed. Everything else came out. That is what a one-page brief does to a build that has drifted - it forces every line to earn its place tomorrow morning.
+
+This chapter walks you through the **Product Brief** - some founders call it a **Vibe PRD** (PRD stands for Product Requirements Document). It is a single page that names the user, the problem, the one workflow you are building, the one metric you will measure, and what you are explicitly NOT building. The five sections below are the same ones Drew Falkman teaches in a 4-week Maven cohort for $1,000; this chapter walks you through the template so you can fill yours in tonight.
+
+![One-page Vibe PRD template with five labeled sections: the problem, the user and their context, what you're building, success metric, what you're NOT building.](vibe-prd-template-visual.svg)
+
+## Who reads it: an AI agent or a hired junior, not a 6-person team
+
+| Audience | Read count | Iteration shape | Cost of a bad brief |
+|---|---|---|---|
+| **Traditional PRD** (6-person team) | 6 people read it + 1 kickoff call + refinement rounds | Long iteration loop, multiple reviewers | Team builds the wrong thing slowly; you learn in sprints |
+| **Vibe PRD** (AI agent or junior) | 1 read, then building starts | Short iteration loop, one builder | Lovable ships you a wrong thing on Wednesday, and you spend the quarter discovering why it's hard to evolve |
+
+[Veracode's 2025 GenAI report](https://www.veracode.com/blog/genai-code-security-report/) found 45% of AI-generated code ships with at least one exploitable security flaw. The brief is your only chance to constrain what the agent or the junior builds for you, and what they skip.
+
+## The 5-section template
+
+The Vibe PRD is one side of paper. Five sections, in this order. Each section is written so an AI agent or a junior contractor can act on it without a follow-up Slack thread.
+
+The simplest reliable order is *problem → user → build → metric → no-go*. Every section has a job. Skip one and your prompt or your contractor fills it in for you, usually wrong.
+
+> **How long is each section?** Each of the 5 sections is 2-4 sentences in plain English. Section 5 (no-go list) is 5-8 bullet lines. Total brief ≤ 250 words on one side of A4 at 11pt. If you spill past 250 words, the persona is too broad or the pain is too vague - revise the section that ran longest first.
+
+### Section 1 - The problem (lifted from Chapter 2.1 synthesis)
+
+What goes in it: one paragraph copied directly from your [validated problem statement](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/#synthesis-write-down-what-you-heard-decide-whats-next). Named persona, named industry, dated 10-call sample, one verbatim quote, one quantified cost.
+
+Example: *Pre-seed B2B SaaS founders doing their own Stripe-to-QuickBooks reconciliation lose 6 hours per week and $800 per month in CFO contractor time. 8 of 10 interviewees confirmed (May 2026 sample). One founder said: "Tuesday at 9pm I spent 40 minutes copying Stripe payouts into QuickBooks. I called my CFO. She did it in 90 seconds."*
+
+Common mistake: rewriting the problem in your own voice for the brief because "this is a different document." The brief inherits the problem statement word-for-word. If you find yourself softening the language, you are about to brief a build for a problem you haven't actually validated.
+
+### Section 2 - The user and their context
+
+What goes in it: who the user is *while* they're using your product. Not the persona's life story. The 60 seconds before they reach for your thing and the 60 seconds after.
+
+Example: *A pre-seed founder, alone in their browser at 9pm on a Tuesday, finishing the week's bookkeeping. They have a Stripe dashboard open in one tab and a QuickBooks ledger in another. They are tired, mildly annoyed, looking for a way to finish in 10 minutes instead of 40. They will open our app from a bookmark, paste one Stripe export, and close the tab when the numbers line up.*
+
+Common mistake: writing the persona's company size, ARR (annual recurring revenue), and tech stack as if pitching to investors. The agent or contractor doesn't need their TAM (Total Addressable Market - how big the whole market is in dollars; investor-pitch math, not builder math). They need to know the user is tired, has two tabs open, and wants to be done. Specific context produces a usable interface; abstract persona data produces a dashboard with seventeen filters nobody uses.
+
+### Section 3 - What you're building (one paragraph, plain English)
+
+What goes in it: one paragraph that names the smallest end-to-end thing a user can do. Verb-led. Mentions the inputs the user provides and the output they get back. No feature list, no tech stack instructions, no mention of microservices or auth strategies.
+
+Example: *A web app where the founder pastes a Stripe payout CSV and the app returns a QuickBooks-compatible journal entry CSV they can import in one click. The first version supports USD only, one Stripe account per user, and no multi-currency. The user authenticates with email + magic link. We never store the CSV after the conversion completes.*
+
+Common mistake: writing this in feature-list form ("Stripe integration · QuickBooks export · user dashboard · settings page"). The agent reads the feature list and produces a settings page nobody asked for and an integration that breaks in the first edge case. One paragraph forces you to name the thing the user *does*, not the menu items the engineer might build.
+
+### Section 4 - Success metric (one)
+
+What goes in it: one number, with a unit, that tells you whether the build worked. Measurable inside the app, not from your gut. Named timeframe.
+
+Example: *Of the first 20 users who land on the app, 10 successfully convert at least one Stripe export to a QuickBooks journal entry within 30 days of signup. Below that, the persona is wrong or the workflow is wrong. The metric is the conversion-completed event in our analytics, not signups.*
+
+Common mistake: listing three metrics (signups, retention, NPS) instead of one. Three metrics let you cherry-pick whichever one looks best. One metric forces a build/no-build decision in 30 days. The [pre-PMF founder rule](/blog/sales-pre-pmf-should-be-done-by-founders/) applies: one number, measured by you, defended in front of one advisor.
+
+### Section 5 - What you're NOT building (the no-go list)
+
+What goes in it: 5 to 8 lines naming the things a competent agent or contractor might add unprompted, that you explicitly do not want in v1. The longer this list, the cheaper your build.
+
+Example: *Not in v1: multi-currency support, multi-Stripe-account support, automatic recurring sync, a settings page, a billing dashboard, user roles and permissions, a marketing site beyond the signup page, mobile responsive design beyond "works on a 1024px screen." We will revisit each of these after metric in Section 4 is hit.*
+
+Common mistake: leaving this section blank because "we'll just say what we want and skip what we don't." Lovable, [Cursor](https://cursor.com), and a hired junior all fill blanks with reasonable defaults, and reasonable defaults stack into a settings page nobody asked for. The same shape produced Sarah's 17 toggles (12 wired to nothing) at the top of this chapter.
+
+![Side by side bad vs good Vibe PRD. Left: bad brief reads 'Build a CRM.' Right: good brief names the persona, the 60-second context, the one workflow, the one metric, and the no-go list.](good-vs-bad-prd.svg)
+
+## The 2 forks: Vibe PRD vs traditional PRD
+
+Not every brief is a Vibe PRD. The audience tells you which to write.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    Start(["One-page Product Brief written.
Where does it go next?"])
+    Start --> Q1{Who reads it
and builds from it?}
+    Q1 -->|Lovable / Cursor / AI agent| Vibe1[Vibe PRD
Hand the page as-is.
Paste into prompt.]
+    Q1 -->|Hired junior contractor| Vibe2[Vibe PRD
Hand the page +
short kickoff call.]
+    Q1 -->|Hired senior engineer| Trad1[Traditional PRD
Expand to 3-5 pages.
Add API + data model.]
+    Q1 -->|Product committee / board| Trad2[Traditional PRD
Expand to 5-10 pages.
Add roadmap + budget.]
+    Vibe1 --> Ship1[Short build loop.
Measure Section 4.]
+    Vibe2 --> Ship1
+    Trad1 --> Ship2[Long build loop.
Kickoff, sprints, demos.]
+    Trad2 --> Ship2
+
+    classDef start fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a
+    classDef vibe fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef trad fill:#fffbe6,stroke:#bf8a00,stroke-width:2.5px,color:#1a1a1a
+    classDef ship fill:#faf5ff,stroke:#a855f7,stroke-width:2px,color:#1a1a1a
+    classDef decision fill:#fff5f5,stroke:#cc342d,stroke-width:2px,color:#1a1a1a
+
+    class Start start
+    class Q1 decision
+    class Vibe1,Vibe2 vibe
+    class Trad1,Trad2 trad
+    class Ship1,Ship2 ship
+```
+
+**Vibe PRD if** the next stop is Lovable, Cursor, or a hired junior contractor. The one-page format is enough. The junior asks clarifying questions during the kickoff call; you answer in the same plain English you wrote the brief in. A senior would expect more context; a junior with an AI assistant ships faster from less.
+
+**Traditional PRD if** the next stop is a senior engineering team, an in-house product committee, or a board that needs a budget number attached. Senior engineers read briefs to find load-bearing assumptions you haven't named, and they expect a data model, an API outline, and an integration list. Product committees expect a roadmap, a phasing plan, and a go-to-market section. Both audiences will write the missing parts themselves if you don't include them, which is rarely what you want.
+
+The trap most founders fall into is writing a traditional PRD for a junior or an AI agent. The 5-page document buries the one paragraph the builder needed. By page 3, the agent has skimmed past the no-go list and started building a settings page.
+
+## When the $1,000 Maven course is worth it
+
+Drew Falkman runs ["Vibe Coding Data-Enabled AI Apps" on Maven](https://maven.com/), a 4-week cohort priced at $1,000. The course teaches the same five-section Vibe PRD template, plus the Lovable + Supabase + Stripe + GitHub stack, plus live community and 1:1 instructor feedback. The Maven [course reviews](https://maven.com/p/about) hover around 4.8/5.
+
+| Scenario | Maven cohort is worth it | This template is enough to start |
+|---|---|---|
+| You wrote the page tonight and can't tell whether it is good. | Yes. Go for peer review + feedback. | Actually, post the draft in a founder Slack - free feedback in 2 hours. |
+| Accountability is your blocker. (3 abandoned briefs in a drawer.) | Yes. The cohort structure + deadline forces you through. | No. You need external structure. The template alone won't help. |
+| You want to go deeper on Lovable + Supabase + Stripe stack mechanics. | Yes. The cohort spends 2 of 4 weeks on this. | No. You'll need the stack tutorials anyway; the template is concept-only. |
+| You can sit alone for 2 hours and finish the brief from the page above. | No. | Yes. The cohort buys peer review + deadline + deeper stack work, but you'll ship either way. |
+
+**Rule of thumb:** If you can sit alone for two hours and finish the brief, start here. The cohort buys structure, deadline, and stack depth. If you can't sit alone, $1,000 buys the accountability that gets the brief out of you.
+
+## What to do tomorrow
+
+| Step | Action | Output |
+|---|---|---|
+| **1** | Block a focused session tomorrow morning. Open your [Validated Problem Statement](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/) + [Vibe PRD Template](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) side by side. | Rough draft of all 5 sections. Copy Section 1 verbatim; fill Sections 2-5 from scratch. |
+| **2** | Read the brief aloud to one peer over coffee or a short call. Ask: "If you had to build this in a week using Lovable, what would you build that isn't in my no-go list?" | First answer = your missing no-go item. Add it to Section 5. |
+| **3** | Paste the brief into Lovable, Cursor, or your contractor's kickoff doc. Do NOT edit it for the audience. Same one page goes to everyone. | The agent or contractor starts building Tuesday morning. |
+
+The [Vibe PRD Template](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) is the artifact for this post. Print it, fill it in one focused sitting, hand it to your AI agent or contractor the next day, and Module 3's checkpoint moves one step closer.
+
+Skipping the brief and going straight into prompting is the most common way a non-technical founder ends up deep into a working MVP they realise they did not actually want - and into the [salvage-or-rebuild question](/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/) that follows. One focused sitting on this page tonight is what spares you that detour.
+
+## What comes next (Chapter 3.2, then Chapter 4.1)
+
+You now have two validated artifacts: a one-page problem statement (from Chapter 2.1 synthesis) and a one-page Vibe PRD (from this chapter). Two more steps before Lovable touches your brief:
+
+1. **[Chapter 3.2 - Quality-check your brief: features to outcomes](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/)** - stress-test Section 3 ("what you're building") by rewriting feature nouns as outcome-shaped job stories. This is the quality gate on the brief you just wrote, not a separate writing exercise.
+2. **[Chapter 4.1 - Should You Hire? The 2026 Decision Tree](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/)** - a 5-question decision tree that routes you to one of 4 build paths (validate without code / self-serve / fractional CTO / hire). The default for a non-technical founder is self-serve ([Chapter 4.3a · Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) + [4.3b · Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/)), but only after the decision gate confirms it's right for YOUR runway and YOUR problem. Chapter 4.1 explicitly requires the outcome-shaped brief from Chapter 3.2 as its input.
+
+A Vibe PRD is what's left when you remove everything an AI agent or a hired junior cannot act on by tomorrow morning.
+
+## Further reading
+
+- Drew Falkman, [Vibe Coding Data-Enabled AI Apps on Maven](https://maven.com/) - the $1,000, 4-week cohort that teaches the Vibe PRD with live feedback. Recommended if accountability is your blocker.
+- Marty Cagan, [Good Product Manager / Bad Product Manager](https://www.svpg.com/good-product-manager-bad-product-manager/) - the canonical essay on what a PRD is for. The Vibe PRD is the AI-era compression of the same shape.
+- Marty Cagan, [Product vs Feature Teams](https://www.svpg.com/product-vs-feature-teams/) - why the brief shapes what gets built. The no-go list is the part feature teams ignore.
+- Jake Knapp and John Zeratsky, [Foundation Sprint (Click, April 2025)](https://www.thesprintbook.com/foundation-sprint) - the 2-day version of the same artifact for teams that have 2 days. The Foundation Sprint workbook is freely sampled from the book site.
+- Ben Horowitz, [Good Product Manager / Bad Product Manager (1996 memo)](https://a16z.com/2012/06/15/good-product-managerbad-product-manager/) - the original Horowitz memo on the "good vs bad PM" frame; pairs with Cagan.
+- Veracode, [GenAI Code Security Report 2025](https://www.veracode.com/blog/genai-code-security-report/) - the 45% LLM-generated-code-flaw stat. Context for why the no-go list matters.
+- Y Combinator, [How to Write a PRD (Startup Library)](https://www.ycombinator.com/library/) - YC's distilled version of the same compression.
+
+> **Done when:** All 5 sections of your one-page brief are filled in, Section 1 is copied verbatim from your validated problem statement, and you have read the brief aloud to one peer.
+> **Founder OS · Artifact #4 of 6:** The one-page Product Brief (Vibe PRD). Save as `Product Brief - [date]` in your `Founder OS` folder. Module 4.1 reads the brief to decide your build path; Module 4.3 reads it to prompt Lovable.
+> **Next click:** [3.2 · Quality-check your brief: features to outcomes](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/)
+> **If blocked:** If you can't fill Section 3 (what you're building) in one paragraph, your scope is too big. Pick the single smallest workflow one persona can complete end-to-end and cut everything else to the no-go list.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Drafts a 1-page brief that passes the quality gate. Core 3 jobs: (1) auto-match Stripe to QuickBooks, (2) flag the 5% exceptions needing a human, (3) generate a reconciliation report. Out of scope: no ERP integrations, no multi-currency - just matching.
+>
+> **Mia**: Drafts a 1-page brief that passes the quality gate. Core 3 jobs: (1) search tutors by specialty + location, (2) read parent reviews before booking, (3) book + pay in one flow. Out of scope: no in-person coordination, no school district partnerships.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/vibe-prd-template-visual.svg b/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/vibe-prd-template-visual.svg
new file mode 100644
index 000000000..065b0f171
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/vibe-prd-template-visual.svg
@@ -0,0 +1,80 @@
+
+  One-page Vibe PRD - 5 sections on a notebook page
+  A clean notebook page divided into five fillable blocks. Section 1 copies the validated problem statement verbatim. Section 2 names the user, where they are, and the 60 seconds around using the product. Section 3 describes what is being built in one paragraph of plain English. Section 4 names one success metric with a number and a timeframe. Section 5 lists what is NOT being built in v1.
+  
+    
+  
+
+  
+
+  
+  
+
+  
+  
+  
+  
+
+  
+  Vibe PRD - One-Page Product Brief
+  Fill in 45 minutes after the validated problem statement. Hand to Lovable, Cursor, or a hired junior.
+
+  
+
+  
+  1.
+  The problem (copy from Chapter 2.1)
+  Persona + industry + dated sample + verbatim quote + cost.
+  _______________________________________________________
+  _______________________________________________________
+  Inherit word-for-word from the validated problem statement. Don't paraphrase.
+
+  
+
+  
+  2.
+  The user and their context
+  Who they are while using your product: __________________
+  60 seconds before reaching for it: ______________________
+  60 seconds after they close it: _________________________
+  e.g., "Founder alone at 9pm, Stripe + QuickBooks tabs open, wants to be done in 10 min."
+
+  
+
+  
+  3.
+  What you're building (one paragraph)
+  Smallest end-to-end thing the user can do: ______________
+  Inputs they provide + output they get back: _____________
+  What v1 explicitly supports (scope of done): ____________
+  e.g., "Paste Stripe CSV. Get QuickBooks journal entry CSV. USD only. Magic-link auth."
+
+  
+
+  
+  4.
+  Success metric (one number)
+  Number + unit + timeframe: ______________________________
+  How it's measured (event name, not gut feel): ___________
+  e.g., "10 of first 20 signups convert at least 1 file within 30 days. Event: conversion_completed."
+
+  
+
+  
+  5.
+  What you're NOT building (the no-go list)
+  5-8 lines of things the agent or contractor will add unprompted:
+  _______________________________________________________
+  Longer list = cheaper build
+
diff --git a/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/cover.png b/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/cover.png
new file mode 100644
index 000000000..ed29979c3
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/index.md b/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/index.md
new file mode 100644
index 000000000..9882af35c
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/index.md
@@ -0,0 +1,301 @@
+---
+title: "5.5 · Going Outbound Without a Sales Team"
+aliases: ["/blog/outbound-without-sales-team/"]
+description: "Once the network is exhausted, customers 11-20 come from filtered cold outbound. The Filter -> Loom -> Calendly -> Stripe pipeline, 4-line scripts."
+date: 2026-05-13
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: outbound-without-sales-team
+keywords:
+  - cold outbound non technical founder
+  - filtered cold email 2026
+  - linkedin sales navigator founder
+  - apollo io free tier founder
+  - first ten customers cold outreach
+tags:
+  - founders
+  - non-technical-founder
+  - first-paying-customer
+  - sales
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "5.5 · Going Outbound Without a Sales Team"
+  og_description: "Once the network is exhausted, customers 11-20 come from filtered cold outbound. The Filter -> Loom -> Calendly -> Stripe pipeline, 4-line scripts."
+cover_image_alt: "JetThoughts blog cover showing a cold-outbound pipeline funnel from filtered list through Loom and Calendly to a signed Stripe invoice"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/"
+related_posts: false
+---
+
+> **Module 5 · Step 5 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** network exhausted, ~10 customers in from [Chapter 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/) and [Chapter 5.4](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/)
+>
+> **Output:** 30 cold messages sent, 3-5 demo calls booked, 1-2 paid pilots cleared once replies mature
+
+> **TL;DR:** Once your network is exhausted, 30 filtered cold messages with a specific personalization per name will book 1-2 paid pilots. Customers 11-20 come from cold outbound, not from launch events.
+
+> **Stop here if you have not exhausted your personal network.** This chapter covers cold outbound to strangers - it assumes you have already converted the people who know you through [Ch 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/).
+>
+> If you still have warm names in your network who fit your ICP, close them first. Cold outbound is harder, slower, and lower-converting than warm outreach.
+>
+> Reading this chapter before your network is dry is the most common sequencing mistake founders make in Module 5 - it feels like progress, but you are skipping the higher-converting path for the lower one. The chapter will still be here when your network is done.
+
+> **$0 outbound stack.** Apollo's free tier (credit-based: roughly 100 email credits + 10 export credits per month) + a Google Sheet + Gmail mail-merge add-on (free) + Loom free + Calendly free covers the entire pipeline at zero monthly cost. You ship the same 30-message batch, you just enrich the list manually in a sheet instead of automating it through Smartlead. Upgrade to Apollo Pro ($49) or Smartlead ($39 Base plan) only when you're sending 100+ messages a week and the manual enrichment is the bottleneck.
+
+This chapter is sales outbound asking buyers for money, which is a different motion from the interview-recruitment outreach in [Chapter 2.3b](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) where you were asking for 30 minutes of their time.
+
+The 10 people you interviewed in Module 2 may or may not become customers, and outreach to them goes through the sales sequence below rather than the recruitment script.
+
+The one difference is that those Module 2 interviewees are warm targets - they already spoke with you about their pain, so your first line can reference that conversation directly instead of finding an external hook.
+
+Product Hunt converted at 3.1% per launch event across 387 launches OpenHunts studied in 2024. Indie Hackers - posts written as engagement rather than launch announcements - converted at 23.1% per engaged post over the same period.
+
+89% of the Product Hunt founders OpenHunts surveyed said they would not launch on the platform again ([source](https://awesome-directories.com/blog/indie-hackers-launch-strategy-guide-2025/)). The data has been public since the OpenHunts study released in mid-2024, yet every "first 10 customers" article still leads with Product Hunt.
+
+Product Hunt is not bad; it is a one-day event in a job that needs sustained motion over a quarter.
+
+Picture the situation. Four paid pilots have closed from your personal network and LinkedIn audience over six weeks. The warm names are gone at customer five. The default move is to book a launch coach or sign an ad-agency contract. Either decision costs the same six weeks and a few thousand dollars - and neither one was designed for your B2B vertical.
+
+The four-line cold-email sequence below is what customer five answers in week three for under $40 of tooling.
+
+![Product Hunt 3.1% vs Indie Hackers 23.1% - per OpenHunts 2024](ph-vs-ih.svg)
+
+This is the closing chapter of Module 5 (First Paying Customer). Once your personal network is exhausted, the next 10 customers come from filtered cold outbound, not from launch events.
+
+Figma's first customer 11-20 cohort came from cold DMs to influential designers identified via Twitter data. Retool filtered Crunchbase by funding recency. Your rescue-Rails MVP customer 11-20 cohort will come from LinkedIn Sales Navigator (or Apollo, or both) feeding the four-line script below.
+
+## Why Product Hunt is the wrong lever for a B2B SaaS product
+
+> **Product Hunt is one day. Cold outbound is sustained. Sustained motions are what put paying customers on the calendar.**
+> 
+> Product Hunt converts at 3.1% (387 launches, OpenHunts 2024). Indie Hackers converts at 23.1% per engaged post. 89% of Product Hunt founders said they'd never launch again. Product Hunt suits developer tools / AI productivity / indie SaaS where buyers read it daily. Your B2B buyer at a 50-500 person company in a specific vertical doesn't. The 5,000 upvotes are from the wrong people.
+> 
+> The calendar shapes the outcome: Product Hunt is one day, Indie Hackers is sustained engagement, filtered cold outbound is recurring 30-message batches until you have a funnel. Founders shortcutting to one-day launches keep being surprised leads don't show up the next morning. The question is not "which big launch." It is "which 50 named buyers should hear from me first."
+
+## The pipeline: Filter -> Personalize -> Loom -> Calendly -> Stripe
+
+You run the whole pipeline in six stages with off-the-shelf tools - no engineer, no $1,200/month sales stack, no Salesforce.
+
+The cold-outbound pipeline in one glance:
+
+1. **Filter** - LinkedIn Sales Navigator or Apollo.io. Pull 100-150 raw rows, strip to 30 clean names.
+2. **Personalize** - 60-90 seconds per name. Read the profile and the last post, find one specific reference.
+3. **Loom** - Same product Loom from [Chapter 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/). No re-record per prospect.
+4. **Send** - LinkedIn DM or 4-line email. One personalized opener + the same body for everyone.
+5. **Calendly** - 15-min demo slot, auto-confirm. No back-and-forth scheduling.
+6. **Stripe** - DPA + deposit from [Chapter 5.4](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/). Money on the table before you start work.
+
+The five tools and their 2026 pricing:
+
+| Tool | Role | Price |
+|---|---|---|
+| LinkedIn Sales Navigator | Filter buyers by title, company size, funding signal, role tenure | $99/month single-user (Core tier) |
+| Apollo.io (Starter / free tier) | Cheaper alternative to Sales Nav for B2B email + filters | Free tier available; paid Apollo Pro starts ~$49/mo |
+| Loom | 90s product walkthrough + you on camera | Free tier: 25 videos |
+| Calendly | 15-min demo booking, auto-confirm | Free tier supports one event type |
+| Stripe Invoice | Pilot deposit, no monthly fee | 2.9% + 30c per transaction |
+
+You can ship the entire pipeline for under $100/month if you use Apollo's free tier and skip Sales Navigator.
+
+The trade-off: Sales Navigator's filters are richer for enterprise buyer profiles (especially for filtering on "joined company in last 90 days" or "recent leadership change"), and Apollo's free tier has limited credits.
+
+If your buyer is a 50-200 person company contact in a specific industry, Apollo free tier is enough. If your buyer is a recent VP hire at a 500-2,000 person company, Sales Navigator pays for itself in week 1.
+
+> **Pre-flight: warm your sending domain BEFORE batch 1.** A brand-new sending domain (e.g., `yourcompany.com` registered last week, no email history) will land in spam on batch 1 even with a perfect ICP list and a sharp script. The fix is either:
+>
+> 1. **Use LinkedIn DM for batch 1.** No domain warmup required. Sales Navigator + 30 personalized DMs gets the same reach as cold email for a B2B founder, and the messages reliably deliver.
+> 2. **OR warm the domain for 2-3 weeks first.** Use a tool like [Mailwarm](https://mailwarm.com) or [Smartlead's warmup](https://smartlead.ai) (the same tools mentioned in this chapter's $0 stack section) to send 5-10 low-volume reply-conversation emails per day to seed positive sender reputation. After 2-3 weeks of warmup, send batch 1 from the same domain.
+>
+> Skip this step and the <5% reply-rate diagnostic below tells you "domain rep is dead" - because the domain never had reputation in the first place. The mechanical cause of your 0 replies is the domain, not the ICP filter or the script.
+
+### Volume targets and what to expect
+
+Running outbound long enough to read the funnel, 100-200 outreach contacts produces 5-10 paying customers. The funnel at each stage:
+
+| Stage | Target |
+|---|---|
+| Raw list pulled | 100-200 names |
+| Sent (after filter) | 30-message minimum per batch, several batches |
+| Reply rate | ≥5% (below 5% = stop and diagnose) |
+| Demo-to-paid | ≥20% of demos taken |
+| Paid pilots landed | 5-10 from 100-200 outreach |
+
+A 10% reply rate on 30 messages is 3 replies. At 20% demo-to-paid, 3 demos lands 0-1 pilots per batch - consistent with the multi-batch model above. The numbers are not impressive individually; they compound across batches.
+
+### Filter: getting to 30 high-fit names
+
+Apollo or Sales Navigator. Filter on the six dimensions you defined in [Chapter 2.3a · Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) (the same filter you saved as the `Module 5 cold seed` tab in your outreach spreadsheet): job title (the buyer or the user, pick one), company size (start one tight band), industry (one vertical first), geography (one timezone for callable demos), technology used (filter for tools your product replaces or integrates with), recent funding or hiring signal (companies with momentum reply faster).
+
+Pull 100-150 raw rows. Strip three categories before sending:
+
+- Anyone whose company size or title is one band off your ICP. The 80% match is not the 100% match.
+- Anyone whose LinkedIn shows no posting activity in the last 12 months. They will not see your DM.
+- Anyone whose company you have a competing product alignment with (you sell to their competitor). A B2B services founder who came to us in March 2026 lost a great lead this way and had to wait two quarters for the lead's company to pivot before reaching out again.
+
+You should be left with 30-50 clean names. Hold the bottom 20 for a later batch and send the top 30 in the first batch.
+
+> **Apollo free-tier reality.** Apollo's free tier is credit-based (~100 email credits + ~10 EXPORT credits per month). The "pull 100-150 raw rows" instruction is achievable on the free tier only if you spread it across 10+ months OR use LinkedIn DM for batch 1 and reserve Apollo exports for batch 2+. Recommended sequence for free-tier founders: (1) build batch 1 from your existing LinkedIn 1st-degree connections + Sales Navigator trial (free for 1 month, no Apollo needed); (2) start Apollo on month 2 with the credits dripping in over time; (3) upgrade to Apollo Pro ($49/mo) only when you have a working reply-rate signal that justifies the spend.
+
+### Personalize: 60-90 seconds per name, not 10 minutes
+
+The mistake founders make on the first batch is over-personalizing. Twenty minutes of LinkedIn research per prospect turns into a 400-word email with five quoted lines from their feed, and response rates fall off a cliff above the four-line threshold.
+
+The right level of personalization is one specific reference per message: scan the last three posts and the recent role, find one specific thing (a post, a comment, a hiring milestone, a recent promotion). One sentence. Then the same four-line script for everyone.
+
+The 60-90 second rule keeps the volume tractable. 30 prospects × 90 seconds = 45 minutes of personalization per send. A founder can do that in one focused sitting.
+
+> **Advanced: Loom video audit (higher conversion, higher effort).** Instead of a text-based cold message, record a 10-minute Loom video showing the prospect's specific pain point on THEIR website or in THEIR public product, then demonstrate how your MVP solves it. Send directly to the decision-maker via LinkedIn DM or email. Conversion is significantly higher than cold text because the video proves you did the work rather than claiming you did. The trade-off: each video takes 10-15 minutes to record and upload vs 60-90 seconds for a text personalization. Use this for your 5 highest-value prospects per batch, not all 30. The same product Loom from stage 3 of the pipeline works for the demo portion; only the first 2-3 minutes (showing their specific pain point) is custom per prospect.
+
+## The 4-line cold-email script (3 variants)
+
+### Variant 1: B2B SaaS, shipped-MVP context
+
+> Subject: shipped MVP last month - your post on [topic]
+>
+> Hi [first name],
+>
+> Saw your post on [topic, paraphrased in their words] last [Tuesday]. I shipped my MVP for [the same problem] last month using [Lovable + Supabase + Stripe] after 12 interviews with people who flagged the exact issue you described. I built [a tool that does X for Y].
+>
+> Worth 15 minutes to walk through? Paid design partner spots, [$ deposit] credited toward year one. Calendly: [link]
+>
+> [Your name]
+
+### Variant 2: B2B services
+
+> Subject: noticed your hiring for [role]
+>
+> Hi [first name],
+>
+> Saw [Company] is hiring a [role] - guessing [the problem the role solves] is on your roadmap. I run a [services category] practice and we have helped [a comparable company size] handle [the same problem] in [the same vertical] in the last six months.
+>
+> Open to a 15-minute walk-through? Paid pilot model, [$ deposit] credited toward year-one engagement. Calendly: [link]
+>
+> [Your name]
+
+### Variant 3: B2C app
+
+> Subject: re: your [Reddit post / TikTok video] on [topic]
+>
+> Hi [first name],
+>
+> Your [Reddit post / TikTok video] on [topic] hit. I built an app that handles [the painful task you described] - the link below is a 90-second Loom showing it work end-to-end on my phone.
+>
+> Loom: [link]. App: [link]. If it looks useful, I am opening 20 paid beta spots at $9/month for the first month. Reply to claim one.
+>
+> [Your name]
+
+All three variants follow the same shape: a specific reference earns the open, one sentence on what you built, one specific ask with friction removed (Calendly or Loom + claim link), one currency anchor (deposit, beta price). Total length: 4-6 lines including subject. Anything longer reduces response rate.
+
+## Stage-by-stage cadence
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TB
+    W1[Stage 1
Send 30 messages
3-5 replies expected]
+    W2[Stage 2
Run 3-5 demos
2-3 DPAs sent]
+    W3[Stage 3
1-2 deposits cleared
Pilot kickoffs scheduled]
+    W4[Stage 4
Send next 20
Hold for reply tail]
+    W5[Stage 5
First Friday demos
+ earlier prospects mature]
+    W7[Stage 6
Year-one conversions
+ next 20 cold names]
+    W1 --> W2 --> W3 --> W4 --> W5 --> W7
+    classDef coldweek fill:#fff5f5,stroke:#cc342d,stroke-width:2px;
+    classDef warmweek fill:#fbe9ff,stroke:#a855f7,stroke-width:2px;
+    classDef conv fill:#fff8e0,stroke:#b8860b,stroke-width:2px;
+    class W1,W4 coldweek;
+    class W2,W5 warmweek;
+    class W3,W7 conv;
+```
+
+Expect a 10-20% reply rate on a properly filtered, properly personalized 30-message batch. That is 3-6 replies, of which 2-4 will agree to a 15-minute demo. Of the demos, 1-2 will agree to a paid pilot. Of the pilots, the [Chapter 5.4](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) deposit-to-year-one conversion math holds - around 60% of paid pilots convert to year-one customers.
+
+The 30-message batch is not a one-time event. Run fresh 30-message batches until you have 20 customers. The second and third batches will outperform the first by 30-50% because you will have learned which reference patterns earn replies and which do not.
+
+### What "no reply" actually means
+
+> **First-batch reality before the diagnostic.** If your first 30-message batch returns 0-1 replies, your first reaction will be "the product is bad" or "my message is generic." Both of those CAN be true, but the more common cause for a brand-new founder with a new sending domain is mechanical: the messages did not deliver, or the domain has no warmup history yet, or the personalization felt fake despite being real.
+>
+> **A 0-1 reply rate on batch 1 is the median outcome for first-time cold senders, not a failure signal.** Walk the 3-item diagnostic below before you change the message, the price, or the product.
+
+A 30-message batch with zero replies is rare and almost always indicates a filter problem, not a script problem. Check three things:
+
+1. **Did the messages deliver?** If you are using cold email (vs LinkedIn DM), check your sending tool's bounce rate. Above 10% bounce means your list is dirty and your domain reputation is suffering. Pause sending and re-warm the inbox before continuing.
+
+2. **Is the filter right?** Re-read three random LinkedIn profiles from your sent list. If you cannot imagine the person reading the message and finding it relevant, your ICP filter is off. The fix is upstream of the script.
+
+3. **Is the reference real?** Look at the first paragraph of your last 10 sent messages. If the "specific reference" sentence sounds generic ("noticed you work at [Company] in [role]"), it was not specific enough. Real specificity means the prospect can verify the claim - a date, a post title, a name, an event.
+
+10-15% reply rate is the baseline for a well-filtered, well-personalized batch in 2026.
+
+> **Stop / continue / accelerate, by reply rate band.**
+> - **<5% reply rate** → STOP after batch 1. Diagnose before batch 2: filter is wrong, domain reputation is dead, or script reads generic. Sending batch 2 over a broken upstream stage wastes the next 30 best-fit names on the same broken funnel.
+> - **5-10% reply rate** → CONTINUE but rotate one element of the script for batch 2 (subject line, opening reference, or CTA). One variable per batch so you can read which change moved the rate.
+> - **>10% reply rate** → ACCELERATE. You have a hot channel. Run batch 2 same-shape and same-cadence. Resist the temptation to "scale" the batch size past 30 - the personalization budget per message is the load-bearing input, and 30 is the practical ceiling for one founder doing it by hand.
+
+## Compounding past customer 20
+
+> **Ask your first 20 for one introduction each. That feeds enough warm leads to stop scaling cold outbound past the current batch size.**
+>
+> Customers 11-20 come from filtered cold outbound. Customers 21-50 come from referrals out of customers 1-20. If your first 20 were chosen carefully (must-have segment, personal network + filtered outbound), each knows two more in the same segment.
+>
+> The motion is asking for one introduction each. Script at the end of every Friday demo once the cadence is established: *"If this is useful for you, do you know one or two others I should be talking to?"*
+>
+> Half say yes. Half of those actually send the intro. A steady drip of warm leads from a 20-customer base is enough to keep cold outbound steady rather than scaling the batch size.
+
+## What to do next
+
+| Step | Action | Output |
+|---|---|---|
+| **1** | Open your `Module 5 cold seed` tab from Ch 2.3 (a + b) - the Apollo filter is already saved and 8-12 contacts may already be exported. Top up to 30-50 high-fit names using the same filter. Drop bottom 20 into a "later batch" tab in your Sheet. Pick one of three message variants and customize deposit + product description. | 30-50 target list built. Message template ready. |
+| **2** | Spend 60-90 minutes personalizing the first 30 messages. One specific reference per prospect (recent post, hire milestone, role change). Send via LinkedIn DM or cold email tool ([Smartlead](https://smartlead.ai), [Instantly](https://instantly.ai)). | 30 messages sent. 3-6 replies expected. |
+| **3** | Tally replies once they settle. Book demos. Follow up with non-responders once only. | 2-4 demo calls booked. Next batch ready. |
+
+The full cold-email scripts (3 variants: B2B SaaS shipped-MVP, B2B services, B2C app), the filter checklist, and the Apollo + Sales Navigator setup guide all ship in [the First-Paying-Customer Operating Kit](/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/).
+
+## Advanced (optional sidebar)
+
+Once you have closed 5-10 paid pilots from cold outbound and want to layer on sales-system rigor, read the [First Round Capital sales scripts collection](https://review.firstround.com/category/sales/), Sahil Bloom's ["The First 10 Customers"](https://www.sahilbloom.com/newsletter/the-first-10-customers) playbook, and the [Y Combinator library on early sales](https://www.ycombinator.com/library/4f-startup-sales-the-fastest-way-to-find-your-first-customers). Once you cross customer 30, the sales playbooks designed for solo founders give way to operator manuals: Mark Roberge's *The Sales Acceleration Formula* for hiring your first AE, Mike Weinberg's *New Sales. Simplified.* for the manager handbook. The main path above gets you from customer 11 to customer 20. The advanced versions matter after that.
+
+> **Module 5 closes here.** → Download the [First-Paying-Customer Operating Kit](/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/) (the full 6-piece template bundle). Now you have a paying pilot, the rest of the course is about keeping the build honest while you ship more: the [oversight rhythm](/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/) sets up the weekly Friday demo + standup + report cadence. Or revisit the [course landing page](/course/tech-for-non-technical-founders-2026/) to pick the next chapter.
+
+## Going further (after your first paying customer)
+
+You've completed the core 5-module course - hypothesis, smoke test + price, problem validation + prototype, brief + build, first paid pilot. Continuation chapters apply once you've signed your first paid pilot:
+
+| Symptom | Continuation chapter |
+|---|---|
+| **Customers leaving in week 2-4** | [Churn Triage Before Acquisition](/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/) - fix retention before spending on more outbound |
+| **Key metric flat for 2+ months** | [Pivot or Persevere](/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/) - decision framework for the next move |
+| **Hit the self-serve ceiling** | [Hire Track Supplementary Reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/) - when to hire and what to look for |
+| **Product touches AI in production** | [Agency AI Questions](/course/tech-for-non-technical-founders-2026/agency-uses-ai-follow-up-questions/), [AI Token Bill](/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/), [Slopsquatting](/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/) - AI-era hygiene |
+
+The course graduates here. Return to the [course landing page](/course/tech-for-non-technical-founders-2026/) when you're ready to retake it for a new project.
+
+Module 5 closes with a deposit in your Stripe account. Everything from here is keeping the build honest while you ship to customer 11.
+
+## Further reading
+
+- OpenHunts (via Awesome Directories), [Indie Hackers Launch Strategy Guide 2025](https://awesome-directories.com/blog/indie-hackers-launch-strategy-guide-2025/) - source for the Product Hunt 3.1% vs Indie Hackers 23.1% per-engaged-post conversion data from the 387-launch 2024 study.
+- Lenny Rachitsky, [How to win your first 10 B2B customers](https://www.lennysnewsletter.com/p/how-to-win-your-first-10-b2b-customers) - the 7-step playbook from 100+ B2B founders, including the cold-outbound section.
+- First Round Capital, [Cold Outreach That Works: A Founder Playbook](https://review.firstround.com/from-1-to-1000-users-tactics-from-airbnb-tinder-etsy-reddit-and-more/) - tactical cold-outreach scripts from Airbnb, Tinder, Etsy, Reddit founder interviews.
+- Paul Graham, [Do Things That Don't Scale](http://paulgraham.com/ds.html) - the foundational text on manual customer recruitment, including the Stripe Collison-brothers cold-DM-and-install motion.
+- Y Combinator Library, [Startup Sales: The Fastest Way to Find Your First Customers](https://www.ycombinator.com/library/4f-startup-sales-the-fastest-way-to-find-your-first-customers) - YC's collection on founder-led sales including the filter-and-personalize cold-outreach motion.
+- Sahil Bloom, [The First 10 Customers](https://www.sahilbloom.com/newsletter/the-first-10-customers) - playbook framing the relationship-to-cold transition that closes the personal-network gap.
+
+> **Done when:** 30 cold messages are sent, replies are tracked in your spreadsheet, and 1-2 paid pilots are booked from the replies.
+>
+> **Next click:** [Course landing page](/course/tech-for-non-technical-founders-2026/) - course complete. See continuation chapters for [churn triage](/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/), [pivot decisions](/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/), and [hiring](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/).
+>
+> **If blocked:** If reply rate is under 5% after batch 1, diagnose before batch 2: is the filter wrong (wrong ICP), is your domain reputation dead (cold email deliverability), or is the personalization too generic? Fix the root cause before sending the next batch.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Runs LinkedIn cold outreach to 30 controllers NOT in his network. 12% reply rate (4 replies). Books 2 pilot conversations. 1 signs at $2,500. Total: 3 paid pilots (2 from network, 1 from cold). Annualized: $30,000 in committed pilot revenue.
+>
+> **Mia**: Runs Facebook group cold outreach to 30 parents NOT in her network. 28% reply rate (8 replies), 5 pilot conversations, 2 sign at $50 - total: 6 paid pilots at $300/mo recurring.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/ph-vs-ih.svg b/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/ph-vs-ih.svg
new file mode 100644
index 000000000..3a9de994b
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/ph-vs-ih.svg
@@ -0,0 +1,46 @@
+
+  Product Hunt 3.1% vs Indie Hackers 23.1% - the OpenHunts 2024 conversion data
+  
+    
+  
+
+  Launch-day platforms - what actually converts in 2024
+  OpenHunts study of 387 product launches and 156 founders surveyed
+
+  
+  
+  0%
+  10%
+  20%
+  30%
+  40%
+
+  
+  
+  3.1%
+  Product Hunt
+  per launch event
+  89% of PH founders surveyed
+  said they would not launch again
+
+  
+  
+  23.1%
+  Indie Hackers
+  per engaged post
+
+  
+  
+  7.4x conversion advantage for IH per engaged post vs PH per launch.
+  Different metrics, same lesson: showing up where founders complain converts; one-day launches do not.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/outreach-sequence-template/cover.png b/content/course/tech-for-non-technical-founders-2026/outreach-sequence-template/cover.png
new file mode 100644
index 000000000..825567796
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/outreach-sequence-template/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/outreach-sequence-template/index.md b/content/course/tech-for-non-technical-founders-2026/outreach-sequence-template/index.md
new file mode 100644
index 000000000..034f1a358
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/outreach-sequence-template/index.md
@@ -0,0 +1,233 @@
+---
+title: "Outreach Sequence Template: 10 Customer Interviews by Friday"
+aliases: ["/blog/outreach-sequence-template/"]
+description: "Reddit + LinkedIn + Clay + Lindy + paid panels = 10 ICP interviewees booked in one morning. The 2026 stack with copy-pasteable email + DM templates."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: outreach-sequence-template
+keywords:
+  - founder cold outreach template
+  - Clay Apollo Lindy founder
+  - book customer interviews 2026
+  - validation outreach sequence
+  - non technical founder outreach
+tags:
+  - founders
+  - non-technical-founder
+  - template
+  - course-companion
+  - validation
+categories: ["Templates"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/outreach-sequence-template/"
+related_posts: false
+---
+
+📋 Template companion to [Chapter 2.3b · What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/). Build the 30-name list first in [2.3a · Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/), then run this template Monday morning. 10 calls in your calendar by Friday.
+
+# Find 10 People With the Problem - The 2026 Outreach Sequence Template
+
+*Reddit + LinkedIn + Clay + Lindy + paid panels = 10 interviewees by Friday.*
+
+> **📋 Quick-ref checklist - copy this into Notion before you start:**
+>
+> - [ ] **Written problem hypothesis** - *"I think [persona] does [task] in [painful way] and would pay $X for [better way]"*
+> - [ ] **4 tabs open, 2 hours mined** - Reddit, LinkedIn, one Discord/Slack, G2/Capterra. 30 verbatim pain sentences captured.
+> - [ ] **ICP list built** - 80-120 rows from Clay or Apollo. Six-filter dimensions applied. 50 names queued for send.
+> - [ ] **3-email sequence live** - Smartlead or Instantly + Lindy + Calendly. Day 0/3/7 messages pasted below.
+> - [ ] **Paid panel backup running** - User Interviews or Respondent screener live. Running in parallel with cold outreach.
+> - [ ] **Smoke-test page live** - Carrd or Framer waitlist. $100-200 ad spend. Target: 5%+ email signup rate.
+
+## Why this exists
+
+A consumer-app founder we spoke with last month spent a full week messaging her LinkedIn network. She sent 60 polite DMs, booked 3 calls, and two of the three were old colleagues showing up to be nice. She had one real conversation, and that founder ghosted on the reschedule. Same week, same hypothesis: she pivoted to the stack below on a Monday morning - two hours on Reddit, an Apollo list of 80 contacts, a 3-email Smartlead sequence with a Lindy agent reading replies, and $400 on a User Interviews panel as a backup track. By Thursday afternoon she had **12 calls booked**. The point isn't that her network was wrong. It's that her network was 3 contacts deep when she needed 10, and the next 7 were strangers she had to find on purpose. The template below is what she ran.
+
+## How to use it
+
+Run this on a **Monday morning, alone, with a credit card**. Budget: 4 hours of your time on Monday + $200 to $500 in tools and panels across the week. Outcome: 10 booked calls by Friday afternoon.
+
+Before you start, you need one thing: a written problem hypothesis. One sentence: *"I think [persona] currently does [task] in [painful way] and would pay $X to do it [better way]."* Module 0 routed you here because the worksheet flagged you don't yet have 10 conversations on this. The sequence below is how you get them.
+
+Run the three tracks in parallel, not in sequence. Cold outreach, paid panels, and the smoke-test landing page fail differently - running all three means even if two flop, you have a real Friday number.
+
+## The 5-step sequence
+
+### Step 1 - Mine where they're already complaining (Monday, 2 hours)
+
+Open four tabs. Read for two hours. Don't write a single message yet.
+
+**Reddit.** Search the exact words your prospect would use. For a typical B2B SaaS founder ICP, productive subreddits are **r/SaaS**, **r/startups**, **r/Entrepreneur**, plus one or two niche subs for your buyer (r/sysadmin if IT, r/marketing if CMO, r/smallbusiness if owner-operator). Sort by Top - Past Month. Read the top 50 posts. Note the exact wording of complaints and existing workarounds.
+
+**LinkedIn.** Type the problem in quotes. Filter to Posts - Past Week. The 1% of LinkedIn willing to complain in public is also the 1% willing to take a call.
+
+**Discord and Slack.** Indie Hackers Discord, Lovable Discord, No Code Founders Slack, plus one industry-specific server. Read the #help-and-feedback channels. The daily question is "has anyone else hit X."
+
+**G2 and Capterra reviews.** Pull every 2-star and 3-star review of the closest competitor or workaround tool. The text is the language of pain a stranger willingly typed for free.
+
+Write down **30 specific sentences in their language**. That bank is the raw material for the messages in Step 3. Don't paraphrase. Use their words.
+
+### Step 2 - Build the ICP list (Monday, 1 hour)
+
+Two tools matter in 2026.
+
+| Tool | Price (2026) | Use when |
+|---|---|---|
+| Clay (clay.com) | ~$149/mo Starter | You need 100+ clean rows with 50+ enrichment sources, deduped and email-verified. |
+| Apollo (apollo.io) | $49-$149/mo | You need 50-100 rows fast and the search filters are enough. Budget option. |
+
+Filter on six dimensions:
+
+1. **Job title** - the buyer OR the user, not both. Pick one.
+2. **Company size** - 50 to 500 employees is the sweet spot (small enough to reach a decision-maker, big enough to have the problem).
+3. **Industry** - one vertical first. Expand later.
+4. **Geography** - one timezone, so calls are bookable.
+5. **Technology used** - if your product replaces or integrates with a specific tool, filter for it.
+6. **Recent funding or hiring signal** - companies with momentum reply faster.
+
+Export 80 to 120 rows. Send to 50, hold 30 in reserve, drop the bottom 40. For consumer founders, Apollo and Clay don't help much - skip to Step 4 and Step 5 instead.
+
+### Step 3 - Run the sequence (Tuesday morning)
+
+Three tools, one workflow.
+
+| Tool | Price (2026) | Role |
+|---|---|---|
+| Smartlead (smartlead.ai) or Instantly (instantly.ai) | $39-$94/mo (Smartlead Base $39) | Sending layer. Handles deliverability, rotates 5-10 inboxes, keeps you out of spam. |
+| Lindy (lindy.ai) | from $49/mo | AI agent. Reads replies, classifies them, sends follow-ups, books calls. |
+| Calendly (calendly.com) | free-$10/mo | Calendar booking. Lindy drops your link when a reply says yes. |
+
+**3-email sequence (copy and paste):**
+
+> **Day 0 - intro**
+>
+> Subject: `quick question about [their exact workaround]`
+>
+> Hi [first name],
+>
+> Saw your post on r/SaaS last week about [the exact thread, paraphrased in their language]. I'm a [your role] looking into the same problem and trying to understand how teams like yours [the specific painful task] today.
+>
+> Not selling anything. I'm 20 minutes from launching a [thing] for this and I want to make sure I'm building what people actually need. Would you be open to a 20-minute call so I can ask 5 questions about how you handle [the task] now?
+>
+> If yes, here's my calendar: [Calendly link].
+>
+> Thanks,
+> [Your name]
+
+> **Day 3 - bump**
+>
+> Subject: `re: [their workaround]`
+>
+> Hi [first name],
+>
+> Bumping this. 20 minutes, your time of choice. I'm not pitching - I'm asking how you do [the task] today and what breaks when you try. The 30 founders I've already spoken to have made the [thing] meaningfully better, so the call is genuinely useful on your end too.
+>
+> [Calendly link]
+>
+> Thanks,
+> [Your name]
+
+> **Day 7 - close**
+>
+> Subject: `last try - 20 min on [topic]`
+>
+> Hi [first name],
+>
+> Last note from me. If this isn't your problem, no worries - I'll stop. If it is and you just haven't had a chance to look, here's the link one more time: [Calendly]. I'm running interviews through next Friday.
+>
+> Thanks either way,
+> [Your name]
+
+**LinkedIn DM openers (3 variants - same sequence pattern, shorter form):**
+
+> 1. "Saw your post yesterday on [exact topic]. I'm 20 min from launching a thing for [task] and want to make sure I'm not building the wrong thing. Open to 20 min so I can ask 5 questions about how you handle this today? [Calendly]"
+
+> 2. "Read your G2 review of [competitor] - the bit about [exact frustration] is exactly what I'm working on. 20 min to ask you 5 questions about what would actually help? [Calendly]"
+
+> 3. "We've never met but you commented something useful on [post] about [problem]. I'm researching it from the founder side - 20 min so I can ask how you currently handle [task]? Not selling, asking. [Calendly]"
+
+**Cold-email subject lines (3 variants):**
+
+> 1. `quick question about [their exact workaround]`
+
+> 2. `[their company] + [the painful task] - 20 min?`
+
+> 3. `re: your r/[sub] post on [topic]`
+
+**Reddit "I'm researching X" comment (1 variant - post AFTER you've added value to the sub for a week):**
+
+> "I'm a founder researching [exact problem in their words]. Not promoting anything yet - just trying to understand how 10 people who hit this currently solve it. If you're up for a 20-minute call this week or next, my DMs are open / here's a Calendly: [link]. Happy to share back what I learn from the calls in a follow-up post here."
+
+**Calendly booking page copy:**
+
+> "20-minute research call - [your name]
+>
+> What this is: I'm researching [problem] from the founder side. I'll ask you 5 questions about how you currently handle [task], what breaks, and what you've tried. No pitch, no demo.
+>
+> What you get: I'll send you a 1-page summary of what the 30+ people I interview say. You'll see the patterns before anyone else.
+>
+> Bring: Nothing. Show up, talk for 20 minutes, hang up."
+
+### Step 4 - Backup via paid panels (kick off Tuesday in parallel)
+
+When your ICP is too niche for Clay or Apollo (a specific executive role, a regulated industry, a consumer audience), pay for the panel.
+
+| Service | Price (2026) | Best for |
+|---|---|---|
+| User Interviews (userinterviews.com) | $50-$150 per interviewee | Generalist B2B and consumer panels. 8-person panel = $400-$1,200 all-in. 3-5 day lead time. |
+| Respondent (respondent.io) | Often cheaper for hard-to-reach roles | CFOs, engineering directors, ops leaders. B2B-leaning. |
+
+Write the screener questions tight. Three screening questions filter out the wrong panel and you pay only for fit interviewees. Run paid panels **in parallel** with cold outreach, not as a replacement - the two channels select for different people, and both samples are biased in opposite directions.
+
+### Step 5 - The parallel smoke-test landing page (Monday afternoon)
+
+While Steps 3 and 4 book calls, Step 5 measures whether strangers will give you their email for the thing you described.
+
+| Tool | Price (2026) | What you ship |
+|---|---|---|
+| Carrd (carrd.co) | $19/year | One-page waitlist landing page. Headline, subhead, email capture. |
+| Framer (framer.com) | $5-$15/mo | Same job, more design control. |
+
+Page anatomy: **headline** (problem in their language, from Step 1) + **subhead** (solution in one sentence) + **one CTA** ("Be first on the waitlist"). Email capture only. No pricing, no signup, no fake product screenshot.
+
+Drive £100 to £200 of paid traffic from Google Ads or LinkedIn Ads, targeting the keywords you searched in Step 1. Aim for 200 to 500 visitors over 5 days.
+
+Signal you want: **5%+ email signup rate**. Below 2% means the headline or offer is wrong - rewrite both. Between 2% and 5% means directionally right, wording isn't sharp. Above 5% means strangers find the problem real enough to give you an email for a product that doesn't exist yet.
+
+The signups become the warmest opener for Step 3 follow-up: "You signed up for the waitlist on [page] last Tuesday - would you be up for a 20-minute call?" runs 60%+ reply rates.
+
+## What good looks like vs what bad looks like
+
+**The Day-0 cold email**
+
+> Bad: "Hi [first name], I'd love to pick your brain about your industry and the challenges you face. Do you have 30 minutes for a quick chat sometime next week?"
+>
+> Good: "Hi Marcus, saw your r/sysadmin post Tuesday about spending 2 hours every Monday reconciling Datadog alerts across 4 accounts. I'm 20 minutes from launching something for that and want to make sure I'm not building the wrong thing. 20 min so I can ask 5 questions about what you do today? Calendar: [link]"
+
+The bad email could go to anyone in any role at any company. The good email could only go to Marcus. References his specific public post, names the exact painful task, sets a tight ask, drops the calendar link. Reply rate goes from 1-3% on the bad version to 25-35% on the good one.
+
+**The Reddit research comment**
+
+> Bad: "Hey r/SaaS! I'm a founder building a new tool for [generic problem]. Would love some feedback! DM me if interested."
+>
+> Good: "I'm a founder researching [exact problem from a post in this sub last week] - not promoting anything yet, just trying to understand how 10 people who hit this currently solve it. If you're up for a 20-min call this week, my DMs are open / Calendly: [link]. I'll share back the patterns in a follow-up post."
+
+The bad comment gets auto-removed by mods and reads as recruiting traffic. The good comment is a question with a clear ask, offers value back to the sub (the follow-up post), and matches an existing thread the sub already engaged with. The [self-promotion on Reddit rules guide](/blog/self-promote-on-reddit-without-getting-banned-promotion/) covers the karma floor and timing that keep you out of the auto-removed pile.
+
+## What to do after
+
+- **Score responses Wednesday afternoon.** Aim for **25-35% reply rate** by mid-week (same benchmark the well-crafted Day-0 example produces). If you're under 10%, the Day-0 subject line is generic - rewrite it referencing a specific public post and resend Thursday morning.
+- **By Friday, hold 10 booked calls across the next 2 weeks.** Cold outreach should give you 5-7 of them. Paid panel fills the other 3-5. The smoke-test landing page is a signal track, not a booking track.
+- **Move to the Mom Test interview script (Chapter 2.1).** The script tells you what to ask once they're on the call. The wrong questions waste the conversations you just booked. The [Mom Test reference at momtestbook.com](https://www.momtestbook.com/) is the anchor; Chapter 2.1 ships the JT-curated 5-question script.
+
+## What to do tomorrow
+
+Three actions. Block the morning before email.
+
+1. **Write your one-sentence problem hypothesis** in a Notion doc: *"I think [persona] currently does [task] in [painful way] and would pay $X to do it [better way]."* If you can't fill the blanks, the rest of the sequence is premature.
+2. **Open four tabs and read for two hours.** Reddit (Top - Past Month in your two niche subs), LinkedIn (problem-phrase + Past Week), one Discord, and 10 G2/Capterra 2-3 star reviews. Capture 30 verbatim complaint sentences in your doc.
+3. **Open Clay or Apollo and pull 80 to 120 rows** filtered on the six dimensions in Step 2. By tomorrow night you have the list. Tuesday morning the 3-email sequence ships.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/ownership-checklist/cover.png b/content/course/tech-for-non-technical-founders-2026/ownership-checklist/cover.png
new file mode 100644
index 000000000..35279879c
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/ownership-checklist/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/ownership-checklist/index.md b/content/course/tech-for-non-technical-founders-2026/ownership-checklist/index.md
new file mode 100644
index 000000000..2aea5bff4
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/ownership-checklist/index.md
@@ -0,0 +1,181 @@
+---
+title: "GitHub, AWS, Database Ownership Checklist"
+aliases: ["/blog/ownership-checklist/"]
+description: "A 45-minute audit that tells you whether you own your company's code, cloud, and domain - or just rent them from your dev shop. 12 items, run alone."
+date: 2026-05-17
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: ownership-checklist
+keywords:
+  - github ownership audit
+  - aws root account founder
+  - non technical founder ownership
+  - dev shop hostage situation
+  - code ownership checklist
+tags:
+  - founders
+  - non-technical-founder
+  - template
+  - course-companion
+  - oversight
+categories: ["Templates"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/ownership-checklist/"
+related_posts: false
+---
+
+📋 Template companion to [Chapter 4.2](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/) of the [From Idea to First Paying Customer course](/course/tech-for-non-technical-founders-2026/). Where this fits: run after [Ch 4.1](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/) routes you to a path that involves anyone else touching your infrastructure.
+
+> **Routing by M4.1 decision (read this first):**
+>
+> - **Path 1 (Validate without code)**: skip this entirely - no infrastructure to audit yet.
+> - **Path 2 (Self-serve - Lovable + Supabase + Stripe)**: 5-minute confirmation, not a 45-minute audit. Your accounts will be in your own email automatically because you sign up yourself. Skim the 12 items below to confirm, save the checklist, and return in full the day you hire your first contractor or Fractional CTO.
+> - **Path 3 (Fractional CTO bridge)**: run the full 45-minute audit BEFORE you give the FCTO any credential.
+> - **Path 4 (Hire a team)**: run the full audit BEFORE the contractor's first commit. This is the safety net that prevents the hostage situation in the next section.
+
+# The GitHub / AWS / Database Ownership Checklist
+
+A 45-minute audit that tells you whether you own your company's code, cloud, and domain - or just rent them from your dev shop. For Path 2 self-serve founders, this is a 5-minute confirmation; for Path 3 and Path 4 founders, the full 45-minute version.
+
+By the end of one Friday (or the 5 minutes if you're self-serve) you will know whether you can fire your dev team on Monday and still ship a hotfix on Tuesday. You will not have read a line of code. You will have logged into 12 accounts and answered one question for each: is the email on this account mine, or is it theirs?
+
+> **📋 Copy-pasteable audit spreadsheet - copy these 12 rows into Notion or Google Sheets before you start:**
+>
+> | # | Check | Pass? | Actual email/name on file | Recovery needed? |
+> |---|-------|-------|---------------------------|------------------|
+> | 1 | GitHub org owner is you | ☐ | | |
+> | 2 | You can remove every contractor right now | ☐ | | |
+> | 3 | Branch protection: you have admin override on `main` | ☐ | | |
+> | 4 | AWS root account email is on your domain | ☐ | | |
+> | 5 | Your card pays the AWS bill; you can see 12 months of invoices | ☐ | | |
+> | 6 | IAM admin user is yours, MFA on, password in your vault | ☐ | | |
+> | 7 | Production DB password: you can read it tonight without paging anyone | ☐ | | |
+> | 8 | Secrets store admin is you; you can rotate every secret tomorrow | ☐ | | |
+> | 9 | DB backups run nightly; you can restore one to staging by yourself | ☐ | | |
+> | 10 | Domain registrar: WHOIS in your name, your email, your card | ☐ | | |
+> | 11 | DNS provider: you can log in and add an A record right now | ☐ | | |
+> | 12 | Third-party API keys (Stripe, SendGrid, OpenAI, etc.): accounts in your name | ☐ | | |
+>
+> **Scoring:** All 12 ✓ = you own your company. Any ✗ = fix that row before contractor kickoff.
+
+## Why this exists
+
+A B2B fintech founder we picked up in Q1 2026 had spent **$180K over eight months** with the previous agency before they stopped answering email. She thought she owned the company - the Delaware C-corp, the bank account, the trademark. What she did not own was the GitHub org (registered to the agency's CTO), the AWS root account (email was `dev@theiragency.com`), the Stripe production keys, or the domain (in the lead developer's personal Namecheap). Her app was live serving 4,200 paying users when checkout broke at 9pm on a Tuesday and she could not push a fix. Recovery took **three weeks and $11K in legal fees**. The audit below would have caught all four problems on Day 1 in 45 minutes.
+
+Most agencies are not malicious. They set the accounts up under their own emails on Day 1 because it was the fastest way to start, and nobody ever moved them. The damage is the same either way.
+
+## How to use it
+
+Run the audit on a **Friday afternoon, alone**. 45 minutes if your accounts are tidy, 90 if they are not. Bring your company credit card, your password manager, and a fresh Notion doc.
+
+Do not tell the team you are running it. If anything is wrong, you want to fix the access first and have the conversation second. A founder who asks "can you transfer the GitHub org to me?" on Monday gets a different answer than a founder who already owns the org and is asking why she did not on Day 1.
+
+For each item, write the answer in your doc - pass or fail. If fail, copy the exact email or account name. You will need it for the recovery step.
+
+## The 12-item checklist
+
+### Code ownership
+
+| # | Check | What PASS looks like |
+|---|---|---|
+| 1 | **GitHub org owner.** Open the org. Settings - People. Who is listed as Owner? | Your name and email. Not the agency's, not a shared `dev@` mailbox. |
+| 2 | **Repo settings.** Settings - Collaborators. Can you remove every contractor right now without asking permission? | You can. Org-owner permission means you can remove any user. |
+| 3 | **Branch protection on `main`.** Settings - Branches. Is `main` protected, and can you override the protection in an emergency? | `main` is protected, and your account has admin override rights. |
+
+### Cloud ownership
+
+| # | Check | What PASS looks like |
+|---|---|---|
+| 4 | **AWS root account email.** AWS console - top-right - Account. What is the root user email? | Email on a domain you control: `you@yourcompany.com`. |
+| 5 | **Billing access.** AWS Billing dashboard. Whose card pays the bill? Can you see invoices for the last 12 months? | Your card or your company AmEx, and you can download every invoice. |
+| 6 | **IAM admin user.** IAM - Users. Is there an admin user that is yours, separate from root? | Yes, with MFA on, and the password in your password manager. |
+
+### Database and secrets
+
+| # | Check | What PASS looks like |
+|---|---|---|
+| 7 | **Production DB credentials.** Where is the prod DB password stored? Can you read it tonight without paging the lead engineer? | You open AWS Secrets Manager (or 1Password / Vault) and see it yourself. |
+| 8 | **Secrets store ownership.** Secrets Manager, Vault, Doppler, or `.env` files in a private repo - who is the admin? | You are. If a developer rage-quits tonight, you can rotate every secret tomorrow. |
+| 9 | **Database backups.** When was the last successful backup? Can you restore one to a staging DB by yourself? | Backups run nightly, the last 7 days are listed in RDS, and you have a one-page restore runbook. |
+
+### Domain and external services
+
+| # | Check | What PASS looks like |
+|---|---|---|
+| 10 | **Domain registrar.** Log in to Namecheap, GoDaddy, or Cloudflare Registrar. Whose name is on the WHOIS? Whose email gets the renewal notice? | Yours, on your company email. The account is paid by your card. |
+| 11 | **DNS provider.** If DNS lives elsewhere (Cloudflare, Route 53), can you log in and add an A record right now? | Yes, on an account in your name, with MFA. |
+| 12 | **Third-party API keys.** Stripe, SendGrid, OpenAI, Twilio, Plaid - whoever you pay every month. For each, is the account in your name and the billing on your card? | No agency owns an account that touches your customers' money or data. |
+
+If you do not know what an item means, that is part of the result. "I have never heard of Secrets Manager" is a failed answer for #7 - it tells you nobody has briefed you on where production passwords live.
+
+## What good looks like vs. what bad looks like
+
+**#1 - GitHub org owner**
+> Bad: Owner is `agency-admin@bigdevshop.com`. You are listed as a Member.
+> Good: Owner is `founder@mycompany.com` (you). Agency engineers are added as Outside Collaborators.
+
+If the agency's email is on the Owner row, they can delete the org tomorrow morning and GitHub support will not help you.
+
+**#4 - AWS root account email**
+
+| Signal | Root email | Recovery if you lose access |
+|---|---|---|
+| Fail | `aws@bigdevshop.com`, you have IAM only, never logged into root | None - the agency controls it |
+| Pass | `aws@mycompany.com`, password in your 1Password, MFA on your phone with a backup code in your safe | You reset it yourself in five minutes |
+
+The root account owns everything underneath it. If the agency controls the root email, they can lock you out of every AWS service in 10 minutes.
+
+**#7 - Production database password rotation**
+
+The fail looks like one sentence: *"Marcus knows it. I would have to ask him."* The pass looks like one action: you open AWS Secrets Manager right now, read the password, and remember the last time you rotated it (e.g. March, when the previous DBA left).
+
+If only one person can rotate the prod DB password, you do not have a database. You have a hostage.
+
+**#10 - Domain registrar**
+> Bad: Renewals come to `dev@theiragency.com`. You have never logged into the registrar.
+> Good: Logged into Namecheap with your account. WHOIS shows your name. Auto-renew is on, charged to your card.
+
+A domain transfer takes a minimum of **14 days** under ICANN rules and requires the losing registrar to release the auth code. If the agency will not release it, your customers cannot reach your site for two weeks.
+
+## What to do if the audit fails
+
+### Do not panic. Do not tell the team yet.
+
+Most failures are sloppy Day-1 setup, not malice. Frame the ask as "can you help me move this over, doing some housekeeping" - you will get a faster transfer than "why is my company under your name?"
+
+### Recovery order
+
+> **📧 Copy-pasteable recovery email - send to the team if the audit fails (do NOT panic, frame as housekeeping):**
+>
+> Subject: `Quick housekeeping - moving a few accounts to my email`
+>
+> Hi [lead engineer / agency contact],
+>
+> Doing some account housekeeping this week. Can you help me move these over?
+>
+> - [List only the failed items, one per line. Example: "GitHub org owner → founder@mycompany.com"]
+>
+> Should take 5-10 minutes each. Happy to jump on a call if easier.
+>
+> Thanks,
+> [Your name]
+
+- **Code (#1-3):** GitHub org transfer takes five minutes. Slack the lead engineer with your target account email.
+- **Cloud (#4-6):** AWS root email change is self-service if you have the root password. If you do not, AWS support recovers it with your incorporation documents (3-5 business days).
+- **Database and secrets (#7-9):** Set up your own AWS Secrets Manager (or 1Password vault) tonight. Migrate secrets next sprint. Schedule a backup-restore test.
+- **Domain (#10-11):** Initiate the registrar transfer to an account in your name. Get the auth code. Budget 14 days. Do not change DNS during the window.
+- **Third-party services (#12):** Most SaaS tools let you change account email and billing card from the settings page. One at a time, so receipts stay readable.
+
+### When to escalate
+
+If the agency does not transfer the GitHub org within 7 days, the AWS root within 14 days, or the domain auth code at all, retain a lawyer. Negotiate for a month yourself and you usually lose. The legal fee is $2K-$5K. The cost of a stalled checkout is much higher.
+
+If you are in this spot, the [JetThoughts dev shop red flags checklist](/blog/dev-shop-red-flags-checklist/) is the next read - a failed audit usually correlates with three or four other red flags - and the [step-by-step exit guide](/blog/fire-dev-shop-guide/) covers the 30-day transition.
+
+## What to do after
+
+- **Run this audit every quarter.** Twenty minutes once you have done it the first time. Recurring calendar block, last Friday of every quarter.
+- **Add it to your due diligence checklist for the next dev shop.** Before you sign a contract, get it in writing that all GitHub orgs, AWS accounts, domain registrar accounts, secrets stores, and third-party API accounts will be created under your company email from Day 1. Put it in the SOW. The [JetThoughts founder's guide to hiring a dev shop](/blog/founders-guide-hiring-dev-shop/) walks through the clauses worth requesting.
+- **Forward the audit answers to your investor or board the same day.** Three quarterly audits in a row in their inbox is the cheapest investor-trust signal you will ever ship.
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/cover.png b/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/cover.png
new file mode 100644
index 000000000..2bc520dba
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/free-vs-paid-pilot.svg b/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/free-vs-paid-pilot.svg
new file mode 100644
index 000000000..43b4ea483
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/free-vs-paid-pilot.svg
@@ -0,0 +1,50 @@
+
+  Why free pilots ghost and paid pilots convert - the skin-in-the-game gap
+  
+    
+  
+
+  Free pilot vs paid pilot - what skin in the game does
+  Illustrative from 4 JT-rescue founders who ran both motions in 2026. Your numbers will vary.
+
+  
+  
+  FREE PILOT
+  12%
+  convert to paying
+  Customer never had to defend the spend.
+  "This is great" emails on Friday,
+  ghost on conversion in week 8.
+  Average pilot length: 6-8 weeks.
+  Average founder hours: 25-40.
+  Average revenue: $0.
+  "It is great. Let me circle back next quarter."
+
+  
+  
+  PAID PILOT ($500-$6K deposit)
+  65%
+  convert to paying
+  Customer defended the spend internally.
+  CFO or boss already approved.
+  Conversion is paperwork, not a new decision.
+  Average pilot length: 6-8 weeks.
+  Average founder hours: 25-40.
+  Average revenue: $500-$6K + annual.
+  "Ship the year-one invoice next week."
+
+  
+  
+  Same product. Same customer. Same eight weeks. The deposit is the variable.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/index.md b/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/index.md
new file mode 100644
index 000000000..0a89c66e2
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/index.md
@@ -0,0 +1,330 @@
+---
+title: "5.4 · Charge Before You Ship: The Paid Pilot Contract"
+aliases: ["/blog/paid-pilot-charge-before-ship/"]
+description: "A verbal yes is not a paid pilot. A refundable Stripe deposit signed before kickoff is. The one-page Design Partner Agreement and a Stripe Checkout setup."
+date: 2026-05-13
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: paid-pilot-charge-before-ship
+keywords:
+  - paid pilot contract founder
+  - design partner agreement template
+  - charge for pilot saas
+  - stripe checkout rails django
+  - first paying customer deposit
+tags:
+  - founders
+  - non-technical-founder
+  - first-paying-customer
+  - sales
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "5.4 · Charge Before You Ship: The Paid Pilot Contract"
+  og_description: "A verbal yes is not a paid pilot. A refundable Stripe deposit signed before kickoff is. The one-page Design Partner Agreement and a Stripe Checkout setup."
+cover_image_alt: "JetThoughts blog cover showing a one-page Design Partner Agreement with the deposit clause highlighted"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/"
+related_posts: false
+---
+
+> **Module 5 · Step 4 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** 3-5 warm leads from [Chapter 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/)
+>
+> **Output:** 1 signed paid pilot before any new code ships
+
+> **TL;DR:** A verbal yes is not a paid pilot. A signed DPA (Design Partner Agreement - a one-page co-design pilot contract) with a refundable Stripe deposit is. Charge 10-30% of year-one ACV (annual contract value - what one customer pays in year one) before kickoff - it puts the CFO question on Week 0 instead of Week 8.
+
+Two pilots, same product, same buyer profile, different deposit timing:
+
+| Variant | Setup | Result at Week 8 |
+|---|---|---|
+| **Free pilot** | Six weeks of free build, customer "loves it," 47 enthusiastic Slack messages, year-one contract sent on day pilot ended | "We're going to revisit at the next budget cycle." There is no next budget cycle. |
+| **Paid pilot** | One-page Design Partner Agreement, $1,200 refundable deposit collected before any code ships | Year-one contract closes day one. |
+
+The playbook below is the second variant: a one-page Design Partner Agreement, a 15-minute Stripe Checkout setup, and the pricing math that puts you in the conversation instead of stuck waiting for a CFO who never approved the pilot.
+
+## Why free pilots almost never convert
+
+Free pilots feel collaborative because the customer says yes, you build for six weeks, and the team shows up to the Friday demo each week and says "this is great."
+
+Week 8 lands and you send the proposal for the year-one contract. The customer says "this is great, let me circle back to my CFO" - and that CFO has never heard of you, did not approve the pilot, and has no internal justification for the line item. The conversation dies in a forwarded email thread.
+
+That's the recurring mechanic. A 20% deposit at kickoff puts the CFO question on Week 0, when there's no project yet for the customer to defend. Conversion in Week 7 becomes paperwork, not negotiation. Skip the deposit and you're back at the Week 8 wall: "this is great" emails Friday, ghost on conversion Monday.
+
+First-time founders often default to "let the customer try it free and they'll pay once they see the value" - that instinct produces six months of free pilots and zero signed contracts. Charging first is what flips a curious user into a customer with skin in the game.
+
+You are not asking for money. You are asking the customer to defend the spend internally. The defense is the test of whether the pilot is real.
+
+![Free pilot vs paid pilot - what skin in the game does](free-vs-paid-pilot.svg)
+
+> **Course terminology: "first paying customer" = signed DPA + cleared deposit.** Year-one contract conversion is a downstream milestone covered in the "Going further" callouts after Module 5 closes. When the course says "first paying customer," it means the customer has signed the one-page DPA AND the Stripe deposit has cleared - real money in your account. A year-one-converted customer is a separate event that happens 6-10 weeks later, after the pilot success criteria are met or missed.
+
+## The Design Partner Agreement, in one page
+
+The Design Partner Agreement (DPA) is a one-page LOI (letter of intent - a short agreement that comes before a full contract) that names the customer as a design partner, defines the pilot scope, sets the deposit, and converts to year-one on success. It is mutual-edit, in plain English, and v1 does not need a lawyer. The reason it stays short: every line in the document is a load-bearing clause, and every line that would not load-bear is removed.
+
+The structure has six sections plus signatures.
+
+| # | Section | What goes in it |
+|---|---------|-----------------|
+| 1 | Scope of pilot | 3 outcomes the customer wants. 2 specific use cases. Anything outside is out of scope. |
+| 2 | Duration + dates | 6-8 weeks. Start date. End date. Weekly Friday demo at a named time. |
+| 3 | **Pilot fee + deposit** (load-bearing) | 10-30% of year-one ACV (annual contract value - what one customer pays in a year). Paid via Stripe before kickoff. Credited toward year-one on conversion. |
+| 4 | Success criteria | 3 measurable outcomes - hours saved, errors avoided, revenue produced. Friday-demo verified. |
+| 5 | Conversion terms | Year-one price. Annual or monthly. Auto-conversion or opt-in. Notice period. |
+| 6 | Data, IP, termination | Customer keeps their data. You keep the product IP. 30-day written notice to exit. |
+|  | Signature block | DocuSign, HelloSign, or PDF + email confirmation - whichever the customer prefers. |
+
+Total document: one page, around 400 words. v1 needs no lawyer review.
+
+A few clauses deserve more detail than the table can hold.
+
+The **scope of pilot** section is where new founders over-spec. Keep it to three outcomes the customer wants and two specific use cases; anything outside that list stays out of scope until conversion. The list also anchors the Friday demos - if a demo does not advance one of the three outcomes, the demo is off-scope and you say so. Friday cadence comes from the [Friday demo chapter](/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/).
+
+The **pilot fee and deposit** clause is what makes everything else work. The deposit lands at 10-30% of projected year-one annual contract value (ACV), paid via Stripe before pilot kickoff and credited dollar-for-dollar against the year-one invoice on conversion. If the customer cancels before week 4, they forfeit the deposit (their commitment). If the founder cancels for any reason, the founder refunds 100% (your commitment). Pricing math is below.
+
+The **success criteria** clause is what makes the DPA a real contract instead of a handshake. Pick three measurable outcomes the pilot is supposed to produce (for example, hours saved per week, errors avoided per month, or revenue lifted per quarter), worded in the customer's verbatim language from the [Chapter 5.3 outreach](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/).
+
+If two of three are hit by week 6, the year-one contract auto-converts unless the customer opts out in writing. If fewer than two are hit, both parties walk and the founder retains the deposit as paid consideration for the pilot work.
+
+The **conversion terms** clause is what the CFO actually approves in week 0. State the year-one price in dollars (never "TBD"), billing cadence (annual or monthly), auto-conversion versus opt-in (auto-conversion recommended), and a 30-day notice period after year one. These numbers are why the deposit can be defended internally before kickoff.
+
+**Data, IP, and termination** is the shortest section: customer keeps their data, founder keeps the product IP, either party can exit at 30 days written notice during the pilot, and the customer's data stays exportable for 90 days after termination. v1 needs no further detail.
+
+Signature block at the bottom - DocuSign, HelloSign, or PDF-and-email-confirmation, whichever the customer prefers.
+
+### Copy-paste DPA template {#dpa-template}
+
+Verbatim - fill the brackets, send.
+
+Open a Google Doc. Paste the block below. Replace every `[BRACKETED]` value with your numbers. Total document: one page, ~400 words. No lawyer review needed for v1.
+
+```text
+DESIGN PARTNER AGREEMENT
+
+Between: [Your Company Name] ("Company") and [Customer Company Name] ("Design Partner")
+Date: [YYYY-MM-DD]
+
+1. SCOPE OF PILOT
+The Company will deliver the following outcomes during the pilot period:
+  1. [Outcome 1 - measurable, e.g. "Reduce weekly report prep from 3 hours to 30 minutes"]
+  2. [Outcome 2]
+  3. [Outcome 3]
+Specific use cases covered: [Use case 1], [Use case 2].
+Anything outside this list is out of scope until year-one conversion.
+
+2. DURATION + DATES
+Start date: [YYYY-MM-DD]
+End date: [YYYY-MM-DD] (6-8 weeks)
+Weekly Friday demo at [time] [timezone]. 15 minutes. Loom or live screenshare.
+
+3. PILOT FEE + DEPOSIT
+One-time deposit: $[500-6,000] (10-30% of year-one ACV).
+Paid via Stripe before pilot kickoff. Credited dollar-for-dollar toward year-one invoice on conversion.
+If Design Partner cancels before week 4: deposit forfeited.
+If Company cancels for any reason: 100% refund within 14 days.
+
+4. SUCCESS CRITERIA
+The pilot is successful if 2 of 3 criteria are met by [end date]:
+  1. [Measurable criterion 1 - e.g. "Report prep time reduced to <=30 min/week, verified in Friday demo"]
+  2. [Measurable criterion 2]
+  3. [Measurable criterion 3]
+If 2+ criteria met: year-one contract auto-converts unless Design Partner opts out in writing within 7 days.
+If <2 criteria met: both parties walk. Company retains deposit as paid consideration for pilot work.
+
+5. CONVERSION TERMS
+Year-one price: $[amount] / [month or year]
+Billing: [monthly / annual]
+Conversion: auto-convert at pilot end unless Design Partner opts out in writing.
+Post year-one: 30-day written notice to cancel.
+
+6. DATA, IP, TERMINATION
+Design Partner keeps their data. Company keeps the product IP.
+Either party may exit at 30 days written notice during pilot.
+Design Partner's data remains exportable for 90 days after termination.
+
+SIGNED:
+
+_________________________  Date: __________
+[Your Name], [Your Company]
+
+_________________________  Date: __________
+[Champion Name], [Customer Company]
+```
+
+Two annotated worked examples (a $1,500 B2B SaaS pilot and a $5,000 B2B services pilot) plus DocuSign-importable + PDF formats are in [The First-Paying-Customer Operating Kit](/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/) - email-gated reference for the same template with sector-specific fills.
+
+> **What happens AFTER the deposit clears (the pilot is not the contract).** The signed DPA + cleared deposit kicks off a 6-8 week working relationship. Three things happen each Friday:
+>
+> 1. **Demo the one workflow** from the DPA Section 1 scope - the customer watches you click through it, no slides.
+> 2. **Read the success criteria aloud** (DPA Section 4) and ask "are we on track for X by week 6?" - the customer either says yes, says no, or names a blocker.
+> 3. **Write down what is NOT working** in shared Slack or email by Friday 5pm - if you skip this, week-3 frustrations turn into week-6 surprises.
+>
+> Two failure modes to watch: the customer goes quiet by week 4 (re-engage with a written status email naming all 3 success criteria), or the success criteria turn out to be wrong (rewrite them with the customer in week 3, do not wait for week 6). The full Friday-demo discipline is in [The Friday Demo Rule chapter](/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/) - read that BEFORE the first Friday call.
+
+## The pricing math
+
+> **From Ch 1.3 smoke-test price to year-one ACV.** Take the monthly price you tested in [Chapter 1.3](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/) and multiply by 12 (or your actual billing period). Example: a $97/month hypothesis → $1,164 year-one ACV. Take 10-30% of that as your deposit floor; the band table below tells you which percentage to pick by sector. If your number lands between two bands or you are unsure which to pick, **pick the midpoint of the smallest applicable band** until your customer's CFO pushes back. The deposit is a commitment device; below the floor it stops working as one. Above the band the customer needs procurement, which lengthens the timeline.
+
+The deposit number is not arbitrary. It is anchored to projected year-one ACV and to what a typical CFO will sign without a procurement review. The bands by sector:
+
+> For Sam's first pilot, the per-seat / 5-10 seats row applies. Skip the mid-market row until you have 5+ customers.
+
+| Sector | Year-1 ACV | Pilot fee (10-30%) | Pilot fee notes |
+|---|---|---|---|
+| B2B SaaS (per-seat, 5-10 seats) | $5K-$12K | $500-$3K | The CFO approves the deposit on email. No procurement involved. |
+| B2B SaaS (mid-market, 50-200 seats) | $20K-$80K | $2K-$24K | Above $10K, expect a 1-week procurement review. Plan for it. |
+| B2B Services / consultancy | $10K-$40K | $1K-$6K | Service deposit is normal in the sector. Customer expects to pay. |
+| Rescue-rebuild engagement (founder inherited a broken codebase from a prior agency) | $15K-$60K | $1.5K-$6K | Founders in this band are rebuilding rather than greenfield - the deposit anchors what they are buying back, not what they are exploring. |
+
+### The minimum: $500
+
+Below $500, the deposit does not work as a commitment device - the customer can write it off as a Friday-impulse purchase and ghost the same way they would on a free pilot. The point of the deposit is that it lives in next month's accounting cycle, which means it gets justified.
+
+> **When 10% of year-one ACV is below $300:** the $500 floor stops working as a commitment device for low-ACV B2B SaaS. In that case, charge the **first month's revenue upfront as the deposit** instead. Example: a $97/mo hypothesis → $97 month-1 upfront, credited toward the year-one contract on conversion. For a $29/mo hypothesis the upfront is the first quarter ($87) for the same reason. The structural rule (deposit must be enough to require a CFO check, not a personal credit card) only works when the absolute number triggers internal-approval friction; for low-ACV B2B that threshold is the first month or quarter, not a multiple of monthly price.
+
+### The maximum without procurement review: typically $10K
+
+Above $10K, even at small companies, finance starts asking questions. If your pilot fee is $10K+, expect a 1-2 week procurement window between handshake and signature, and price the timeline into the conversation - the deposit clears in week 2, not week 0.
+
+### Always credit toward year-one
+
+The pilot fee is not separate revenue. It is "year-one ACV, pre-paid." The customer's CFO is approving year-one revenue brought forward, not a discretionary line item. Naming it correctly changes the conversation entirely.
+
+## The Stripe Checkout setup (15 minutes, no engineer)
+
+You will spend more time renaming the Stripe product than building the payment page. Stripe Checkout is hosted - you do not build a payment form, you just generate a checkout URL and email it to your customer.
+
+The five-minute path:
+
+1. Create or sign in to your Stripe account. [stripe.com/login](https://dashboard.stripe.com/login)
+2. Go to Products. Create a new product called "[Your Product Name] - Design Partner Pilot".
+3. Add a one-time price for the deposit amount ($500, $2K, $6K, whatever your math).
+4. Hit "Payment link" on the product detail page. Stripe generates a hosted checkout URL.
+5. Paste the URL into your DPA email. Customer clicks, pays card or ACH, you get the Stripe notification.
+
+That is the entire setup. No webhook, no Rails controller, no Django view, no Laravel route. If you want to log paid pilots into your existing app, you can - but you do not have to. The CSV export from Stripe is enough for a Module 5 first-pilot motion.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+sequenceDiagram
+    participant Founder
+    participant Stripe
+    participant Customer
+    participant Email
+    Founder->>Stripe: Create product + price ($500-$6K)
+    Stripe->>Founder: Payment link URL
+    Founder->>Email: Send DPA + Stripe link
+    Email->>Customer: Receives PDF + payment URL
+    Customer->>Stripe: Clicks link, pays card/ACH
+    Stripe->>Founder: Payment notification
+    Founder->>Customer: Pilot kickoff scheduled
+```
+
+If you do want to wire the payment into a Rails app for record-keeping later, the Stripe Ruby gem (`gem 'stripe'`) takes a `Stripe::Checkout::Session.create` call to generate the same URL programmatically. Django uses `stripe.checkout.Session.create` via the `stripe-python` package. Laravel uses `Stripe\Checkout\Session::create()` from `stripe/stripe-php`. All three produce the same hosted URL. Do not build this until after your first paid pilot ships.
+
+## The conversation script
+
+You have a warm lead from [Chapter 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/) who booked a 20-minute demo, the demo went well, and they said something close to "yes, I would love to try this with my team." The default first-time-founder move is to soften here. The 15-second script that does not soften:
+
+> "Glad it resonates. Quick word on how I am setting up pilots - I am running them as paid design partnerships, so the customer has skin in the game and I have a real signal. The deposit is [$500-$6K], credited toward year one on conversion. Refunded in full if I cannot deliver on the success criteria. Want me to send the one-pager?"
+
+| Customer response | What it means | Next action |
+|---|---|---|
+| **"Send the one-pager"** | Close to a paid pilot. Window is open today. | Send inside the hour. DPA + payment link. |
+| **"Can we start free and convert later?"** | Still hedging. Deposit scares them but they're interested. | Reframe: deposit is *year-one ACV prepaid*, not added cost. Clarify: $500 sits in this month's accounting, gains CFO approval. Free pilots lose approval in week 8. |
+| **"Let me think about it"** | Not ready this week. Warm lead turning cold. | Check back once. If no callback, move to next prospect. Hedge → delay → ghost is the pattern. |
+| **"We do not do paid pilots"** | Not in your must-have segment. Wrong buyer profile. | Thank them. Move on. They're not disqualified; they're not your customer yet. |
+
+### Advanced objections (after customer #5)
+
+The five responses below show up once you start talking to enterprise buyers or repeat prospects. For the first 4-5 pilots, the basic-objection table above covers what you will hear. These render as expandable rows so each long answer doesn't overflow on mobile.
+
+**"Can we do it at $300 instead of $1,200?"**
+
+*Means:* Interested but anchoring price down. The deposit IS the commitment device; lowering it kills the function.
+
+*Say back:* "The $1,200 number is what makes this a year-one commitment, not a trial. If we drop to $300 I am back to charging you a one-time consult fee, which is not what either of us wants. Same price, but I can move the kickoff later or split into two tranches if that helps internal approval." Hold the price. Offer flexibility on timing, not amount.
+
+**"Can you do net-30 instead of upfront?"**
+
+*Means:* Common ask from enterprise buyers; the deposit-before-kickoff rule loses its commitment function on net-30.
+
+*Say back:* "The deposit is structured upfront on purpose - it is the signal that this is a real pilot, not a sales call. I can offer net-15 from invoice date, but the kickoff timer starts when the deposit clears. If net-30 is a hard requirement on your end, the alternative is a paid PoC with a smaller scope I can deliver before invoicing for the full pilot."
+
+**"My legal team needs to review any contract."**
+
+*Means:* Standard B2B response; the one-page DPA is usually under their threshold.
+
+*Say back:* "The DPA is a one-page mutual document, not a long contract. Send it to your legal contact today; if they want changes I will turn them within 48 hours. Most legal teams approve a one-page DPA in 2-3 business days. While we wait I can send you the kickoff prep doc so we can start immediately when legal clears."
+
+**"What if you cannot deliver by week 6?"**
+
+*Means:* Testing your refund promise without saying so directly.
+
+*Say back:* "If I do not hit two of the three success criteria you and I write into the DPA, you get a 100% refund within 14 days and we walk - no negotiation. The DPA names this in section 5. Want me to walk you through how the success criteria get written so you are comfortable they are measurable?"
+
+**"Can I get exclusivity in my vertical?"**
+
+*Means:* Their commitment is real but they want defensible value.
+
+*Say back:* "I cannot offer category exclusivity at the pilot stage - I do not have enough signal yet to know what the right exclusivity term looks like. What I can do: write into the DPA that you are my first paying customer in [vertical], and that we will revisit category exclusivity at year-one renewal once we both know whether this is working. That gives you the chronology advantage without locking me in before I have learned what to lock to."
+
+## When founders should not insist on a paid pilot
+
+The paid pilot is the default, but it has three honest exceptions.
+
+| Exception | When it applies | Substitute approach |
+|---|---|---|
+| **Champion conversion** | A champion from Chapter 5.3 offers free pilot + co-marketing case study + Loom testimonial. Trade: your work now for their case study + testimonial (your conversion assets for the next 10 customers). | Limit to 1-2 champions out of first 10 pilots. Only when case study is contractually committed. Case study must ship within 60 days. |
+| **True early-MVP (30% built)** | Your MVP is genuinely unfinished. Paid pilot misrepresents what you can deliver in 6-8 weeks. | Run free pilot honestly, ship to the agreed scope, turn second customer into the paid pilot. The honesty signal is commitment of a different kind. |
+| **Pre-investment-grade product** | Your product is 12 months from differentiability. Customer is buying relationship, not product. | Follow the Paul Graham ["Do Things That Don't Scale"](http://paulgraham.com/ds.html) Stripe Collison playbook. Paid pilot returns once product is actually doing the job. |
+
+## What to do next
+
+| Step | Action | Output |
+|---|---|---|
+| **1** | Copy the [DPA template above](#dpa-template) into a Google Doc, fill the 6 bracketed sections, pick deposit number from the sector table above, set up Stripe product + payment link. Optional: the [First-Paying-Customer Operating Kit](/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/) has annotated worked examples + DocuSign-importable format. | Stripe link ready. DPA drafted. Deposit amount locked. |
+| **2** | Send the DPA + Stripe link to 1-2 warm leads from Chapter 5.3 who booked demos recently. | 1-2 DPA emails sent. Expect 1 procurement question + 1 ready-to-sign. |
+| **3** | Bank your first deposit. Schedule pilot kickoff and the first Friday demo cadence. | Deposit cleared. Kickoff scheduled. Pilot officially started. |
+
+**If you do not have warm demos yet**, your work is still in [Chapter 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/). The DPA is the wrong sprint for an empty pipeline.
+
+## Advanced (optional sidebar)
+
+Once you have closed 2-3 paid pilots and want to layer on contract rigor, read the [Common Paper Design Partner Agreement template](https://commonpaper.com/standards/design-partner-agreement/) (a vetted v2 LOI used by hundreds of YC companies), [SaaStr's "Should we charge for pilots"](https://www.saastr.com/should-you-charge-for-a-pilot/) (Jason Lemkin's thirty-second answer is yes, always), and Ash Rust's ["Startup Sales: How to Get Pilot Customers to Pay"](https://medium.com/sharp-spear/startup-sales-how-to-get-pilot-customers-to-pay-7a9b7a48eedf) for the conversation tactics. The one-page DPA in this chapter is enough through your first 10 pilots. The advanced versions matter once you start hearing the words "procurement" and "MSA" in pilot conversations.
+
+A 20% deposit at kickoff puts the CFO question on Week 0. Conversion in Week 7 becomes paperwork, not negotiation.
+
+---
+
+## Further reading
+
+- Common Paper, [Design Partner Agreement template](https://commonpaper.com/standards/design-partner-agreement/) - a vetted, modern LOI used by hundreds of YC companies. The companion to your one-pager when conversations move toward MSAs.
+- SaaStr, [Should you charge for a pilot?](https://www.saastr.com/should-you-charge-for-a-pilot/) - Jason Lemkin's case for charging and the conversion-rate data behind the recommendation.
+- Ash Rust, [Startup Sales: How to Get Pilot Customers to Pay](https://medium.com/sharp-spear/startup-sales-how-to-get-pilot-customers-to-pay-7a9b7a48eedf) - tactical conversation script and pricing-band data from a former Sequoia-backed founder.
+- Steve Blank, [The Four Steps to the Epiphany](https://steveblank.com/2010/01/06/the-four-steps-to-the-epiphany/) - the foundational text on Customer Validation; Blank argues paid pilots are how you separate real demand from polite enthusiasm.
+- Stripe, [Payment Links documentation](https://stripe.com/docs/payment-links) - the official Stripe Checkout setup. 15-minute integration with no engineering work required.
+- Lenny Rachitsky, [How to win your first 10 B2B customers](https://www.lennysnewsletter.com/p/how-to-win-your-first-10-b2b-customers) - the 7-step playbook including the design-partner pricing model from B2B founders.
+
+> **Done when:** One DPA is signed and the Stripe deposit has cleared in your account.
+> **Founder OS · Artifact #6 of 6:** A signed Design Partner Agreement + cleared deposit. Save the executed PDF + Stripe receipt in your `Founder OS` folder. This is the artifact investors fund; you can now point to it and say "someone who doesn't know me paid real money for this."
+>
+> **Next click:** [5.5 · Going Outbound Without a Sales Team](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/)
+>
+> **If blocked:** If the customer says "can we start free and convert later," reframe: the deposit is year-one ACV prepaid, not added cost. If they still say no, they are not in your must-have segment - move to the next lead.
+
+> **Stuck? Most first-timers stall here:** asking for money from someone you know, even as a refundable deposit. **Fix:** the deposit is a test of whether the problem is real - not a test of whether you deserve to be paid. If they value the solved problem less than the deposit, their problem isn't acute enough. Send the DPA to your warmest lead first. The second one is easier.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Signs a Design Partner Agreement with 3 accounting firms. Deposit: $2,500 each (refundable if product doesn't ship within 90 days). 2 of 3 sign and pay within 48 hours. Revenue: $5,000 in committed deposits.
+>
+> **Mia**: Signs a Design Partner Agreement with 4 parents. Deposit: $50 each (refundable) - B2C marketplace convention: deposit equals roughly 2× the monthly fee ($25/mo tutoring × 2). The $500 floor in the body above is the B2B SaaS convention; consumer marketplaces work to smaller absolute numbers because the buyer signs without a CFO. 4 of 4 sign and pay. Revenue: $200. Lower deposit, higher volume - consumer math.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/cover.png b/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/cover.png
new file mode 100644
index 000000000..3f725b3d1
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/index.md b/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/index.md
new file mode 100644
index 000000000..fb9152cfc
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/index.md
@@ -0,0 +1,176 @@
+---
+title: "Pivot or Persevere: The Decision Framework"
+aliases: ["/blog/pivot-or-persevere-decision-framework/"]
+description: "Six pivot types, trigger conditions for each, and what to keep when you pivot. The chapter that turns the course from a one-way escalator into a discovery loop."
+date: 2026-05-14
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: pivot-or-persevere-decision-framework
+keywords:
+  - when to pivot startup
+  - lean startup pivot framework
+  - customer development pivot
+  - pivot vs persevere decision
+  - founder pivot signal
+tags:
+  - founders
+  - non-technical-founder
+  - first-paying-customer
+  - course-companion
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "7.6 · Pivot or Persevere: The Decision Framework"
+  og_description: "Six pivot types, trigger conditions for each, and what to keep when you pivot. The chapter that turns the course from a one-way escalator into a discovery loop."
+cover_image_alt: "JetThoughts course cover showing 6 pivot arrows branching from a center node"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/"
+related_posts: false
+---
+
+> **Going further · Continuation chapter 6 of 6** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a churn-triage decision (chapter 7.5) OR a Sean Ellis 40% test result (chapter 7.1)
+>
+> **Output:** a pivot decision with the 6-type framework + a written list of what you keep vs what you change
+
+## The Course Is a Loop, Not an Escalator
+
+A founder I rode shotgun with last quarter - a fintech founder named D. - hit chapter 7.4 with a cold-outbound conversion rate of 0.6%. He had sent 287 personal emails to CFOs of 50-200-person companies over 14 days, with 11 replies and 0 paid pilots. His instinct, the same instinct every founder gets here, was to push forward into salvage-or-rebuild territory and start managing the build harder.
+
+That was the wrong move. The right move was backwards. The 0.6% conversion rate was telling him the messaging he had built off his [Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) sentence was not landing on the segment he had picked. Three things could be wrong: the customer (segment), the need (problem), or the channel (outbound vs PLG). Pushing forward into rebuild mode would have made him a better operator of a misaligned hypothesis. Going back to [Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) with a pivot decision made him a better founder.
+
+The course you have been reading was structured as a numbered sequence because that is the cleanest way to learn the moves. But the actual job is a loop. A founder writes a hypothesis, smoke-tests it, talks to customers, builds an MVP, lands paying customers, and at any point can hit a signal that sends them back to [Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) with a new hypothesis. The courses that pretend the journey is one-way escalator produce founders who think pivoting is failure. It is not. Pivoting is the discovery loop working correctly.
+
+This chapter teaches you when to go back vs when to push forward. It is the chapter that turns the rest of the course from a checklist into a system.
+
+## The Six Pivot Types
+
+Eric Ries catalogued ten pivot types in *The Lean Startup*; Steve Blank built on them with the customer-development variants. Six of those ten cover 90% of what a non-technical founder will face in 2026. The other four are scope and platform pivots that show up later, when you are managing a product team. Below are the six in plain English, with one trigger sentence and one example each.
+
+![The 6-pivot wheel - center hypothesis with 6 spokes labeled by pivot type and trigger](pivot-wheel.svg)
+
+### 1. Customer Segment pivot
+
+*Right product, wrong customer.* You shipped a tool that works, but the audience you targeted is not the audience that gets value from it. The signal usually comes from a churn-triage cohort slice (chapter 7.5) where one segment retains at 50%+ and others languish under 20%. Example: R. from the churn-triage chapter shipped a workflow tool to solo founders that turned out to be a 3-person-team tool. Same product, different audience.
+
+### 2. Customer Need pivot
+
+*Right customer, wrong problem.* The audience you targeted is correct, but the job you built for is not their highest-priority job. The signal usually comes from [customer interviews](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) where multiple customers describe a different pain than the one your product solves. Example: a HealthTech founder targeting solo dental practices initially built around appointment scheduling; six interviews in, every dentist named insurance-claim resubmission as the bigger pain. The audience was right; the need was not.
+
+### 3. Solution pivot
+
+*Right problem, wrong solution.* You picked a real problem for the right customer, but the product you built does not actually relieve it. The signal comes from the [Sean Ellis 40% test](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/) returning under 25% across all segments uniformly. Example: a productivity founder built a Slack integration to manage standup notes; users came for the right reason (hated standup overhead) but the integration created more notification noise than it removed. Same problem; different solution shape (a quiet email digest at 9 AM, not a real-time bot).
+
+### 4. Technology pivot
+
+*Right solution, wrong tech stack.* The shape of the solution is right but the platform you built it on cannot reach the price or performance the customer needs. Less common for non-technical founders because most ship on Lovable, Bubble, or with a hired team and the tech is opaque. Becomes relevant when you outgrow a no-code ceiling. Example: a B2C founder hit 4,000 MAU on Bubble and discovered the per-row pricing model would cost $11K/month at 20K MAU; the rebuild on a native stack made the unit economics work.
+
+### 5. Channel pivot
+
+*Right product, wrong distribution.* The product is right, the audience is right, but the way you reach them does not work. The signal usually comes from cold-outbound under 1% conversion or paid ads producing zero qualified pilots. Example: the fintech founder D. above. The product was right (CFO-grade close-the-books tool), the segment was right (50-200-person companies), but cold email could not break through to a CFO's inbox. Channel pivot was to a partner-led motion through fractional CFO networks; conversion went to 4.2% in 30 days.
+
+### 6. Revenue Model pivot
+
+*Right product, wrong pricing.* The product works and the audience pays, but the pricing shape (per seat, per event, flat tier, freemium) does not match how customers value or budget for the product. The signal comes from active customers churning at the renewal date with feedback that points at price, not the product. Example: a B2B SaaS priced at $200/seat/month for 10-seat teams; customers loved it but balked at the renewal because they only needed 3 power users. Pivot was to $400/month flat for unlimited seats with feature gates by usage tier. ARPU dropped 20% per customer; net revenue retention jumped to 118%.
+
+The skill is not memorizing the six types. The skill is asking which of the five Mad Libs blanks (customer, problem, approach, competition, differentiation) is wrong, and matching it to the pivot type that addresses that blank.
+
+## Trigger Conditions: What Tells You to Pivot
+
+The common pattern is not pivoting too early. It's pivoting too late - watching the cohort numbers, the conversion rates, the ad spend, and the CAC numbers all degrade for two quarters before admitting the signal is real. The trigger conditions below are the numerical thresholds that should override the "let me try one more thing" instinct.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    Start[Pivot trigger detected] --> A{Sean Ellis 40% test}
+    A -->|Under 25% overall
uniform across segments| P3[Solution pivot
or Customer Need pivot]
+    A -->|Under 40% overall
one segment over 50%| P1[Customer Segment pivot]
+    A -->|Above 40%| B{Cohort retention 30-day}
+    B -->|All segments under 25%| P3b[Solution pivot]
+    B -->|Above 40% in one segment| C{CAC vs LTV ratio}
+    C -->|CAC over 3x LTV
customers love product| P6[Revenue Model pivot]
+    C -->|CAC sustainable| D{Outbound conversion}
+    D -->|Under 1% after 60 messages| P5[Channel pivot]
+    D -->|Above 2% in one channel| E{Tech ceiling hit?}
+    E -->|Yes - cost or performance| P4[Technology pivot]
+    E -->|No| Persevere[PERSEVERE
You have signal]
+
+    classDef redbox fill:#fff5f5,stroke:#cc342d,stroke-width:2px;
+    classDef purplebox fill:#fbe9ff,stroke:#a855f7,stroke-width:2px;
+    classDef goodbox fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px;
+    class P3,P3b,P1,P6,P5,P4 redbox
+    class Persevere goodbox
+```
+
+**Sean Ellis 40% under 25% across all segments** triggers a Solution pivot or a Customer Need pivot. Founders typically react by trying harder on the same product - more features, better onboarding, more polish. The right move is to ask whether the solution shape itself is wrong, or whether you targeted the wrong job.
+
+**Cohort retention under 30% with churn-triage Decision 3** triggers a Solution pivot. The cohort floor from chapter 7.5 already told you no segment retains. The pivot framework tells you the most likely culprit is solution shape, not audience.
+
+**CAC > 3x LTV with paying customers who love the product** triggers a Revenue Model pivot. Founders typically react by trying to push CAC down (better ads, better landing pages). When the customers who do convert love the product, the issue is almost always pricing model, not acquisition cost.
+
+**Outbound conversion under 1% after 60 personal messages** triggers a Channel pivot. Founders typically react by writing better email copy. After 60 messages with thoughtful copy, the channel itself is the bottleneck. Most B2B products that fail outbound do well via partnerships, communities, or content; most B2C products that fail Meta Ads do well via influencers or organic social.
+
+**Tech-stack cost or performance ceiling** triggers a Technology pivot. Founders typically react by ignoring the ceiling for too long because rebuilding feels expensive. The cost of a 6-week rebuild is almost always less than the cost of running on a stack that triples every quarter at scale.
+
+The right rule is simple: when two consecutive months show the same trigger condition, the next decision is a pivot type, not a "try harder." The flail response is to try harder for two more quarters; the pivot response is to ship a new hypothesis test in two weeks.
+
+## What You Keep When You Pivot
+
+A pivot is not a restart. The founders who treat pivots as restarts are the ones who burn the most runway because they throw away the evidence they already paid to collect. The discipline that distinguishes a real pivot from a flailing reboot is the pivot ledger - a written list of every artifact you have built so far and whether it survives the pivot.
+
+![The pivot ledger - a 4-column table showing what you keep and what you replace](pivot-ledger.svg)
+
+The ledger above is the template. Print it (or copy it to a Notion doc) before you declare the pivot. Walk every row. The evidence you keep includes: the validated problem statements that survived the interviews (or the disconfirmed ones - both are evidence), the customer relationships from your [First Ten Come From Your Network](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/) outreach (50 names with verified contact details and one conversation each is the most valuable B2B asset you own at this stage), the cohort retention numbers you collected for the chapter 7.5 churn triage, and your domain expertise as the founder. The hypothesis sentence, the landing page copy, and the ad creative get rewritten. The MVP code depends - the auth and billing layers usually survive; the core workflow gets rebuilt around the new hypothesis.
+
+A second founder we rode shotgun with - Anika, running a vertical SaaS for clinical-trial coordinators - ran the ledger move on a Monday afternoon. She kept her 287-person coordinator contact list (Customer Need pivot meant the segment was still right). She kept four of her eleven validated problem statements from her [Mom Test interviews](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) (the ones about consent-form reconciliation, not the ones about scheduling). She kept her Stripe integration and her auth flow from the Lovable build. She rewrote her hypothesis sentence around consent-form reconciliation. She rewrote her landing page headline. She kept her pricing model intact ($240/month per seat). Two weeks later she had a smoke-test landing page live, an outreach script aimed at the same 287 contacts with the new pitch, and four warm meetings booked. The pivot took 14 days because she kept everything that survived.
+
+The trade-off worth naming: keeping too much makes a pivot feel like a renaming. The discipline is to be honest about which artifacts genuinely transfer and which ones are sunk cost. If your ledger says everything survives, you have not actually pivoted - you have rebranded. A real pivot rewrites at least the hypothesis sentence, the landing page, and the messaging across all customer touchpoints. If those three are the same after the "pivot," the trigger condition will fire again in 60 days and you will be back here.
+
+The ledger also serves a second purpose. When you go back to investors, advisors, or your fractional CTO with the pivot decision, the ledger is the artifact that proves you are pivoting on evidence and not on whim. Investors fund founders who can show their work. The pivot ledger is the work.
+
+## When to PERSEVERE
+
+Not every dip is a pivot signal. The harder skill in 2026 is knowing when to push through a slow signal rather than chase a new hypothesis. Most pivots that fail were premature; the founder mistook a bad month for a bad hypothesis and reset the discovery loop just as the original one was starting to work.
+
+The persevere signals are quieter than the pivot signals because they are about trajectory, not about absolute numbers. The three signals to look for are: cohort 3-month retention is climbing (even slowly - 12% to 14% to 17% across three monthly cohorts is a persevere signal even if the absolute number is low), one segment is producing referrals without you asking for them (referrals mean the product is creating word-of-mouth value, which is the strongest possible PMF signal), and your own founder energy is genuinely renewing as you ship (not stubbornly continuing despite exhaustion - the difference matters).
+
+The Eric Ries persistence threshold is 6-12 months of consistent signal in the same direction. Most consumer products that became hits hit their first usable PMF signal in months 7-9; most B2B products in months 9-14. Pivoting at month 4 because the signal was not loud enough is the most common pre-PMF mistake. The right move at month 4 is usually to run a tighter experiment within the current hypothesis - sharpen the segment, refine the messaging, ship one more workflow improvement - and re-measure at month 6.
+
+Tomás, a B2B procurement-tools founder, came back to me eleven weeks after his Channel pivot with a different question. The new hypothesis was working: 4.2% outbound conversion, 3 paid pilots signed, MRR around $2,400. He was wondering whether to pivot again because growth had stalled at $2,400 for three weeks. The cohort numbers were good (78% week-4 retention on the 3 pilots), the segment was right, the new pivots from the trigger conditions were not firing. The persevere call was obvious. He had run his pivot 11 weeks earlier; the signal was new, the trajectory was up, and three weeks of flat MRR after a 0-to-$2,400 ramp is noise, not pattern. He stayed put. By week 16 MRR was at $4,100 with no new pivots.
+
+The honest trade-off: persevere is the harder discipline because it looks like inaction from outside. Investors ask why you are not pivoting; advisors offer new hypotheses; the [Twitter timeline](https://twitter.com) keeps surfacing founders who pivoted into a unicorn. Persevere works only when you have a written list of trigger conditions and the latest measurements show none of them firing. Without that list, persevere collapses into "stubborn." With the list, persevere is a deliberate operational choice backed by evidence.
+
+The KISS rule for the pivot/persevere call: write the trigger conditions down. Re-measure monthly. Pivot when two consecutive months hit a trigger; persevere when none do. Do not pivot every quarter; do not push through every signal. The framework runs on a steady cadence, not on emotion.
+
+## Hand This to the Next Loop
+
+You walk out of this chapter holding a pivot decision (one of six types, or persevere) and a pivot ledger that names what you keep and what you change. The next chapter for you depends on the pivot type.
+
+A Customer Segment pivot or Customer Need pivot routes you back to [Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) - rewrite the customer or problem blanks, keep the rest of the sentence template. Then [Find 10 People With the Problem](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) to validate the new hypothesis with the new segment.
+
+A Solution pivot routes you back to [Decide What's Next](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/#synthesis-write-down-what-you-heard-decide-whats-next) - the validated problem statement is still good (you confirmed the right customer has the right pain); the solution shape needs to change. Then back into the self-serve or hire path for the rebuild.
+
+A Channel pivot or Revenue Model pivot routes you back to [The First Ten Come From Your Network](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/) with the new channel or pricing model. The hypothesis stays intact; the go-to-market motion changes.
+
+A Technology pivot routes you to the [salvage-vs-rebuild decision framework](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/). The customer-facing hypothesis is the same; the implementation needs to be re-platformed.
+
+A persevere decision keeps you on whatever module you were on. Re-measure trigger conditions in 30 days.
+
+The course was always a loop. The reason it reads as a numbered sequence is that the discovery moves work the same regardless of whether you are running them for the first time or the fifth. The founders who graduate the course - the ones holding all eight Founder OS artifacts at the end - are not the founders who never pivoted. They are the founders who ran the loop three or four times and got better at each pass.
+
+D. is on his third pivot now. He ran the original hypothesis once (audit prep), pivoted to month-end close (Customer Need), then 7 weeks later pivoted the channel from outbound to partnerships (Channel). The two pivots cost him 5 weeks of build time combined and saved him at least two quarters of running each wrong hypothesis to its conclusion. The pivot framework is what made each loop a deliberate decision instead of a flail.
+
+## Further reading
+
+- Eric Ries, [*The Lean Startup*](https://theleanstartup.com/) - the canonical text on pivots, including all ten pivot types and the discovery-loop framing this chapter compresses.
+- Steve Blank, [The Customer Development Manifesto](https://steveblank.com/2010/01/25/the-customer-development-manifesto-reasons-for-the-revolution-part-1/) - the customer-development counterpart to Ries's pivot framework.
+- Patrick Vlaskovits and Brant Cooper, [*The Lean Entrepreneur*](https://leanentrepreneur.co/) - field-tested patterns for running discovery loops with limited resources.
+- Lenny Rachitsky, [How and when to pivot](https://www.lennysnewsletter.com/p/how-and-when-to-pivot) - decision-criteria interviews with founders who pivoted and survived (and some who pivoted and did not).
+- Marty Cagan, [Continuous Discovery vs Continuous Pivots](https://www.svpg.com/continuous-discovery-vs-continuous-pivots/) - the senior product perspective on when persevere beats pivot.
+- Y Combinator, [How to know when to pivot](https://www.ycombinator.com/library/4S-how-to-know-when-to-pivot) - the YC partner perspective on trigger conditions and signal strength.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/pivot-ledger.svg b/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/pivot-ledger.svg
new file mode 100644
index 000000000..52d20a8ac
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/pivot-ledger.svg
@@ -0,0 +1,90 @@
+
+  The pivot ledger: 4-column table tracking what survives the pivot and what does not
+  
+    
+  
+
+  Pivot ledger: what you keep, what you change
+  A pivot is not a restart. The evidence column is the difference between a pivot and a flailing reboot.
+
+  
+  
+  
+  
+  
+  
+
+  
+  Evidence Type
+  Source Module
+  Survives Pivot?
+  Action
+
+  
+  Customer relationships
+  Chapter 5.2 outreach
+  YES
+  Re-pitch new hypothesis
+  
+
+  
+  Validated problem (survived)
+  Chapter 2.1
+  YES
+  Carry forward as anchor
+  
+
+  
+  Disconfirmed problem
+  Chapter 2.3 / 7.5
+  YES (negative)
+  Add to "do not chase" list
+  
+
+  
+  Cohort retention numbers
+  Chapter 5.5 floor
+  YES
+  Baseline for next cohort
+  
+
+  
+  Hypothesis sentence
+  Chapter 1.1
+  REWRITE
+  New blanks, same template
+  
+
+  
+  Landing page copy
+  Chapter 1.2
+  REWRITE
+  New headline + CTA
+  
+
+  
+  Built MVP code
+  Module 5A / 6B
+  DEPENDS
+  Keep auth/billing, replace core
+  
+
+  
+  Founder energy / domain
+  N/A
+  YES
+  The whole reason to pivot
+
+  
+  Print this. Walk every row before declaring the pivot. The discipline is what separates a pivot from a flail.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/pivot-wheel.svg b/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/pivot-wheel.svg
new file mode 100644
index 000000000..52fc7bcd3
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/pivot-wheel.svg
@@ -0,0 +1,70 @@
+
+  The 6 pivot types: customer, need, solution, technology, channel, revenue
+  
+    
+  
+
+  Six pivot types branching from the same hypothesis
+  Each spoke names what stays right and what changes - keep what works, replace what does not
+
+  
+  
+  Founding
+  Hypothesis
+  5 blanks - 1 right
+
+  
+  
+  
+  1 - Customer Segment
+  Right product, wrong customer
+  e.g. SMB tool sold to enterprise
+
+  
+  
+  
+  2 - Customer Need
+  Right customer, wrong problem
+  e.g. dentists, bill not schedule
+
+  
+  
+  
+  3 - Solution
+  Right problem, wrong solution
+  e.g. dashboard, not workflow
+
+  
+  
+  
+  4 - Technology
+  Right solution, wrong stack
+  e.g. native, not Bubble
+
+  
+  
+  
+  5 - Channel
+  Right product, wrong distribution
+  e.g. PLG not outbound
+
+  
+  
+  
+  6 - Revenue Model
+  Right product, wrong pricing
+  e.g. seat, not per-event
+
diff --git a/content/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/cover.png b/content/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/cover.png
new file mode 100644
index 000000000..f97068540
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/index.md b/content/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/index.md
new file mode 100644
index 000000000..1ed21bbb2
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/index.md
@@ -0,0 +1,98 @@
+---
+title: "1.3 · Price Your Hypothesis on the Smoke-Test Page"
+aliases: ["/blog/price-hypothesis-on-smoke-test-page/"]
+description: "Add a Stripe payment button to your smoke-test page. Measure whether strangers will pay, not just whether they're curious."
+date: 2026-05-18
+draft: true
+course_chapter: false
+author: "JetThoughts Team"
+slug: price-hypothesis-on-smoke-test-page
+keywords:
+  - smoke test pricing
+  - stripe payment link mvp
+  - validate price before build
+tags:
+  - founders
+  - non-technical-founder
+  - module-1
+  - validation
+categories: ["Founders"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/"
+related_posts: false
+---
+
+> **Module 1 · Lesson 1.3 · [CORE]** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a live smoke-test landing page from [Lesson 1.2c](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/)
+>
+> **Output:** a price hypothesis with a measured click-to-payment signal
+>
+> **Progress:** M1 · 5 of 5 · Results so far: hypothesis sentence + live landing page + tracking installed + conversion data
+
+---
+
+A founder we worked with ran a waitlist page, collected 48 emails at 9.8% conversion, and spent $62K building the product. Zero paying customers. Her visitors had read the page as a free signup  --  the 48 emails proved curiosity, not commitment. An email signup costs nothing; typing a card number costs the moment of second-guessing. Those two signals are not measuring the same thing.
+
+After this lesson you will be able to: **add a Stripe Payment Link to your smoke-test page and measure whether strangers will click a real price  --  not just whether they'll leave an email.**
+
+---
+
+A **Stripe Payment Link** is a hosted checkout URL you generate from your Stripe dashboard  --  no code, no integration. You paste the link on your landing page. Stripe hosts the checkout. Strangers who click through and enter card details produce a payment intent  --  the strongest demand signal a pre-product page can generate.
+
+Your price hypothesis needs three parts:
+
+| Part | What it is | Example |
+|---|---|---|
+| **Number** | A specific dollar amount, not "affordable" | $49, not "premium" |
+| **Unit** | Per month, per user, or one-time | $49/month, not $49 |
+| **Framing** | Early-access or founding-member rate | "Founding member  --  $49/month for life" |
+
+**Default price anchor:** For SaaS, the most common tier is $49-$99/month if the tool replaces manual work. If you can't research yet, pick the midpoint of your category's band. You'll refine after Module 2 interviews.
+
+**Button copy matters more than the price number.** Two patterns consistently work:
+
+- **Outcome framing:** "Stop spending 4 hours on reconciliation  --  $97" (anchors price to the problem it replaces)
+- **Risk-reduction framing:** "Reserve your spot  --  $97 refundable for 30 days" (reduces first-touch risk)
+
+Pick one pattern. Do not A/B test  --  150 visits each on a $300 budget can't distinguish 4% from 5%. Ship one button copy.
+
+![Stripe Payment Link flow: dashboard → create link → paste URL on landing page → visitor clicks → card entry → payment intent](stripe-payment-link.svg)
+
+---
+
+> **Price:**
+>
+> 1. **Start Stripe verification tonight.** Sign up at [stripe.com](https://stripe.com) (free). Stripe needs your bank account + tax ID before accepting live payments  --  usually 1-3 business days. Start the weekend before launch.
+> 2. Create a Payment Link. Dashboard → Payments → Payment Links → New link. Add a one-time product at your hypothesis price. Use one-time (not subscription)  --  "founding member" converts better on a pre-product page.
+> 3. Set the after-payment redirect. **Skip it** if you're in a hurry (Stripe shows its own confirmation). **Set it** if you want GA4 to count payment completions as page views: **Mixo** — redirect to your main page URL (GA4 counts the revisit; rougher but works). **Carrd** — create a hidden section at the bottom, redirect to its anchor URL (`yourpage.carrd.co/#thanks`). **Durable** — create a new page called Thanks, redirect to `/thanks`.
+> 4. Add a refund line in your page footer (not the Stripe checkout footer): "Full refund within 30 days if we don't ship." Legal, honest, lowers click friction.
+> 5. Paste the Payment Link URL on your CTA button. Below it, smaller text: "Not ready? Join the free waitlist instead."
+> 6. **✅ Success check:** your Stripe dashboard shows live-mode (not test-mode) and the button opens a real checkout page.
+
+---
+
+**If Stripe verification takes more than 3 days.** **Why:** Stripe sometimes requests an ID upload for first-time accounts. **Fix:** build the page without the button. Run the email-only smoke test from 1.2c while Stripe processes. The demand signal doesn't depend on the price button being live today.
+
+**If visitors click the button but nobody completes payment.** Track both: click (page → Stripe) and completion (Stripe → thank-you). 60 clicks with 3 completions = the checkout page is killing intent (price felt different in context). 6 clicks with 3 completions = 50% of clickers bought  --  strong signal. Same outcome, opposite diagnosis. The [full price test guide](/course/tech-for-non-technical-founders-2026/reference/stripe-price-test-full/) has the detailed threshold table.
+
+---
+
+Open your Stripe dashboard. Write down the number of clicks vs. completed payments. Which number is lower than you expected? That gap is your pricing research question for Module 2 interviews.
+
+---
+
+> **Done when:** Stripe Payment Link is live on your smoke-test page and you have a measured click-to-payment rate.
+>
+> **Next click:** [2.1 · The Mom Test: Ask About the Past, Not the Future](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/)
+>
+> **If blocked:** see "If this fails" above. Module 1 closes here. Before Module 2, you should have: hypothesis (1.1), landing page (1.2a), tracking (1.2b), conversion data (1.2c), and a price signal (1.3). Missing one? Go back to that lesson.
+>
+> **What M1 cost you:** ~$325-625 total ($300-600 for Meta/Reddit ads + optional [Perplexity Pro](https://www.perplexity.ai/) $20/mo; all other tools used free tiers). If you're B2B on LinkedIn, budget $1,800-6,600. If you used the $0 organic path from the [channel guide](/course/tech-for-non-technical-founders-2026/reference/smoke-test-channel-guide/), your cost was $0. No hidden fees beyond ad spend.
+>
+> **Deeper reference:** [Full Stripe setup walkthrough + pricing revisit moments + threshold bands](/course/tech-for-non-technical-founders-2026/reference/stripe-price-test-full/)
+
+---
+
+> **See it in action:** [Module 1 walkthrough: Mia builds TutorMatch](/course/tech-for-non-technical-founders-2026/module-1-walkthrough-mia/)
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) free curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/stripe-payment-link.svg b/content/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/stripe-payment-link.svg
new file mode 100644
index 000000000..d7ab9cbe4
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/stripe-payment-link.svg
@@ -0,0 +1,31 @@
+
+  
+  
+  
+  Stripe
+  Dashboard
+  Payment Link
+  
+  
+  
+  
+  Landing Page
+  CTA: "Reserve
+  access — $97"
+  
+  
+  
+  
+  Stripe
+  Checkout
+  Card entry →
+  
+  
+  Thank
+  You
+  
+    
+      
+    
+  
+
diff --git a/content/course/tech-for-non-technical-founders-2026/quickstart/index.md b/content/course/tech-for-non-technical-founders-2026/quickstart/index.md
new file mode 100644
index 000000000..2d04a9712
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/quickstart/index.md
@@ -0,0 +1,99 @@
+---
+title: "Quickstart - From Idea to First Paying Customer"
+aliases: ["/blog/quickstart-tech-for-non-technical-founders/"]
+description: "The fastest path through From Idea to First Paying Customer - 5 modules, core lessons only, for time-poor founders who need results tonight."
+date: 2026-06-07
+draft: false
+course_chapter: false
+author: "JetThoughts Team"
+slug: quickstart
+keywords:
+  - tech for non technical founders quickstart
+  - fast path founder course
+  - minimum effective dose founder
+  - startup validation essentials
+tags:
+  - founders
+  - non-technical-founder
+  - course-quickstart
+categories: ["Founders"]
+metatags:
+  image: cover.png
+  og_title: "Quickstart - From Idea to First Paying Customer"
+  og_description: "The fastest path through the course - core lessons only, for time-poor founders who need results tonight."
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/quickstart/"
+related_posts: false
+---
+
+> **Quickstart** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+
+You have an idea and no time. You need the minimum effective dose - the smallest amount of reading that produces a real result. This page is that dose.
+
+## The Problem (in your language)
+
+You want to validate whether your idea has real demand before you spend $10K+ on a dev shop. You can't read code. You have evenings and weekends - maybe 2-4 hours a week. You need a route that works without hiring anyone.
+
+## The Promise
+
+**From a rough idea to a signed paid pilot ($500+ deposit) in 5 modules, on evenings and weekends, without writing a line of code.**
+
+Time: ~8-12 weeks at 2-4 hrs/week. Free. No sign-up.
+
+## The Minimal Path (Core Lessons Only)
+
+Skip anything tagged [OPTIONAL] and you still walk away with all 6 Founder OS artifacts. Here's the shortest route:
+
+### Module 1 - Hypothesis & Smoke Test (~1 week)
+*Output: one-sentence hypothesis + live landing page with Stripe price button.*
+
+- [**1.1** · Form Your Founding Hypothesis (90 min)](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/)
+- [**1.2a** · Build the Page (2-3 hrs)](/course/tech-for-non-technical-founders-2026/smoke-test-build-landing-page/)
+- [**1.2b** · Run the Test (7 days)](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/)
+- [**1.3** · Add a Stripe Price Button (5 min)](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/)
+
+**Gate:** ≥3% of cold visitors click your CTA.
+
+### Module 2 - Validate the Problem (~2-3 weeks)
+*Output: 10 Mom Test interviews + clickable prototype tested with 5 people.*
+
+- [**2.1** · The Mom Test: Ask About the Past](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/)
+- [**2.3a** · Find 10 People: Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/)
+- [**2.3b** · Find 10 People: What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/)
+- [**2.4** · Build a Clickable Prototype (2 hrs)](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/)
+
+**Gate:** ≥7 of 10 interviewees have spent time or money on the problem.
+
+### Module 3 - Design from Evidence (~3-5 days)
+*Output: one-page Product Brief from real customer vocabulary.*
+
+- [**3.1** · The One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/)
+- [**3.2** · Quality-check: Features to Outcomes](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/)
+
+**Gate:** every feature traces back to a verbatim interview quote.
+
+### Module 4 - Build It Yourself (~2-4 weeks)
+*Output: live MVP at a real URL, ownership locked Day 1.*
+
+- [**4.1** · Should You Hire? Decision Tree](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/)
+- [**4.2** · Own Your GitHub, AWS, and Database](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/)
+- [**4.3a** · Tools & Setup](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/)
+- [**4.3b** · Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/)
+
+**Gate:** you own every account; the app loads; one core flow works end-to-end.
+
+### Module 5 - First Paying Customer (~2-4 weeks)
+*Output: one signed paid pilot + repeatable outbound channel.*
+
+- [**5.1** · PMF Test Before You Scale](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/)
+- [**5.3** · First Ten Come From People Who Know You](/course/tech-for-non-technical-founders-2026/first-ten-customers-personal-network/)
+- [**5.4** · Charge Before You Ship: The Paid Pilot](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/)
+
+**Gate:** signed DPA + $500+ Stripe deposit received.
+
+---
+
+> **Start here:** [Chapter 1.1 - Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/)
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/reference/hypothesis-sprint-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/hypothesis-sprint-full/index.md
new file mode 100644
index 000000000..a8b92c255
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/reference/hypothesis-sprint-full/index.md
@@ -0,0 +1,139 @@
+---
+title: "Full Reference: The 6-Step Founding Hypothesis Sprint"
+description: "The complete Click/Jake Knapp Foundation Sprint methodology for writing a falsifiable one-sentence hypothesis. Includes the Mad Libs template, 4-lens scoring deep-dive, AI deep-research prompts, and a worked procurement-tool example."
+date: 2026-05-13
+draft: true
+slug: hypothesis-sprint-full
+---
+
+> **Reference companion to [Lesson 1.1 · Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/)**  --  the full 6-step sprint, 4-lens scoring methodology, AI research prompts, and worked examples. Read the micro-lesson first for the minimum effective path; return here when you want the deep reference.
+
+---
+
+## The Full 6-Step Sprint
+
+Jake Knapp and John Zeratsky published *Click* in April 2025 after twenty years of running design sprints with 300+ startups. The book's central artifact is the Founding Hypothesis: one Mad Libs sentence that names your customer, problem, approach, competition, and differentiation. Their thesis: *"Products click with customers when they make a compelling promise  --  and that promise must be simple, or customers won't pay attention."*
+
+The version below compresses the original multi-day workshop into a focused session you can run alone with a notebook and a kitchen timer.
+
+### Step 1: The Basics
+
+Open four columns in a notebook: Customer, Problem, Advantages, Competition. Write five entries in each column.
+
+- Five candidate customers (different segments)
+- Five candidate problems for the strongest customer (different jobs-to-be-done)
+- Five things you bring that a generic Lovable build does not (audience, domain knowledge, a contact, a unique data set)
+- Five things the customer does today instead of your product (competition, even when it is "a spreadsheet" or "doing nothing")
+
+Read the column. Circle the one entry you would bet on.
+
+Beside the customer you circled, write three ICP characteristics in plain words: industry vertical (e.g., "solo chiropractic clinics"), company size band (e.g., "1-3 staff"), and the specific moment the pain happens (e.g., "Monday morning insurance-claim resubmission"). These three become inputs for your interviews.
+
+### Step 2: Classic Differentiator
+
+Draw three columns: *fast*, *easy*, *free*. For each, write "more," "less," or "same" against the strongest competition entry from Step 1. Pick the one column you can credibly own.
+
+You cannot own all three. A product that is faster AND easier AND cheaper than the spreadsheet is a product nobody believes exists. Write one sentence: "Our product will be the [faster / easier / cheaper] one."
+
+### Step 3: Generate 3 Candidate Approaches
+
+Write three different one-sentence approaches to solve the circled problem for the circled customer. Three is the right number: two collapse into the safer option, four is procrastination.
+
+### Step 4: Magic Lenses (Full Deep-Dive)
+
+Score each of the three approaches on a 1-5 scale across four lenses:
+
+**Customer lens:** Would the customer pick this on a Friday afternoon between meetings? If the answer is "they would have to be convinced," score 1-2. If "they would notice this in a Reddit thread and bookmark it," score 4-5.
+
+**Pragmatic lens:** Can you ship something usable with what you have today? Drop one point if the approach requires integrating with an API you have never used. Drop another if it requires a license, partnership, or compliance work.
+
+**Growth lens:** How does the customer hear about you, and how many of them are there? An approach that needs a sales call to explain itself is 1-2. An approach that fits in a Reddit headline and converts on a landing page is 4-5.
+
+**Money lens:** Do the unit economics work at the scale you can plausibly reach? A consumer app at $4/mo needing 10,000 users to clear $40K MRR is a different shape than B2B SaaS at $400/mo needing 100. Pre-revenue founders with no built product: leave the Money lens blank and come back after the smoke test gives you real conversion data.
+
+Sum each approach. Pick the highest sum. The lens that scored lowest across the winning approach is your biggest risk  --  the part of the hypothesis most likely to break.
+
+**The PASS bar:** ≥14/20 across the four lenses with no individual lens below 2. Pre-revenue founders leaving Money blank: the bar drops to ≥11/15 across the other three, same "no lens below 2" rule.
+
+**The routing rule:** The lowest-scoring lens is the part of your hypothesis the next test must attack. Money and Customer are the two that matter first  --  if Money is lowest, your smoke test is about price; if Customer is lowest, your interviews need to find real pain. Pragmatic lowest? Feasibility check. Growth lowest? Ad-test the channel before the build.
+
+### Step 5: Write the Founding Hypothesis
+
+Open the Mad Libs sentence. Fill in the five blanks using the winning approach from Step 4, the customer and problem from Step 1, the competition from Step 2, and the differentiator from Step 2.
+
+Read it aloud three times. Stop when the sentence reads like a thing a friend could repeat back. Type the final sentence into a Google Doc titled `Founding Hypothesis - [date]` and save it to a `Founder OS` folder. You will paste this sentence verbatim into your landing-page headline, interview script, and Stripe price prompt.
+
+### Step 6: Test Design
+
+Open a fresh page. Write one sentence: *The smallest signal that would prove or kill this hypothesis is _____*.
+
+The full test is two parts: (1) a smoke-test landing page for demand signal, and (2) ten Mom Test interviews for problem signal. Write both as your test plan now. Modules 2 and 3 run the tests; this sprint produces the plan they run.
+
+---
+
+## AI Deep-Research Prompts
+
+### For the [customer] and [problem] blanks
+
+Paste into Perplexity Pro ($20/mo), ChatGPT Deep Research (Pro tier), or Gemini Deep Research ($20/mo Advanced tier):
+
+```text
+Find the 5 most-named pain points among [YOUR CANDIDATE ICP] in 2024-2026, from Reddit, LinkedIn posts, G2 reviews, and industry podcasts. Cite the exact source for each pain point and quote one verbatim phrase. If you cannot find a real source for any item, respond with "NOT FOUND - [item]" rather than estimating or paraphrasing.
+```
+
+**Free-tier fallback:** Paste the same prompt into Claude free (claude.ai) or ChatGPT free (chat.openai.com). The output is less exhaustive (these tools cannot browse the web in real time) but the NOT-FOUND escape valve will tell you which items it could not verify.
+
+### For the 4-lens scoring (optional AI shortcut)
+
+If you don't want to score yourself, paste into Claude or ChatGPT:
+
+```text
+Here is my Founding Hypothesis: [SENTENCE]. Score it 1-5 on each of the Customer, Pragmatic, Growth, and Money lenses. For each lens, name the single biggest risk and the one piece of evidence that would change my score. If any lens lacks enough specifics to score honestly, respond with "INSUFFICIENT DETAIL: [lens]" rather than guessing.
+```
+
+---
+
+## Worked Example: Procurement-Tool Valuation
+
+A founder building a vendor-management tool for procurement teams scored her approach:
+
+| Lens | Score | Why |
+|---|---|---|
+| Customer | 4/5 | Procurement teams she'd interviewed wanted the workflow |
+| Pragmatic | 4/5 | Could ship on Lovable + Supabase without partnerships or compliance |
+| Growth | 4/5 | Procurement people cluster in the same 3 newsletters |
+| Money | 1/5 | Buyers expected under $150/mo; unit economics needed $600/mo |
+
+The Money lens scored 1 because procurement teams expected under $150/mo and her unit economics needed $600/mo. She designed her landing-page CTA around the price point  --  not the feature set  --  and learned quickly that procurement at that price was a no.
+
+She pivoted to a 200-employee-plus mid-market segment where $600/mo was reasonable, re-scored Money to 4, and ran the test again. The pivot happened before she wrote a line of product code.
+
+---
+
+## Two More Worked Examples
+
+**Gmail in 2003:** If we help heavy email users solve finding old messages with full-text search + 1 GB free, they will pick it over Yahoo Mail because Yahoo charges for storage and has no real search.
+
+**B2B SaaS  --  chiropractic billing:** If we help solo chiropractors solve insurance-claim resubmission with a one-click resubmit, they pick it over billing services that take 14 days and charge 8% of recovered claims.
+
+**B2C  --  parents of teens with allergies:** If we help parents solve weekend menu safety with a 3-second phone-camera scan, they pick it over reading menus aloud because the teen does not have to feel different.
+
+---
+
+## Case Study: Tomas & Mia
+
+**Tomas** (ReconcileBot, B2B SaaS) filled his hypothesis: "If we help mid-size accounting firm controllers solve manual Stripe-to-QuickBooks reconciliation with an auto-matching engine, they will choose it over exporting to Excel because it cuts 2 hours of Monday work to 90 seconds." He scored 4/5 on customer, 4/5 on pragmatic, 3/5 on growth, 3/5 on money. Weakest blank: money  --  he doesn't know if firms will pay $200/mo or $2,000/mo. The money test goes into his smoke-test design.
+
+**Mia** (TutorMatch, B2C marketplace) filled hers: "If we help parents of kids 8-14 with dyslexia/ADHD solve finding a vetted specialist tutor with a search-by-specialty marketplace, they will choose it over Googling and calling dead numbers because it matches them in 48 hours with parent reviews." She scored 5/5 on customer, 4/5 on pragmatic, 3/5 on growth, 3/5 on money. Weakest blank: growth  --  she doesn't know if parents prefer search-by-specialty or search-by-location. Her smoke-test headline will test both.
+
+---
+
+## Further Reading
+
+- Jake Knapp and John Zeratsky, [*Click*](https://www.theclickbook.com/)  --  the book that introduced the Founding Hypothesis Mad Libs and the Foundation Sprint workshop
+- Lenny Rachitsky, [Introducing the Foundation Sprint](https://www.lennysnewsletter.com/p/introducing-the-foundation-sprint)  --  short writeup of how the format works
+- Once you have run the sprint at least once, layered frameworks like Lean Inception, JTBD Canvas, Value Proposition Canvas, and Lean Canvas add useful structure. Skip them on the first pass.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as a companion reference to the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) free curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/reference/smoke-test-channel-guide/index.md b/content/course/tech-for-non-technical-founders-2026/reference/smoke-test-channel-guide/index.md
new file mode 100644
index 000000000..8f3134efc
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/reference/smoke-test-channel-guide/index.md
@@ -0,0 +1,175 @@
+---
+title: "Full Reference: Smoke Test Channel Guide"
+description: "Complete ad channel budgets, account setup timing, B2B budget alternatives, and conversion benchmark sources for running a cold-traffic smoke test."
+date: 2026-05-13
+draft: true
+slug: smoke-test-channel-guide
+---
+
+> **Reference companion to [Lesson 1.2c · Run the Smoke Test and Read the Signal](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/)**  --  this page contains the full channel budget table, ad-account setup timing, B2B budget alternatives, and conversion benchmark sources. Read the micro-lesson first; return here for detailed channel planning.
+
+---
+
+## Full Channel Budget Table
+
+The dollar cost of 300 visits depends entirely on channel CPC (cost-per-click), with a wide spread. Plan from this table, then add ~20% slack for creative-iteration spend:
+
+| Channel | When to use | 2026 CPC | Budget for 300 visits |
+|---|---|---|---|
+| Meta / Instagram | B2C consumer | $0.70-$1.90 | $300-$600 |
+| Reddit Ads | Developer tools, niche communities | $1.25-$3.00 | $400-$900 |
+| Google Search | B2B with named search intent | $3-$8 | $1,200-$2,400 |
+| LinkedIn | B2B sold by job title | $5.50-$22 | $1,800-$6,600 |
+
+*Sources: [WordStream Meta benchmarks 2026](https://www.wordstream.com/blog/facebook-ads-benchmarks-2025); [WordStream Google Ads benchmarks 2026](https://www.wordstream.com/blog/2026-google-ads-benchmarks); [The B2B House LinkedIn benchmarks 2026](https://www.theb2bhouse.com/linkedin-ad-benchmarks/); [Stackmatix Reddit Ads 2026](https://www.stackmatix.com/blog/reddit-ads-cost-per-click).*
+
+**Default for a $20K-savings, no-cofounder founder: the $0 organic path.** Use Reddit comment outreach + LinkedIn DMs + a free landing page (NeetoSite + Clarity), and run the smoke test slower. The table above is a menu of paid options if you have budget to spare; it is NOT a floor.
+
+---
+
+## Ad-Account Setup Timing
+
+Picking the channel is fast. Getting the ad account ready to run is not. First-time ad-account setup runs 60-120 minutes, and many platforms hold the first ad in review for 24-48 hours before approving the account:
+
+- **Meta:** Business verification + ad account creation + payment method review. Plan for Sunday evening setup so verification clears by Tuesday. Meta is the slowest.
+- **LinkedIn:** First-time advertiser verification can take 48-72 hours.
+- **Reddit Ads:** Usually clears same-day.
+- **Google Ads:** Typically 24 hours for first-time account review.
+
+**Plan for the worst case.** If you wait until Monday morning to start the account, your "launch this week" plan slips to next week.
+
+---
+
+## B2B on a Small Budget
+
+If your ICP says LinkedIn but $1,800+ is out of reach, three viable substitutes at ~10% of the cost:
+
+| Alternative | How | Cost |
+|---|---|---|
+| LinkedIn organic outreach | 30 hand-picked DMs to people matching your ICP exactly | Free (trades cash for your time) |
+| Reddit Ads in a B2B subreddit | r/SaaS, r/startups, r/Entrepreneur, r/Sysadmin, or your vertical's sub | $400-$900 for 300 visits |
+| Cold email to 50 hand-built leads | Apollo free tier + Gmail | Free (reply rate replaces click rate) |
+
+Use one of these, run it the same way until the numbers stabilize, read the result against the same go/iterate/kill table. The smoke test is the test  --  the channel is the delivery vehicle.
+
+---
+
+## Channel by ICP (Full Breakdown)
+
+### B2C Consumer
+**Channel:** Meta ($0.50-$2 CPC). Split 60/40 Reels/feed.
+**When to pick:** Product is visual, audience is broad.
+**Skip when:** Customer 55+ OR enterprise.
+
+### B2B / Job-Title-Sold
+**Channel:** LinkedIn ($5.50-$22 CPC) OR Google Search ($3-$8).
+**When to pick:** LinkedIn for unaware audiences; Google for active searchers.
+**Skip when:** Consumer or under-25 audience.
+
+### Developer Tools
+**Channel:** Reddit Ads ($1-$3) OR Hacker News ($475/mo flat).
+**When to pick:** Audience in r/programming, r/webdev, r/SaaS, HN comments.
+**Skip when:** Non-technical procurement role.
+
+### Niche Vertical
+**Channel:** Google Search ($1-$5 long-tail intent).
+**When to pick:** Real estate, dentists, contractors Googling pain.
+**Skip when:** N/A  --  Google Search works for most verticals.
+
+**Twitter / X:** Skip for first-time validation in 2026  --  targeting signal too noisy after 2024-2025 platform changes.
+
+---
+
+## Before Your First Campaign: Create the Ad Account
+
+You need an ad account before you can create a campaign. Each platform has a one-time setup flow  --  plan 60-90 minutes for your first one. (Approval times: see [Ad-Account Setup Timing](#ad-account-setup-timing) above.)
+
+- **Meta:** Go to [business.facebook.com](https://business.facebook.com/) → Create account → verify your business (email or domain) → create ad account → add payment method.
+- **Google Ads:** Go to [ads.google.com](https://ads.google.com/) → Sign up → enter billing info → create a dummy campaign to complete account setup (pause it immediately  --  this is NOT your real smoke-test campaign; that comes in Lesson 1.2c).
+- **LinkedIn:** Go to [linkedin.com/campaignmanager](https://www.linkedin.com/campaignmanager/) → create account → add company page → add payment method.
+- **Reddit Ads:** Go to [ads.reddit.com](https://ads.reddit.com/) → sign up → add payment method.
+
+Do this the weekend before you plan to launch. If approval takes longer, you'll still hit your Monday start.
+
+---
+
+## Campaign Creation Recipes
+
+You picked your channel above and created your ad account. Here are the settings to use when you create your first campaign. Each ad platform changes its button labels regularly, so these recipes name the *what* and *why*  --  find the matching fields in your platform's campaign creation flow.
+
+**Budget note:** These recipes use conservative starter budgets for your first campaign. To hit 300 visits, scale the daily budget up using the CPC rates in the channel table above. Example: at Meta's $0.70-$1.90 CPC, 300 visits costs $210-$570 total  --  aim for $40-80/day over 5-7 days.
+
+### Meta Ads (Facebook/Instagram)
+
+1. **Campaign objective:** Pick "Traffic" (not "Conversions"  --  you need pixel data before conversion optimization works).
+2. **Budget:** $10-20/day. Set a lifetime budget of $70-140 to hit ~100-200 visits (CPC $0.70-$1.90). Add 20% for creative iteration.
+3. **Audience:** Start broad. Meta's AI optimizer is better than manual interest stacking in 2026. If your [customer] blank is "solo chiropractors," add one interest (Chiropractic) and let the rest run broad. Age 25-55. All genders unless your product is gender-specific.
+4. **Placement:** Advantage+ placements (automatic). Let Meta decide where your ad shows.
+5. **Ad creative:** Single image (your hero image from Lesson 1.2a, or the AI-generated one). Primary text: your value prop sentence (1-2 lines from your landing page). Headline: your landing page headline. CTA button: "Learn More" or "Sign Up." Destination: your landing page URL.
+6. **Tracking:** Your Meta Pixel should already be installed (Lesson 1.2b). In Ads Manager, under the ad set, verify the pixel is selected. If it says "No pixel," go back to 1.2b and install it.
+7. **Launch:** Hit Publish. Expect 24-48 hours for first-time ad account review. Do not touch the campaign for 5-7 days after it starts spending.
+
+### Google Ads (Search)
+
+1. **Campaign type:** Search campaign. NOT Performance Max (too broad for a smoke test). NOT Display (low intent).
+2. **Budget:** $20-50/day. Set max CPC bid at $3-8 (see channel table above for your use case).
+3. **Keywords:** 10-20 keywords in phrase match. Use your [problem] blank as the seed. Example: if your hypothesis is about chiropractor insurance claims, bid on "chiropractor insurance claim software," "resubmit denied claims chiropractor," "chiropractic billing automation."
+4. **Ad creative:** 3 headlines (Google shows 1-3). Headline 1: your landing page headline. Headline 2: one value prop. Headline 3: CTA ("Try It Free" or "See If It Works"). 2 descriptions. Description 1: your sub-headline. Description 2: one more value prop. Final URL: your landing page.
+5. **Tracking:** GA4 is installed (Lesson 1.2b). In Google Ads > Tools > Linked Accounts, link your GA4 property. This takes 30 seconds  --  click "Link" next to your GA4 property, confirm, done.
+6. **Launch:** Submit. First-time accounts go into 24-hour review. Do not touch for 5-7 days.
+
+### LinkedIn Ads
+
+1. **Campaign objective:** Website visits.
+2. **Budget:** $50-80/day minimum (LinkedIn CPC is $5.50-$22). If this is too steep, use the B2B budget alternatives section above instead.
+3. **Audience:** Job title + industry + company size. Use your [customer] blank literally. If your hypothesis says "CTOs at 20-50 person SaaS companies," target exactly that. Do not broaden  --  on LinkedIn, narrow targeting is cheaper (less competition per audience slice).
+4. **Ad format:** Single image ad.
+5. **Ad creative:** Intro text: your value prop (keep it professional  --  LinkedIn readers expect B2B tone). Headline: your landing page headline. Image: your hero image or a simple text-on-color card. CTA: "Learn More" or "Sign Up." Destination: your landing page.
+6. **Tracking:** LinkedIn Insight Tag should already be installed (Lesson 1.2b). In Campaign Manager, the tag should auto-detect if it's on your page.
+7. **Launch:** Submit. First-time advertiser verification can take 48-72 hours. Start account setup Friday, launch Monday.
+
+### Reddit Ads
+
+1. **Campaign objective:** Traffic.
+2. **Budget:** $10-25/day. Reddit CPC is $1.25-$3.00.
+3. **Targeting:** Community targeting. Pick 3-5 subreddits where your [customer] hangs out. For a developer tool: r/programming, r/webdev, r/SaaS. For B2B: r/startups, r/Entrepreneur. DO NOT target r/all  --  you'll burn budget on irrelevant clicks.
+4. **Ad format:** Promoted post (looks like a regular Reddit post with a "Promoted" tag).
+5. **Ad creative:** Title: your headline, rewritten in Reddit's casual tone. "We built a thing that [solves X problem]" works better than polished marketing copy. Body: 2-3 sentences. Problem → solution → link. Authentic, not salesy. Link: your landing page.
+6. **Tracking:** Reddit Pixel should be installed (Lesson 1.2b). In Ads Manager, the pixel status should show "Active."
+7. **Launch:** Submit. Reddit typically clears same-day. Comments will appear under your ad  --  leave them up unless they're spam. Real comments are free social proof or free feedback.
+
+---
+
+## Run Length and Volume
+
+**Run length:** Do not judge a campaign on its first few hours. The opening burst of any paid run attracts the platform's most reactive clickers  --  the people who click everything  --  so early conversion almost always over- or under-shoots the steady-state number. Let daily numbers normalize and stabilize before reading the rate.
+
+**Volume:** ≥300 paid visits. Below 300 the sample is too small to distinguish 2% from 5%. With 300 visits a 5% conversion is 15 signups, a 2% is 6 signups  --  the difference between 15 and 6 is meaningful. With 100 visits a 5% is 5 signups, a 2% is 2  --  you cannot tell whether you have a hot audience or a noisy one.
+
+---
+
+## Conversion Rate Benchmarks
+
+The Foundry CRO 2026 industry benchmark report (citing Unbounce Q4 2024 data):
+
+| Benchmark source | Median conversion rate |
+|---|---|
+| All industries (aggregate) | 6.6% |
+| SaaS / technology | 3.8% |
+| B2B professional services | 1-3% |
+| Paid search traffic | 3.2% |
+| Paid social traffic | 1.5% |
+
+These are aggregate medians across mature products with optimized funnels. Your unoptimized smoke test against cold traffic at week one is comparing against a different baseline. Use the go/iterate/kill table from the micro-lesson  --  not the industry medians  --  as your decision threshold.
+
+---
+
+## When the Smoke Test Isn't the Right Filter
+
+The smoke test misses founders whose product genuinely needs a longer education arc to make sense (a category-creation product, a complex B2B integration, a regulated-industry tool). What this looks like in the numbers: a 2-3% conversion rate that the founder reads as "kill the hypothesis" when the real signal is "this product needs a sales motion, not a Meta ad."
+
+If your hypothesis sentence is hard to fit in a headline, the smoke test is not the right filter  --  run a paid-pilot conversation instead. See [Charge Before You Ship](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/).
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as a companion reference to the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) free curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/reference/stripe-price-test-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/stripe-price-test-full/index.md
new file mode 100644
index 000000000..5b25e3299
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/reference/stripe-price-test-full/index.md
@@ -0,0 +1,146 @@
+---
+title: "Full Reference: Stripe Price Test Guide"
+description: "Complete Stripe Payment Link setup walkthrough, visit-to-Stripe-click threshold bands, button copy patterns with Claude prompt, click-vs-completion tracking, and pricing revisit moments."
+date: 2026-05-18
+draft: true
+slug: stripe-price-test-full
+---
+
+> **Reference companion to [Lesson 1.3 · Price Your Hypothesis on the Smoke-Test Page](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/)**  --  this page contains the full Stripe setup walkthrough with gotchas, click-vs-completion tracking table, detailed threshold bands, button copy patterns, and the Claude copy-generation prompt. Read the micro-lesson first; return here for deep pricing methodology.
+
+---
+
+## The Maya Story (Full Version)
+
+A founder came to us after nine months of building. She'd run her smoke-test page with a waitlist CTA, spent $380 on Meta ads, drove 490 visits, and collected 48 emails  --  a 9.8% conversion rate that looked respectable by every benchmark she'd found.
+
+She moved into building. By month nine she had shipped a working product and spent $62K on developer time  --  and had zero paying customers. On her first sales call the prospect asked whether the tool was really $49/month: she had assumed her landing page price was obvious, but most of the people who had given her an email had read the page as a free signup. The 48 emails proved curiosity, not commitment.
+
+You don't need a $62K invoice to learn this. An email signup costs the visitor nothing; a Stripe click costs them the moment of entering a card number. Those two signals are not measuring the same thing.
+
+---
+
+## Full Stripe Payment Link Setup
+
+A Stripe Payment Link is a hosted checkout URL generated from your Stripe dashboard  --  no code, no integration, no webhooks. Stripe takes ~2.9% + $0.30 per transaction.
+
+| Step | Action | Where in Stripe |
+|---|---|---|
+| 1 | Create free Stripe account | [stripe.com](https://stripe.com) |
+| 2 | Open Payment Links | Dashboard → Payments → Payment Links → New link |
+| 3 | Add one-time product at hypothesis price | "Add a product" inside the link wizard |
+| 4 | Configure after-payment redirect | "After payment" → custom thank-you URL on your builder |
+| 5 | Copy generated `https://buy.stripe.com/xxx` URL | Paste into landing-page CTA button |
+
+**Gotchas the table doesn't say:**
+
+- **Stripe signup.** You need an email and a business name; the business name can be your own name or a project name (Stripe doesn't verify incorporation at signup). Pick "I'm building a SaaS or software product" when it asks. Stripe will ask for your bank account + tax ID (SSN for US sole proprietors) before you can accept *live* payments  --  usually approved within a day, sometimes 24-72 hours if Stripe requests an ID upload. **Sign up at least 3 days before launch.**
+
+- **Can't find Payment Links?** Dashboard sidebar → Payments → Payment Links. If hidden, search "Payment Links" in the Stripe search bar (it sometimes tucks under "More").
+
+- **One-time vs subscription.** Use one-time for the smoke test  --  a "founding member" lifetime or 12-month block. It converts better than a recurring sub on a pre-product page because the commitment is bounded.
+
+- **Thank-you URL on Carrd.** Carrd has no separate "thank-you page" route. Make a hidden second section on the same Carrd page (Settings → Sections → add → set as Hidden) and use its anchor URL (e.g. `yourpage.carrd.co/#thanks`) as the Stripe redirect. Framer and Webflow have real second pages; Carrd cheats with anchors.
+
+- **Refund policy in the footer.** "Full refund within 30 days if we don't ship." Standard FTC-friendly disclosure for pre-orders, also lowers click friction. The signal is still real because card entry took intent.
+
+- **Live mode, not test mode.** Test-mode clicks prove the button works; live mode proves anyone wants to buy.
+
+---
+
+## Visit-to-Stripe-Click Threshold Bands
+
+| Band | Visit-to-Stripe-click | What to do |
+|---|---|---|
+| Iterate before you kill | Below 4% | Lower price by 50%, add "founding member" framing, change button copy. Below 2% after that = audience or hypothesis is wrong, not the price. In the 2-4% band, also try shortening the Stripe product description. |
+| Advance | 5-9% | Price-validated hypothesis. Move to Module 2 customer interviews. Email everyone who clicked but didn't complete  --  the most valuable interview group. |
+| Verify before celebrating | 10%+ | Either exceptional fit or ad targeting hit a hot audience. Run a second cold channel briefly to verify. If both channels stay near the rate, the signal is real. If one is 12% and the other 2%, your targeting is unusually good, not your pricing. |
+
+Thresholds assume a $49-$299 price band. Below $49, you need more than 5% to cover acquisition cost; above $299 (or any $500+ one-time), 2-3% can be enough if the completion rate is high.
+
+---
+
+## Click-vs-Completion Tracking
+
+Both signals matter. Track click (page → Stripe) AND completion (Stripe → thank-you):
+
+| Scenario | Diagnosis |
+|---|---|
+| 60 clicks, 3 completions | Checkout page is killing intent  --  price felt different in context, or card-entry surfaced second thoughts |
+| 6 clicks, 3 completions | 50% of clickers bought  --  strong price signal, even if the base click rate was low |
+| 8% email signups, 6% Stripe clicks | What price-hypothesis validation looks like in the clear |
+
+Same page, both CTAs: primary CTA is the Stripe button with price visible. Below it, smaller text: "Not ready? Join the free waitlist instead." This weights the Stripe signal as primary without eliminating the email signal.
+
+Both signals must be tracked from the same page view count. Don't compare your email list size to your Stripe dashboard in isolation.
+
+---
+
+## Button Copy Patterns (Full)
+
+Two patterns consistently beat plain "Get access - $97" on pre-product pages:
+
+| Pattern | Example | When it wins |
+|---|---|---|
+| Outcome framing (anchor price to the problem it replaces) | "Stop spending 4 hours on reconciliation  --  $97" | Buyer can name what the alternative costs them |
+| Risk-reduction framing (lead with refundable/refund window) | "Reserve your spot  --  $97 refundable for 30 days" | First-touch audience, no brand trust yet |
+
+**Do not A/B test on the smoke test.** Two-variant testing on a $300 ad budget produces 150 visits each, not enough to distinguish 4% from 5%. Pick the pattern that fits your audience best, ship one button copy, read the single result. A/B testing is a post-launch tool.
+
+### Claude Copy-Generation Prompt
+
+If you want copy variants to choose between before launch:
+
+```text
+I'm testing a price hypothesis for a pre-product landing page.
+
+My hypothesis: [paste your one-sentence Founding Hypothesis here]
+My test price: [e.g., $97 one-time founding member access]
+My target customer: [e.g., freelance bookkeepers who reconcile client accounts manually]
+My hero benefit: [e.g., reconcile Stripe and QuickBooks in 90 seconds instead of 4 hours]
+
+Generate 2 button-label variants and a 1-sentence sub-copy for each:
+1. Outcome framing (price anchored to the outcome / alternative cost the buyer already pays)
+2. Risk-reduction framing (refundable, 30-day window)
+
+Format each as:
+BUTTON: [button text]
+SUB-COPY: [one sentence under the button]
+```
+
+---
+
+## AI Deep-Research for Price Anchor
+
+Paste into Perplexity Pro ($20/mo), ChatGPT Deep Research (Pro tier), or Gemini Deep Research ($20/mo Advanced tier):
+
+```text
+What do [YOUR ICP] currently pay for [YOUR CATEGORY]? Pull from G2 review price snippets, Reddit pricing threads, Capterra category averages, and competitor pricing pages. If you cannot find a real source for any item, respond with "NOT FOUND - [item]" rather than estimating or paraphrasing.
+```
+
+**Free-tier fallback:** Paste the same prompt into Claude free or ChatGPT free. Output is less exhaustive but the NOT-FOUND escape valve tells you which items it could not verify.
+
+The output gives a real price distribution (e.g., "$19-$79/month is the band, with one outlier at $299"). Pick your hypothesis price ABOVE the cheapest 30%; the smoke test's job is to validate willingness-to-pay, not to be cheaper than the cheapest.
+
+---
+
+## Pricing Revisit Moments
+
+The smoke-test price is a hypothesis price, not your launch price. Revisit pricing at two moments:
+
+| Moment | What to listen for | How it changes your brief |
+|---|---|---|
+| After 10 customer interviews | Comments about budget, alternatives they pay for now, what the problem costs them | If 5+ mention $250/month for a workaround, your $97 is anchored too low. If 3+ say "under $30 only," audience or value prop needs fixing |
+| Before first paid pilot | What reference customers will sign for given the research weight | Paid pilots usually settle at 30-50% of eventual list price plus a case-study clause. Smoke-test number is the ceiling you tested at, not the floor |
+
+---
+
+## Case Study: Tomas & Mia
+
+**Tomas:** Adds a Stripe price button at "$1,200 founding member  --  6 months access at $200/mo equivalent" (one-time). 5% of visitors click (15 of 300). Of those, 3 complete the payment. Weak price signal  --  won't sustain $200/mo equivalent without the product in hand.
+
+**Mia:** Adds a Stripe price button at "$99 founding member  --  4 months access at $25/mo equivalent" (one-time). 6% of visitors click (18 of 300). Of those, 6 complete. Stronger signal than Tomas  --  parents are used to paying for tutoring.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as a companion reference to the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) free curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/cover.png b/content/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/cover.png
new file mode 100644
index 000000000..3d2897dd1
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/index.md b/content/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/index.md
new file mode 100644
index 000000000..9123b2041
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/index.md
@@ -0,0 +1,107 @@
+---
+title: "Salvage vs Rebuild: 6-Question Decision Tree"
+aliases: ["/blog/salvage-vs-rebuild-decision-tree/"]
+description: "A 30-minute structured decision that ends two weeks of analysis paralysis. KEEP / FREEZE / REBUILD with a 30/60/90 day plan."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: salvage-vs-rebuild-decision-tree
+keywords:
+  - salvage rebuild software project
+  - founder rescue decision tree
+  - codebase salvage decision
+  - rebuild or refactor founder
+  - tech debt decision framework
+tags:
+  - founders
+  - non-technical-founder
+  - template
+  - course-companion
+  - rescue
+categories: ["Templates"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/"
+related_posts: false
+---
+
+📋 Template companion to the "When Things Break" path of the [From Idea to First Paying Customer course](/course/tech-for-non-technical-founders-2026/). Run alone Friday afternoon. Send the score to one independent reviewer for a paid 30-minute call.
+
+# The Salvage vs Rebuild Decision Tree
+
+A 30-minute decision that ends two weeks of analysis paralysis and gives you a defensible verdict by Friday night.
+
+By Sunday morning you will know whether to KEEP your codebase, FREEZE it for 60 days while you stabilize, or REBUILD the two or three flows that carry your business. You will not have read a line of code. You will have answered six yes/no questions in a Notion doc and sent the score to one independent reviewer for a 30-minute paid second opinion.
+
+## Why this exists
+
+A founder we picked up in late 2025 had spent **$95K and fourteen months** with the previous shop on a marketplace app for home-service contractors. The codebase was about **38,000 lines of Ruby on Rails** with **0% test coverage**, no staging environment, and an auth flow that had been reimplemented three times in three years. None of the three had been deleted. Two were still wired into different login URLs.
+
+She had spent nine weeks asking three different consultants whether to keep, rewrite, or do something in between. Every consultant gave a different answer. Every answer cost $1,500 to $4,000. She ran the six questions below in one Friday afternoon, scored a 2 out of 6, and had a paid 30-minute review confirming a 30/60/90 day REBUILD-the-core-paths plan by the following Wednesday. The paralysis was the expensive part. The decision was 30 minutes.
+
+## How to use it
+
+Run this **alone, on a Friday afternoon**. Do not invite the team. If something fails, you want to know before the conversation, not during it.
+
+Bring five things: the latest code-health note from your new lead engineer or fractional CTO (a thumbs-up or thumbs-down counts), the bug backlog count, the test coverage percentage if anyone tracks it (write `0` if nobody does), the AWS or Heroku bill trend over the last six months, and the original SOW. Open a fresh Notion doc.
+
+For each question, write the answer + the score (0 or 1) + one sentence of evidence. The whole exercise should take 30 minutes. Send the doc to ONE independent reviewer (not the team that wrote the code, not the agency you are about to hire) for a 30-minute paid second opinion before you commit.
+
+## The six questions
+
+Score each question 1 or 0 and write one sentence of evidence next to it. The whole grid takes 30 minutes.
+
+| # | Question | Score 1 if | Score 0 if |
+|---|---|---|---|
+| Q1 | **Bus factor** - is more than one person able to deploy the production app and restart it without help today? | Two or more humans can deploy independently. | One person, or that person left in the last six months. |
+| Q2 | **Test coverage signal** - does the team have any automated tests that run before a deploy? Even 10% with a green CI counts. | `bundle exec rspec` (or the equivalent) runs in CI and the build is green more days than red. | Testing is manual, there is no CI, or the build has been red for more than two weeks. |
+| Q3 | **Database health** - can you restore last night's production database to a fresh staging environment in under four hours, with someone you can call tonight? | Backups run nightly, the last seven are visible in your provider's console, and someone has a one-page restore runbook. | "We have backups but I have never tested a restore" - same as no backups. |
+| Q4 | **Architecture sanity** - can you list the top three external services your app depends on (e.g. Postgres, Redis, Stripe) and explain in one sentence what breaks if each goes down? | You can write three sentences without help. | The answer is "I don't know, the team handles that." A founder who cannot list the top three cannot triage an outage. |
+| Q5 | **Onboarding time** - if you hired a senior engineer Monday morning, would they ship one real pull request to staging by Friday? | There is a written README that gets a developer from `git clone` to a running local app in under two hours. | Onboarding needs "let me get on a call and walk you through it" - that is a knowledge silo, not a codebase. |
+| Q6 | **Customer signal** - are real users (not your team, not your investors, not friends doing favors) using the app every week, in volume that materially affects your business? | You can name 10+ paying or actively engaged weekly users by handle or company. | Usage is mostly the team and a few pilot accounts who have not logged in this month. |
+
+## The verdict
+
+Add up the scores.
+
+| Score | Verdict | What you do next |
+|---|---|---|
+| **5-6** | **KEEP and harden.** | The codebase is salvageable. Spend the rebuild budget you were about to write a check for on test coverage, monitoring, and one senior hire. Do not rewrite. |
+| **3-4** | **FREEZE and stabilize.** | No new features for 30 to 60 days. One sprint on access ownership (run the [GitHub / AWS / database checklist](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/)), one sprint on adding tests around the top three flows, one sprint on monitoring and backups. Re-score in 60 days. If you climb to 5+, you keep. If you stay at 3-4, you rebuild the core paths. |
+| **0-2** | **REBUILD core paths.** | Not a full rewrite. Identify the two or three highest-traffic flows (signup, checkout, the one core action your users repeat) and rebuild THOSE on a parallel codebase. Migrate users behind a feature flag. Keep the legacy system running for everything else for 90 days, then sunset it one flow at a time. |
+
+A score of 0 is not a "burn it down" verdict. The legacy code keeps running while you carve out the parts that matter and rebuild them with tests, monitoring, and one engineer who owns them.
+
+## What good looks like vs what bad looks like
+
+### Treating the score as a verdict on you, not the codebase
+
+> Bad: "I scored a 1. I picked the wrong team. This is my fault."
+> Good: "I scored a 1. The previous shop shipped without tests, monitoring, or backups. That is triage data."
+
+A 2 or 3 on the first run is typical for the rescue-stage builds we see. The score points at the next sprint, not at the mirror.
+
+### Conflating REBUILD with FULL REWRITE
+
+> Bad: "We scored a 1, so we are throwing everything away and starting fresh in Next.js."
+> Good: "We scored a 1. Signup, checkout, and the contractor-match screen carry 80% of our revenue. We rebuild those three flows on a parallel codebase, ship behind a feature flag, and keep the legacy admin panel running for nine more months."
+
+Joel Spolsky called the full-rewrite trap "[the single worst strategic mistake](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/) any software company can make" in 2000, and the math has not changed. A full rewrite buys you a 12 to 18 month feature freeze in exchange for a new codebase with its own undiscovered bugs. REBUILD in the verdict above means the two or three flows that carry the business, not the whole repo.
+
+### Skipping the independent reviewer because "we cannot afford a consultant"
+
+> Bad: "I will run this myself. A 30-minute review costs $400 and I am already over budget."
+> Good: "I scored a 2. I am sending the doc to one fractional CTO for a $400 review on Monday, before I sign anything else."
+
+The founder in the opening story spent $7,500 on three consultants over nine weeks asking the same question three different ways. One 30-minute paid review by someone who is not selling you the rebuild costs less than $500 and resolves it in a week.
+
+## What to do after
+
+- **Send the verdict + the six scores to your independent reviewer** for a 30-minute paid call. Ask one question: "Is there anything in this score I am misreading?"
+- **Draft the 30/60/90 day plan in plain English.** KEEP looks like "hire one senior engineer, raise test coverage to 40% by day 90, set up monitoring." FREEZE looks like "no new features for 60 days, three sprints on stabilization, re-score on day 60." REBUILD looks like "two parallel codebases, feature flag, sunset the old one flow at a time."
+- **Forward the verdict to your investor or board the same week.** Three lines: the score, the verdict, the plan. Forward it and you keep the trust you have spent 18 months building.
+
+If the verdict is FREEZE or REBUILD and the previous team is still around, the next two reads are the [dev shop red flags checklist](/blog/dev-shop-red-flags-checklist/) and the [step-by-step exit guide](/blog/fire-dev-shop-guide/). If the verdict is KEEP, run the [ownership checklist](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/) the same Friday to confirm you actually own what you just decided to harden.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/cover.png b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/cover.png
new file mode 100644
index 000000000..6a5ed669d
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/index.md b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/index.md
new file mode 100644
index 000000000..0f047a80f
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/index.md
@@ -0,0 +1,220 @@
+---
+title: "4.3b · The Self-Serve MVP Stack: Build Phases"
+description: "The build plan: 4 phases from Lovable UI to live Stripe checkout. Phase exit criteria, 5 green lights, and the Module 5 handoff. Part 2 of Chapter 4.3."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: self-serve-mvp-stack-build-phases
+keywords:
+  - lovable supabase stripe build phases 2026
+  - non technical founder mvp build plan
+  - vibe coding ship plan
+  - self serve mvp exit criteria
+tags:
+  - founders
+  - non-technical-founder
+  - course-companion
+  - self-serve
+  - vibe-coding
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "4.3b · The Self-Serve MVP Stack: Build Phases"
+  og_description: "The build plan: 4 phases from Lovable UI to live Stripe checkout. Phase exit criteria, 5 green lights, and the Module 5 handoff."
+cover_image_alt: "JetThoughts cover showing three hand-drawn stacked layers labeled Lovable, Supabase, and Stripe with arrows linking them, and a sticky note reading Ship by Friday week 4."
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/"
+related_posts: false
+---
+
+> **Module 4 · Step 3b of 4** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Part 2 of 2** · [Part 1: Tools & Setup](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) covers why these three tools, what each one does, the 12 rules, communities, and the AI critic block.
+>
+> **Input:** a Module 4 decision pointing to "self-serve" + a one-page brief + the tool knowledge from Part 1
+>
+> **Output:** a live MVP at a staging URL real users can click - by week 10-12 for evening-only founders (the 2-4 hr/week pattern this course is built for), or by Friday week 4 for full-time founders
+
+> **TL;DR:** Four build phases with one demo each. Phase 1 ships clickable UI. Phase 2 wires Supabase auth. Phase 3 connects Stripe checkout. Phase 4 deploys to 5 ICP users. Five green lights to exit. Ship the shed, not the skyscraper.
+
+> **Calendar reality for the MVP build.** A full-time founder with daytime availability can hit the Phase 4 5-lights in 4-6 weeks. An evening-only founder (the 2-4 hr/week pattern this course is built for) typically needs 10-12 weeks for the same outputs. Phase 2 (Supabase wiring + RLS - Row-Level Security, the database rule that walls one customer's data off from another's) and Phase 3 (Stripe webhook - an automatic message Stripe sends your app when a payment lands - plus idempotency, the rule that says "if the same webhook fires twice, only act once") are where part-time founders lose the most calendar. Plan a 10-week version of the build, not a 4-week version. The Friday-week-4 framing in the Output line above applies to full-time founders only.
+
+> **This chapter assumes you read Part 1 first.** Part 1 covers the $0 path, the 12 rules, what each tool does, the M2 prototype vs M4 MVP distinction, communities, and the AI critic block. The build phases below reference those concepts without re-explaining them.
+
+## The ship plan
+
+> **The ship plan below is the BUILD portion only.** It assumes you already ran Modules 1-3 (hypothesis → smoke test → 10 interviews → one-page brief) and read [Part 1: Tools & Setup](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/). If you skip straight here without validation, the build often ships into the silence Modules 1-3 were designed to prevent.
+
+Four build phases, plus an onramp phase that hands you off to Module 5. Each phase ends with one demo to one human (a friend, an advisor, your spouse, the dog if necessary - someone who has not seen the build). The build phase ends with five real ICP users on the staging URL; the onramp phase brings the rest of your Ch 2.3 (a + b) interview pool onto the product.
+
+1. **Phase 1 - Lovable, the UI.** No backend yet. *Demo:* screens click, no data persists.
+2. **Phase 2 - Supabase + auth.** Real signup works. *Demo:* your spouse signs up, a row appears in Supabase in real time.
+3. **Phase 3 - Stripe + checkout.** $1 test transactions. *Demo:* you sign up as a fake coach, pay $1, the webhook flips your row to paid.
+4. **Phase 4 - staging URL + 5 ICP users.** Custom domain, Stripe live. *Right after:* 5 click sessions logged - iterate from real signal.
+5. **Onramp phase - Module 5 handoff.** Invite the 10 Ch 2.3 (a + b) interviewees by name (covered in detail below). Hand off to Module 5 with a populated users table, not an empty one.
+
+### Phase 1 - write your prompts, set up Lovable, ship the UI
+
+Start by opening the one-page brief. The "what you're building" section becomes your first three Lovable prompts.
+
+> **Bridge from Ch 2.4 vocabulary (the highest-leverage paste in the course).** Before you describe a button label, a column header, or a screen title, open your Ch 2.4 vocabulary doc (the verbatim words your 5 prototype subjects used in the closing "describe in one sentence" question). If 4 of 5 said "match" and not "reconcile," the button label is **"Match transactions,"** not "Reconcile." If 3 of 5 said "client" and 2 said "patient," **use the most-repeated term**. The vocabulary your prototype subjects passed is the only user-tested language you have; the production MVP is the one place where using it has revenue consequences.
+
+Lovable's prompt style is conversational; you describe the screen, the components, the rough behavior. Examples:
+
+```text
+Build a dashboard for a fitness coach. Top-level view shows
+a list of clients (name, last check-in date, status: green
+if checked in this week, red if not). Click a client to open
+their detail page with a check-in form (date, weight, notes,
+3-photo upload).
+```
+
+Lovable generates the screens. You iterate by chatting with it: "make the status badges bigger, move the check-in form to the right side." By the end of the phase you have a clickable UI on a public staging URL. No data persists yet. That is fine. The phase demo is to your spouse: do the screens make sense without any explanation? If the screens need a tour to understand, the design is wrong, not the build. Rewrite the prompts.
+
+### Phase 2 - set up Supabase, connect, real signup works
+
+Create a Supabase project on the free tier. Define your three or four core tables in the SQL editor (or in the Table Editor UI; both work for an MVP). For the fitness coach example: `coaches`, `clients`, `check_ins`. Enable [Row-Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security) from the start. RLS is the difference between a coach seeing their own clients and a coach seeing every coach's clients in a single bug. Skipping it is the most common security mistake we see in vibe-coded MVPs.
+
+> **First-table walkthrough (for the fitness-coach example - adapt to your domain):** in Supabase Dashboard, click **Table Editor** in the left sidebar, then **New table**. Name it `coaches`. Check the "Enable Row Level Security (RLS)" box BEFORE adding columns. Add columns: `id` (uuid, primary key, default `gen_random_uuid()`), `email` (text), `user_id` (uuid, foreign key to `auth.users.id`), `created_at` (timestamp, default `now()`). Click **Save**. Repeat for your second and third tables. The RLS checkbox is the load-bearing click - if you forget it on table creation, you'll have to manually enable it later AND backfill policies on existing rows.
+
+In Lovable, install the Supabase integration. Lovable will add the Supabase JS client and store the keys for you. Wire your signup screen to `supabase.auth.signUp()` and your data screens to `supabase.from('clients').select()`. The phase demo: your spouse signs up via the staging URL, you watch a row appear in the Supabase console in real time.
+
+> **Self-test your RLS policy before going live (two paths).**
+>
+> *No-code path (default for Sam).* In Claude or ChatGPT, paste: *"Audit my Supabase RLS policy. Here is my schema: [paste your table definitions from Supabase Table Editor]. Here is my current RLS policy: [paste from Authentication -> Policies]. Tell me whether a logged-in user with a fake user-id can read rows that belong to other users. If yes, give me the exact policy SQL to fix it."* Paste the AI's suggested policy into Supabase Authentication -> Policies.
+>
+> *SQL path (only if you are comfortable writing SQL).* In Supabase Dashboard -> SQL Editor, paste the test below, replacing `` with your main user-data table. The pretend user-id `999` has no real rows; if the query returns any, your policy has a hole.
+>
+> ```sql
+> SET ROLE authenticated;
+> SET request.jwt.claims = '{"sub": "00000000-0000-0000-0000-000000000999"}';
+> SELECT * FROM 
;
+> RESET ROLE;
+> ```
+>
+> Zero rows back = policy works. Any rows back = the policy is missing a `USING (auth.uid() = user_id)` clause or equivalent. Fix before any real user touches the URL.
+
+> **End-of-Phase-2 micro-fail signal.** Before you build Stripe in Phase 3, hand the staging URL to your spouse OR one of your Ch 2.3 (a + b) Mom Test interviewees. Give zero coaching. Watch them try to sign up and reach the core action button (logging a check-in, exporting the CSV, whatever your one-page brief named as the workflow). If 2+ test users stall on screens 1-2, the workflow shape is wrong - pivot back to [Ch 3.2 outcome rewrite](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/) before adding Stripe. Building a payment wall on top of a workflow nobody can navigate just adds friction to a broken loop.
+
+### Phase 3 - add Stripe, wire checkout, $1 test transactions
+
+Create a Stripe account in test mode. Build one product (your monthly plan) at one price (the price your one-page brief locked in). Use [Stripe Checkout](https://docs.stripe.com/payments/checkout/quickstart) for the simplest possible integration: one URL Lovable links to, one webhook (a webhook is an automatic message Stripe sends your app the moment a payment succeeds - you don't write code to call Stripe; Stripe calls you) back to Supabase that flips the `coaches.subscription_status` column to `active` when the charge clears.
+
+Spend the rest of the phase running $1 test transactions through the flow: signup, hit the paywall, pay $1 in test mode, land in the paid view. Use Stripe's [test card numbers](https://docs.stripe.com/testing) to simulate failures (declined card, 3D Secure challenge, dispute). The phase demo is to yourself: you sign up as a fake coach, you pay $1, you land on the paid dashboard, you check Supabase, the row says paid. Webhook works.
+
+### Phase 4 - deploy, send to 5 ICP users, iterate from the data
+
+Switch Stripe out of test mode. Buy a domain (~$10/year on [Porkbun](https://porkbun.com/) - .com registration is $9.73 first year, $10.91 renewal as of 2026 - or your registrar of choice; never let a tool hold your domain). Point the domain at the Lovable staging URL. Take final screenshots, write a 3-line cold email or LinkedIn DM, and send to 5 ICP prospects from your [Module 2 outreach list](/course/tech-for-non-technical-founders-2026/outreach-sequence-template/).
+
+> "Hey [name] - the workflow you described recently (logging client check-ins by hand on a spreadsheet) is now a tool. Quick first-use, $29/month after a trial window. URL: [staging URL]. Honest reactions only."
+
+Watch what happens. If 0 of 5 click, the cold message is wrong, not the product (yet). If 5 click and 0 sign up, the landing screen is wrong, not the product. If 5 sign up and 0 pay, the paywall position or the price is wrong. Each failure shape tells you what to fix next. The demo is the data, not the screens.
+
+> **Phase 4 exit criteria: the MVP is "done" only when ALL 5 lights are green.** Without these, you either polish indefinitely in Lovable or hand Module 5 an MVP that real users cannot touch.
+>
+> 1. **Stripe in LIVE mode** (not test mode) and a real card successfully clears the paywall at least once.
+> 2. **Custom domain wired** (not a `.lovable.app` subdomain) - the URL you DM to a user must be yours.
+> 3. **At least 1 ICP user who was NOT in your Ch 2.3 (a + b) interviews** has clicked through to the paywall on the live URL.
+> 4. **Zero JS errors in the browser Console** on the sign-up + checkout flow (open DevTools, walk the happy path, console must stay clean).
+> 5. **Friday-style weekly demo recording exists** for the last week of build (a Loom or screen-record proving the demo cadence held to the end).
+>
+> Advance to Module 5 only when all 5 are green. If any are red, the MVP is NOT ready for the 10-30 users Module 5 needs as input. Fix the red light first, then re-check.
+
+> **Pre-flight before M5.1: book up to 10 user sessions.** Phase 4's 4-6 onramp accounts are not enough for M5.1's Sean Ellis 40% test (under 10 respondents = noise, not signal). Before you start Module 5, book a second small invite wave: 5-10 more sessions from your Ch 2.3 (a + b) interviewee list, your community connections, or a fresh micro-batch of cold DMs. Aim for 10-15 active users total by the time M5.1's survey ships. Without this pre-flight, you will run the 40% test on 5 people, get an ambiguous result, and falsely conclude you have a product problem when you really have a sample-size problem.
+
+### Onramp phase - Module 5 handoff: invite your Module 2 interviewees onto the live MVP
+
+The build phases above are the BUILD container. The onramp phase is the Module-5 handoff - the step that turns a live staging URL into a live users table. The five cold prospects from Phase 4 are the demand-signal check. The 10 interviewees you ran through Ch 2.3 (a + b) are the warm pool that becomes your first real users - the ones who told you the problem was real, in their own words, recently. They are not on your MVP yet. They will not show up unless you invite them by name.
+
+Open your Ch 2.3 (a + b) interview list. For each of the 10 names, write a 3-line personalized note: the workaround they described in their interview, the staging URL of the workflow that now replaces it, and one specific question they answered that the MVP now responds to.
+
+Send it as a [Loom](https://www.loom.com) (Loom is a free short-form screen-recording tool - the recipient watches you click through the product in their browser, no install) or a personal LinkedIn DM, not a generic email blast.
+
+Expect 4-6 of the 10 to create accounts; 2-3 of those to actually log in and click around; 1-2 to become candidates for the [Ch 5.1 Sean Ellis 40% survey](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/) once you have 10-30 users total. "Create an account" is not "pay" - paid conversion happens in Module 5.
+
+This is the step that closes the gap between Module 4 (MVP shipped) and Module 5 (first paying customer). Without it, you ship a working URL into the silence of a Supabase users table with zero rows. The Module 2 interviewees are the closest 10 people in the world to your ICP - they spent 30 minutes telling you their version of the problem. Inviting them by name is the cheapest first-10-users acquisition the course will name.
+
+If you need more than 10 users on the MVP before running Ch 5.1's survey, the recruitment playbook in [Ch 2.3 (a + b)](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) is the same one you use to find them - the message changes from "30 minutes of your time" to "try the live tool for a week, free."
+
+## What "ship the shed" means in practice
+
+The [Module 4 post](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/) walked through Rob Walling's [shed-vs-skyscraper warning](https://podcast.creatorscience.com/rob-walling/): you build the smallest structure that does the job, and you do not pour skyscraper foundations for it. Lovable + Supabase + Stripe is the shed.
+
+| **Inside the envelope** | **Outside the envelope** |
+|---|---|
+| One workflow, one persona, one happy path | Multiple parallel workflows or personas |
+| Database fits on one Supabase project | Complex data model needing sharding |
+| No real-time features | Real-time multiplayer or live updates |
+| No compliance scope | Regulated industry (healthcare, finance, PII) |
+| AI inference costs pennies per request | AI inference at scale (daily cost >$10) |
+| Three core integrations (Lovable/Supabase/Stripe) | Many third-party APIs beyond the three |
+
+Be honest about the trade-off. This stack cannot host every business. It can host yours through the first 10 paying customers, which is the only data point that earns you the right to argue about the next architecture.
+
+## The architectural ceiling - what's coming in Chapter 4.4
+
+The stack holds until it doesn't. Five specific signals tell you the ceiling is close. The next chapter ([Chapter 4.4 - Proactive Ceiling Signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/)) walks through each one with the threshold to watch.
+
+Quick preview: scale beyond roughly 10,000 users, complex data model that no longer fits a single Supabase project, real-time features the auto-generated REST API cannot serve, security or compliance scope that needs an external audit, AI inference at scale where per-request cost crosses pennies. When you see two of these, route to the [hire-track supplementary reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/) or to a [Fractional CTO](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge) for the architecture call. Architecture does not collapse overnight; the warning shows up in the metrics before the customer sees it. Chapter 4.4 names the metrics.
+
+What the stack actually costs, per published vendor pricing:
+
+| Phase | Cost shape | Line items |
+|------|-------|-----------|
+| Start | Free tiers | Free tiers across Lovable, Supabase, Stripe, GitHub |
+| First ship | Per-tool monthly fees | Lovable Pro $25 + Supabase Pro $25 + Porkbun .com ~$10/yr + Resend $20 + Stripe 2.9% + $0.30 per transaction |
+| Post-launch | Scale-tier monthly fees | Lovable Scale $100 + Supabase Pro $25 + Resend $35 + Sentry $26 + monitoring $14 |
+
+The architectural ceiling tends to land at the post-launch tier - at ~10K users, route to Chapter 4.4 or a [Fractional CTO](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge). A hire-a-team build is material monthly burn before revenue; this stack ships the same first 10 paying customers on a fraction of that.
+
+## What to do tomorrow
+
+Three actions, in order. The first two cost $0.
+
+> **Sign up for Lovable + Supabase free tiers** on [lovable.dev](https://lovable.dev) and [supabase.com](https://supabase.com) (Google sign-in). Connect GitHub sync inside Lovable so your code survives subscription cancellation.
+>
+> **Pick ONE feature from your one-page brief's "what you're building" section.** Not three. One. The smallest workflow that solves the validated problem for one persona. Write: "build a [screen] for [persona] to [outcome]."
+>
+> **Generate the UI in Lovable.** Iterate by chatting: rename, resize, reposition. End-of-phase demo: screens click with nothing persisted. Show one human who hasn't read the PRD - watch them try it without a tour.
+
+The [Self-Serve Stack Walkthrough](/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/) artifact is the day-by-day version of this post. Print it before Phase 1. Each day has one small task; each phase has one demo. The artifact removes the "what do I do next" question, which is the reason most small ships actually finish.
+
+Skip the build phases and try to design the perfect first version, and months later you are the one posting in the [salvage-or-rebuild](/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/) thread about a 12,000-line vibe-coded codebase that grew faster than the architecture could hold.
+
+The shed build never grows that large. Either you reach the architectural ceiling on real users (good problem), or you learn the demand is not there (cheap problem). Both outcomes beat the half-built thing.
+
+## When this path ends
+
+Self-serve has a ceiling. The [ceiling-signal monitoring chapter](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) covers the 5 signals that mean it's time to bring in help. When 2+ signals fire in one monthly check, switch to the [hire-track supplementary reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/).
+
+Build the shed first. Lovable + Supabase + Stripe + a $14 domain ships your validated problem to a staging URL on per-vendor pricing. The bigger architecture is a different conversation, and you have not earned the right to have it yet.
+
+## Further reading
+
+- [Part 1: Tools & Setup](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) - the companion page: why these three tools, what each one does, 12 rules, communities, and the AI critic block
+- [Self-Serve Stack Walkthrough](/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/) - day-by-day version of the build plan; print before Phase 1
+- Y Combinator, [Startup School Library + 2026 Founder Resources](https://www.ycombinator.com/library/) - the YC stance on validating without code
+- Rob Walling, [Vibe Coding interview on Creator Science](https://podcast.creatorscience.com/rob-walling/) - the shed vs skyscraper analogy
+- Lovable, [Pricing tiers](https://lovable.dev/pricing) and [community Discord](https://lovable.dev/community)
+- Supabase, [Row-Level Security guide](https://supabase.com/docs/guides/database/postgres/row-level-security)
+- Stripe, [Checkout quickstart](https://docs.stripe.com/payments/checkout/quickstart) and [Pricing page](https://stripe.com/pricing)
+- Drew Falkman, [Vibe Coding Data-Enabled AI Apps on Maven](https://maven.com/)
+
+> **Done when:** All 5 green lights are lit: Stripe in live mode, custom domain wired, 1 ICP user tested the paywall, zero JS errors on the signup+checkout flow, and a weekly demo recording exists.
+>
+> **Founder OS · Artifact #5 of 6:** A live MVP at a real URL, with ownership of every account in your name (per Ch 4.2's Day-1 ownership audit). Save the URL + admin login + the latest weekly demo recording in a `Live MVP` doc in your `Founder OS` folder. Module 5 invites your Module 2 interviewees + smoke-test email list to this URL as the warm seed for the first 10-30 users.
+>
+> **Next click:** [4.4 · Vibe Coding Done Right: 5 Ceiling Signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/)
+>
+> **If blocked:** If stuck on Phase 2 (Supabase), post your schema in the Lovable Discord. If stuck on Phase 3 (Stripe webhook), run a $1 test transaction in Stripe test mode first. The communities section in Part 1 lists free help channels.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Phase 1-3 (6 weeks total with CTO): builds reconciliation dashboard, CTO sets up RLS + Stripe subscriptions + QuickBooks API via n8n. Phase 4: ships to custom domain. 5 green lights passed.
+>
+> **Mia**: Phase 1-3 (4 weeks total): builds tutor search + profiles, sets up parent/tutor login, integrates Stripe booking payments. Phase 4: ships to custom domain. 5 green lights passed.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/cover.png b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/cover.png
new file mode 100644
index 000000000..6a5ed669d
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/index.md b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/index.md
new file mode 100644
index 000000000..c5c76d252
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/index.md
@@ -0,0 +1,218 @@
+---
+title: "4.3a · The Self-Serve MVP Stack: Tools & Setup"
+aliases: ["/blog/self-serve-mvp-stack-lovable-supabase-stripe-2026/"]
+description: "Why Lovable + Supabase + Stripe is the dominant self-serve path. Plain-English roles, vendor pricing, 12 rules, communities. Part 1 of Chapter 4.3."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: self-serve-mvp-stack-lovable-supabase-stripe-2026
+keywords:
+  - lovable supabase stripe stack 2026
+  - non technical founder build mvp self serve
+  - vibe coding stack
+  - ship MVP without engineers
+  - ai assisted build founder
+tags:
+  - founders
+  - non-technical-founder
+  - course-companion
+  - self-serve
+  - vibe-coding
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "4.3a · The Self-Serve MVP Stack: Tools & Setup"
+  og_description: "Why Lovable + Supabase + Stripe is the dominant self-serve path. Plain-English roles, vendor pricing, 12 rules, communities. Part 1 of Chapter 4.3."
+cover_image_alt: "JetThoughts cover showing three hand-drawn stacked layers labeled Lovable, Supabase, and Stripe with arrows linking them, and a sticky note reading Ship by Friday week 4."
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/"
+related_posts: false
+---
+
+> **Module 4 · Step 3a of 4** · Part 1 of 2 · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a Module 4 decision pointing to "self-serve" (from [Ch 4.1](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/)) + a one-page brief (from [Ch 3.1](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/)) + a Day-1 ownership audit passed (from [Ch 4.2](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/))
+>
+> **Output:** the 3 pre-flight rules locked in, tool boundaries clear, ready to start the build in [Part 2 · Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/)
+
+> **Jump to:** [What each tool does](#what-each-tool-does-in-plain-english) · [12 rules checklist](#12-rules-for-a-self-built-poc-done-right) · [Communities](#communities-that-replace-a-co-founder) · [The ship plan](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/#the-ship-plan)
+
+> **TL;DR:** Lovable renders the screens, Supabase stores the data, Stripe charges the card. Three tools, three jobs. Know the boundaries before you open Lovable. Twelve rules keep the build inside the shed. All three tools have free tiers; the chapter's specific cost callouts live where each tool is introduced. Skip to [the ship plan](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/#the-ship-plan) if you already know the stack.
+
+> **This chapter starts FRESH from your one-page brief - do NOT iterate the Chapter 2.4 prototype.**
+>
+> The Chapter 2.4 prototype was a short research artifact: fake data, no auth, viewed by 5 interview subjects, archived after the shape test. This chapter is the production build: real Supabase auth, real Stripe payments, real domain, real users. The first proved users can navigate the SHAPE; the second ships the actual product. Reusing the prototype code multiplies the build effort and ships every research compromise into production.
+
+If you completed Modules 1-4, your default Module 4 path is to build it yourself with Lovable + Supabase + Stripe. Hiring is a ceiling-signal trigger covered in the [supplementary reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/), not a parallel choice.
+
+You will not write code. You will spend two months running [Mom Test calls](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) before you touch a single tool, then start the build after the [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) is locked and the [build-path decision tree](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/) routes you to Path 2.
+
+The stack, top to bottom:
+
+| Layer | Tool | Job | Cost |
+|-------|------|-----|------|
+| UI | Lovable | Render the screens. Send form data down. | $0 free / $25 Pro / $100 Scale |
+| Data | Supabase | Store the user, the row, the file. Listen for Stripe events. | $0 free / $25 Pro |
+| Money | Stripe | Charge the card. Tell Supabase the customer is paid. | 2.9% + $0.30 per transaction |
+
+The buyer opens the staging URL → Lovable shows the screens → Supabase stores the data → Stripe charges the card → a Stripe webhook tells Supabase the row is now paid.
+
+## Why these three tools, and why they slot together
+
+[Y Combinator's current stance](https://www.ycombinator.com/library/) is direct: validate without code, then ship the simplest version with AI tools. Lovable + Supabase + Stripe became the dominant self-serve path because all three tools were built AI-first, their documentation is exhaustive, and the integrations between them are templated to the point of being boring.
+
+Boring is what you want for an MVP. The boring path lets one non-technical founder ship the full loop (signup, paid onboarding, the one feature that solves the validated problem) without ever opening a terminal.
+
+The cost to disprove your hypothesis is vendor free tiers and the small per-tool monthly fees in the cost table above. The cost to prove it is the same.
+
+> **Alternative: $0 Concierge MVP (no-code Wizard of Oz).** If you want more demand evidence before committing to Lovable code, run a Concierge MVP first: **Tally** (free form) → **Zapier or Make.com** (free routing) → **Airtable or Notion** (free storage). The customer fills the Tally form, Zapier drops the row in Airtable, you process by hand. To the customer it looks automated. Validate willingness-to-pay before committing to the build. All three tools have free tiers. This is a stepping stone, not a replacement; the Lovable + Supabase + Stripe stack is what ships in Part 2.
+
+## M2 prototype vs M4 MVP - different artifacts, different rigor
+
+**You do NOT polish your Module 2 prototype into the MVP. The prototype was throwaway by design. The MVP is built fresh with production rigor - real auth, real Stripe, real domain, real user data.**
+
+The Module 2 clickable prototype (Lovable in 2 hours) tested whether 5 interview subjects could navigate the SHAPE of the solution. It had no real auth, no payment integration, no production domain. Discard it.
+
+The Module 4 MVP is built from the [validated Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) with production rigor: real Lovable build with real Supabase auth + real Stripe + real custom domain + real user data. Different stack composition, different polish bar, different decision criteria.
+
+Side-by-side: the Module 2 throwaway prototype vs the Module 4 production MVP.
+
+| | M2 prototype | M4 MVP |
+|---|---|---|
+| Time | 2 hours | Days to weeks |
+| Auth | None | Supabase auth |
+| Payment | None | Stripe live |
+| Domain | lovable.dev preview | Custom domain |
+| Polish | Sketch-grade | Production-grade |
+| Audience | 5 interview subjects | Real signups + paying customers |
+| Decision | "Should we build this for real?" | "Should we scale this?" |
+
+## What each tool does (in plain English)
+
+Pre-seed founders ask "which framework" before they ask "which job." Three tools, three jobs. The boundaries between them are the only architecture you need to know on day one.
+
+### Lovable - the UI layer
+
+Lovable is an AI-powered builder for the screens. You describe an app in English: *"a dashboard for fitness coaches to log client check-ins, with a weekly export to CSV"*, and Lovable generates a working web frontend with proper component structure, routing, and form validation. Every save deploys to a public staging URL you can paste into a Slack message.
+
+[Lovable's pricing tiers in 2026](https://lovable.dev/pricing) run $0 (Free, capped messages), $25/mo (Pro), $50/mo (Business), and $100/mo (Scale, the tier most paying-MVP founders settle on after the first month).
+
+The key thing it does not do well: heavy backend logic, complex auth flows, anything custom on the database side. That is what Supabase is for.
+
+### Supabase - the data layer
+
+Supabase is managed Postgres + auth + file storage + row-level security in one console. Lovable's built-in storage is fine for a prototype; Supabase is what you connect when you have real users whose data has to survive a redeploy.
+
+The free tier handles up to 50,000 monthly active users and 500MB of database before you have to upgrade. Pro is $25/month and most pre-seed founders never outgrow it before they hit the architectural ceiling.
+
+Supabase auto-generates a REST API and a JavaScript client on top of any table you create, which is what Lovable calls when it needs to read or write a row. [Supabase's 2026 pricing](https://supabase.com/pricing) lists the bands clearly. The auth product replaces 80% of what founders used to pay Auth0 or Clerk for; the row-level security policies replace what a contractor would have hand-coded over two weeks.
+
+### Stripe - the money layer
+
+Stripe processes the payment. The 2026 default integration for a Lovable app is [Stripe Checkout](https://docs.stripe.com/payments/checkout) (a hosted page Lovable can link to with one line) plus a webhook into Supabase that updates the user's subscription status when the charge succeeds.
+
+The fee is the standard [2.9% + $0.30 per transaction](https://stripe.com/pricing) for cards in the US; international, Klarna, ACH, and other rails have their own bands. There is nothing custom about this in 2026. Every founder hits the same Checkout integration; the documentation has been refined over a decade of pre-seed founders running the exact same setup.
+
+### GitHub for version control
+
+Free for solo founders on the Free plan. You will not write much code yourself, but Lovable can sync to a GitHub repo on every save. Two reasons this matters: (a) you have a backup if Lovable goes down or you cancel the subscription, (b) when you eventually hire a contractor or a Fractional CTO, the code is already in a place they can read. Set this up in Lovable's Settings on day one. Skipping this is the most common reason founders we pick up six months later cannot retrieve the source.
+
+> **Module 4 AI critic/simulator block**
+>
+> **What AI can help with at this stage:**
+>
+> **Review your Lovable build against your one-page brief.** Paste your brief's Section 3 into Claude, then paste this prompt:
+>
+> ```text
+> Here is Section 3 of my one-page brief (the outcome-shaped feature list). Based ONLY on this list, name 3 things a Lovable build of this brief would likely include that are NOT in the list. Be specific - feature names, not categories.
+> ```
+>
+> **Audit your Supabase RLS policies.** First, in the Supabase Dashboard, open Table Editor, click each table, click the Definition tab, and copy the SQL shown. Paste all your table definitions into Claude with this prompt:
+>
+> ```text
+> Here are my Supabase table definitions. Which tables lack row-level security (RLS) enabled, and for each one, name the cross-tenant data leak that would result if a logged-in user from Tenant A queried that table. If you cannot determine the leak without seeing the application code, respond with "NEED CODE: [which file]" rather than guessing.
+> ```
+>
+> **Walk the happy path from static input.** Open Lovable in your browser, take 3 screenshots (sign-up screen, the one core-action screen, and the paywall / payment screen) and paste them into Claude one by one along with Section 3 of your brief. Prompt:
+>
+> ```text
+> Here is the signup-to-paywall happy path from my MVP plus the outcome-shaped feature list it was meant to ship. For each screenshot, name any screen, button, or field that is NOT in the outcome list - these are scope leakage you can cut before launch. If a screen looks aligned to the outcome, say so explicitly.
+>
+> If you cannot identify any scope leakage in a screenshot, respond with "NO SCOPE LEAK FOUND" - that is a valid finding, not a failure.
+> ```
+>
+> Claude cannot audit a URL it cannot browse; it CAN audit screenshots you provide.
+>
+> **What AI cannot prove or substitute:**
+> - Whether real users can navigate the workflow (only uncoached ICP users can)
+> - Whether the Stripe webhook idempotency is correct (only test-mode charges can)
+> - Whether the architecture will hold at scale (only real traffic + Ch 4.4 ceiling signals can)
+>
+> **The real gate:** 5 green lights (Phase 4 exit criteria in [Part 2](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/)) + weekly demo to one non-PRD-reader human.
+
+## 12 rules for a self-built PoC done right
+
+> **How to read this list.** 3 rules need to be true BEFORE you open Lovable. The rest fire inline during the Phase 1-4 build in [Part 2](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/). If you internalize ONLY the 3 pre-Lovable rules + the Phase 4 exit criteria, you ship a working MVP. The other rules are inline reminders, not a homework checklist.
+
+Synthesis of every rule scattered across Module 4 and the supplementary references. Print this page, tape it next to the laptop, re-read before every weekly demo.
+
+**Before you open Lovable - the 3 load-bearing pre-flight rules.** Rules **1, 2, and 6** in the list below are the ones that must be true on day zero. Rule 1 (one-page brief passed the Ch 3.2 quality-gate) keeps Phase 1 prompts from generating a 47-button admin panel. Rule 2 (one workflow, one persona, one happy path) keeps the build inside the shed. Rule 6 (GitHub sync turned on in Lovable Settings on day 1) keeps your source recoverable if Lovable drops it. Get those 3 right and the rest read as inline checks while you build. Get them wrong and the other 9 cannot save the project.
+
+1. **Start from a one-page brief that passed the Ch 3.2 quality-gate.** If Section 3 is feature-shaped, fix it before you open Lovable. Feature-shaped briefs produce 47-button admin panels.
+2. **One workflow, one persona, one happy path.** No multi-tenancy, no admin dashboard, no settings page on day one. Build the shed (Rob Walling's analogy), not the house.
+3. **Strict layer boundaries**: Lovable renders screens, Supabase stores data, Stripe collects payment. Do not let Lovable hand-roll auth; do not let Supabase render a UI; do not let Stripe become the source of truth for user state.
+4. **Weekly demo to one non-PRD-reader human.** Spouse, advisor, dog if necessary. Keep a ship-something-visible cadence every week. The demo IS the data; the screens are not.
+5. **Do NOT iterate the Ch 2.4 throwaway prototype.** Start the M4.3 build fresh from your one-page brief. The prototype answered "do users know what to click"; the MVP answers "do users pay."
+6. **Set up GitHub sync in Lovable Settings on day 1.** Lovable can drop the work; GitHub is your backup. Skipping this is the #1 reason rescued founders cannot retrieve their source.
+7. **Enable Row-Level Security on every Supabase table from day 1.** RLS is the rule that says "Coach A can only read Coach A's rows." Skipping it ships the cross-tenant data leak that ends pilots (see Ch 4.4 Signal 4).
+8. **Stripe webhook handler must be idempotent.** Idempotent means "safe to run twice without breaking anything" - Stripe sometimes sends the same payment event more than once, and your handler must not double-charge or double-activate. Check `WHERE event_id = $1 AND processed = true` before re-running the update. (See production hardening section of [hire-track reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#production-hardening-checklist-what-your-fractional-cto-will-look-for) for details.)
+9. **Budget envelope: vendor free tiers + per-tool monthly fees.** Lovable free, Supabase free, Stripe transaction fees, domain registration. Upgrade Lovable to $25/mo Pro only when build velocity demands it.
+10. **Ship before scope creep, then a short stabilization phase.** Build the smallest end-to-end thing, then a stabilization phase before paid-pilot conversations. Sits inside the multi-month journey to first paying customer.
+11. **Monthly Ch 4.4 ceiling-signal check once the live MVP is up.** Even if everything is green, the habit catches the 5 architectural break-points before they become rebuilds.
+12. **Do not scale a Lovable stack past ~5K users or 2 ceiling signals at red.** When you hit either limit, graduate to a Fractional CTO bridge (see [hire-track reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge)). The shed is not the house; pouring skyscraper foundations into a shed slab does not build a skyscraper.
+
+Each of the 12 rules is taught in depth somewhere across this chapter, the [self-serve stack walkthrough](/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/), [Ch 4.4 ceiling signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/), or the [hire-track supplementary reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/). The list above is the index; the surrounding chapters are the depth.
+
+## Communities that replace a co-founder
+
+You are about to hit a wall: a Lovable prompt that produces the wrong component, a Supabase RLS policy that locks out your own admin user, a Stripe webhook that fires twice for one charge. Five communities answer most of these in under an hour, free.
+
+| Community | Members / Tiers | Best for | Cost |
+|-----------|-----------------|----------|------|
+| **[Lovable Discord](https://lovable.dev/community)** | 160K+ (2026) | Real-time UI troubleshooting; Lovable team answers in channels; hosts monthly hackathons | Free |
+| **[Indie Hackers](https://www.indiehackers.com/)** | Bootstrap-focused | Honest revenue posts + shipping logs; Friday-demo accountability rhythm | Free + paid tier (varies) |
+| **[No Code Founders (NCF Slack)](https://www.nocodefounders.com/)** | Full no-code stack (Bubble, Webflow, Glide, Softr) | If Lovable is wrong for your UI shape; worth membership even if you stay on Lovable | Free membership |
+| **r/nocode + r/vibecoding (Reddit)** | Free, indexable | Lower signal-to-noise than Slack; search before post | Free |
+| **[Buildspace + Maven cohorts](https://maven.com/)** | Drew Falkman's "Vibe Coding Data-Enabled AI Apps" (~$1K) | Peer cohort + office hours; for founders who ship harder under deadline | ~$1,000 |
+
+None of these is JetThoughts. None of them sells you a service. They are the founder peer pool the YC stance on co-founders [now points at](https://www.ycombinator.com/library/) instead of the 50%-equity hire.
+
+## Further reading
+
+- [Part 2: Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/) - the companion page: 4 build phases, exit criteria, shed-vs-skyscraper, and the architectural ceiling
+- Y Combinator, [Startup School Library + 2026 Founder Resources](https://www.ycombinator.com/library/) - the YC stance on validating without code and the changing role of the technical co-founder
+- Rob Walling, [Vibe Coding interview on Creator Science](https://podcast.creatorscience.com/rob-walling/) - the shed vs skyscraper analogy that frames the architectural ceiling. 35-minute listen.
+- Lovable, [Pricing tiers](https://lovable.dev/pricing) and [community Discord](https://lovable.dev/community)
+- Supabase, [Pricing tiers](https://supabase.com/pricing) and [Row-Level Security guide](https://supabase.com/docs/guides/database/postgres/row-level-security)
+- Stripe, [Checkout quickstart](https://docs.stripe.com/payments/checkout/quickstart) and [Pricing page](https://stripe.com/pricing)
+- DHH, [The One-Person Framework](https://world.hey.com/dhh/the-one-person-framework-711e6318)
+- Veracode, [GenAI Code Security Report 2025](https://www.veracode.com/blog/genai-code-security-report/)
+
+> **Done when:** You understand what each of the three tools does, why the boundaries between them matter, and the 3 pre-flight rules are locked in (brief quality-gate passed, one workflow scoped, GitHub sync on). Ready to open [Part 2: Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/).
+>
+> **Next click:** [4.3b · The Self-Serve MVP Stack: Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/)
+>
+> **If blocked:** If the tools don't click yet, skim the Lovable Discord or Indie Hackers to see real founders shipping with this exact stack. The communities section above lists free help channels.
+
+> **Stuck? Most first-timers stall here:** the 12 rules list feels like a homework checklist and you haven't opened Lovable yet. **Fix:** read ONLY the 3 pre-Lovable rules at the top of the list. The other 9 fire inline during the build - they're reminders, not prerequisites. Open Lovable and paste your brief's Section 3. Ship one screen tonight.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Fractional CTO greenlights the self-serve stack: Lovable (UI), Supabase (auth + DB), Stripe (payments), n8n (QuickBooks API connector). CTO writes the RLS policies and API patterns. Tomas builds the UI.
+>
+> **Mia**: Picks the full self-serve stack: Lovable (UI), Supabase (auth + DB), Stripe (booking payments). Reads the 12 rules checklist. Passes all 12 rules. Starts building.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/cover.png b/content/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/cover.png
new file mode 100644
index 000000000..85bcf6256
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/index.md b/content/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/index.md
new file mode 100644
index 000000000..41f7d95a7
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/index.md
@@ -0,0 +1,467 @@
+---
+title: "Self-Serve Stack Walkthrough: Lovable + Supabase + Stripe in 4 Weeks"
+aliases: ["/blog/self-serve-stack-walkthrough/"]
+description: "Step-by-step walkthrough of shipping a B2B SaaS MVP on Lovable + Supabase + Stripe in 4 weeks. Free."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: self-serve-stack-walkthrough
+keywords:
+  - lovable supabase stripe walkthrough
+  - 4 week mvp ship plan
+  - self serve mvp template
+  - vibe coding day by day
+  - non technical founder ship plan
+tags:
+  - founders
+  - non-technical-founder
+  - template
+  - course-companion
+  - self-serve
+  - vibe-coding
+categories: ["Templates"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/"
+related_posts: false
+---
+
+📋 Template companion to [Chapter 4.3a · The Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) and [4.3b · Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/). Print Monday morning. Ship by Friday week 4.
+
+# Self-Serve Stack Walkthrough - 4 Weeks, 3 Tools, 1 Staging URL
+
+*Day-by-day tasks for shipping the Lovable + Supabase + Stripe MVP. Cross off as you go.*
+
+**The 4-week roadmap:**
+
+1. **Week 1 - Lovable + the UI** (no backend yet). Friday demo: clickable staging URL.
+2. **Week 2 - Supabase + auth** (real signup works). Friday demo: first real signup persists.
+3. **Week 3 - Stripe + checkout** ($1 test transactions). Friday demo: end-to-end paid flow.
+4. **Week 4 - staging URL + 5 ICP users click**. Friday demo: live data review from 5 prospects.
+
+## Why this exists
+
+A two-person co-founder team we spoke with last month spent eleven weeks on Lovable before they had a single paying user. Not because the tool was wrong - because they kept rebuilding the same first screen from different prompts every Monday. They had no plan. Each week started with "let's polish the dashboard" and ended with the same broken Stripe webhook nobody had wired. By the time they came up for air, the runway-to-paying-customer math no longer worked. We walked them through the four-week plan below on a Friday afternoon. They restarted from week 1, ignored the eleven weeks of half-built screens, and shipped a paid signup flow on day 23. The first dollar arrived on day 31. The plan is the difference between four weeks of progress and eleven weeks of polish.
+
+The tool stack does not ship the MVP. The schedule does.
+
+## How to use this
+
+Print one side of paper. Tape it to the wall next to your monitor. Each Monday morning, read the week's day-by-day list, calendar the four work blocks (one per day, 90 minutes each is enough), and pick the Friday demo audience. Each Friday, do the demo and write the one-line result at the bottom of the week. If a Friday demo fails the goal, repeat the week. Do not advance until the week's demo lands.
+
+Total time budget: 90 minutes per day, 5 days a week, for 4 weeks = 30 hours of work. Plus ~$90 in tool subscriptions and a domain across the four weeks. The plan ships a public staging URL with paid signup by the end of week 4.
+
+If a week takes you 7 days instead of 5, you are normal. If a week takes 14 days, the prompt you wrote on Monday was wrong; rewrite it before continuing.
+
+## Pre-flight checklist (the Sunday before week 1)
+
+- [ ] **one-page brief finalized** ([template](/course/tech-for-non-technical-founders-2026/vibe-prd-template/))
+- [ ] **Validated Problem Statement filled in** ([template](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/))
+- [ ] **[Build Path Decision Worksheet](/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/) verdict = Path 2 (Self-serve)**
+- [ ] **One Lovable account created** (Free tier OK to start; upgrade to Pro $25 in week 2)
+- [ ] **One Supabase project created** (Free tier OK through week 4)
+- [ ] **One Stripe account created** in test mode (verify the email)
+- [ ] **One GitHub account** (Free plan is fine for solo founder)
+- [ ] **Calendar blocks** scheduled: Mon-Fri 9am-10:30am, 4 weeks straight
+- [ ] **Friday demo audience chosen** for each week (spouse, advisor, peer founder, ICP prospect - rotate)
+
+If any pre-flight box is unchecked, do that first. The four-week plan does not work without the inputs.
+
+## Week 1 - Lovable + the UI (no backend yet)
+
+Goal: a clickable UI on a public staging URL. No data persists. Friday demo: a non-PRD reader navigates the screens without a tour.
+
+### Monday - write the first prompt
+
+Open the one-page brief's "what you're building" section. Paraphrase the smallest workflow into a single Lovable prompt. Sample (fitness coaching SaaS):
+
+```text
+Build a dashboard for a fitness coach.
+- Top bar: coach name + log out
+- Left sidebar: list of clients (name, last check-in date,
+  status badge: green if checked in this week, red if not)
+- Main pane (when a client is clicked): client detail page
+  with a check-in form (date, weight, notes, 3-photo upload)
+- Save button. Toast notification on save.
+```
+
+Paste into Lovable. Iterate by chatting: "make the badges bigger," "move the check-in form to the right side." Stop when the screen matches the PRD's screenshot mock.
+
+### Tuesday - second screen + signup placeholder
+
+Add the signup screen and a paywall placeholder (no real auth yet). Sample prompt:
+
+```text
+Add a signup page at /signup with email + password fields
+and a "Start 14-day trial" button. Add a paywall page at
+/upgrade that says "Your trial ends in N days" and has a
+"Pay $29/month" button. Both buttons can be no-op for now.
+```
+
+By end of day: signup -> dashboard -> client detail -> check-in form. All clickable. Nothing saved.
+
+### Wednesday - second workflow screen
+
+Add the export-to-CSV screen (or whatever your second core screen is from the PRD). One screen per day in week 1; you are buying yourself the iteration room.
+
+### Thursday - polish + GitHub sync
+
+Read every screen aloud. Anything that needs more than 5 seconds to understand: rewrite the prompt. Then go to Lovable Settings, connect a new GitHub repo, push everything. Verify the commit lands on github.com.
+
+### Friday - demo to a non-PRD reader
+
+Send the staging URL to someone who has not read the one-page brief. Watch them try to use it (over screen-share or in-person). Do not narrate. Note every place they pause for more than 3 seconds. Those are your week-1 bugs in design, not in code.
+
+**Result line (fill in)**: ____________________________________________
+
+> **Week 1 outcome**: a clickable UI on a public staging URL, GitHub-synced, that a non-PRD reader can navigate without a tour.
+
+## Week 2 - Supabase + auth (real signup works)
+
+Goal: a real user signs up, lands in the dashboard, sees their data persist across a refresh. Friday demo: your spouse or first ICP signs up, you watch their row appear in the Supabase console live.
+
+### Monday - schema design (90 minutes max)
+
+Open the Supabase Table Editor. For the fitness coach example, create three tables:
+
+```sql
+-- Coaches (the user account)
+create table coaches (
+  id uuid primary key default uuid_generate_v4(),
+  email text unique not null,
+  full_name text,
+  subscription_status text default 'trial',
+  trial_ends_at timestamptz default now() + interval '14 days',
+  created_at timestamptz default now()
+);
+
+-- Clients (each coach has many)
+create table clients (
+  id uuid primary key default uuid_generate_v4(),
+  coach_id uuid references coaches(id) on delete cascade,
+  full_name text not null,
+  created_at timestamptz default now()
+);
+
+-- Check-ins (each client has many)
+create table check_ins (
+  id uuid primary key default uuid_generate_v4(),
+  client_id uuid references clients(id) on delete cascade,
+  check_in_date date not null,
+  weight_kg numeric,
+  notes text,
+  photo_urls text[],
+  created_at timestamptz default now()
+);
+```
+
+Cap the schema at 3-5 tables for week 2. Anything more is scope creep.
+
+### Tuesday - enable Row-Level Security on every table
+
+In Supabase, click each table > Authentication > Enable RLS. Then add the policy: a coach can only read/write rows where `coach_id = auth.uid()`. Sample policy on `clients`:
+
+```sql
+create policy "coaches see only their clients"
+  on clients for all
+  using (coach_id = auth.uid());
+```
+
+Without RLS, your first bug ships every coach's data to every other coach. With RLS, the bug is impossible by construction. This is the single most important thing you do in week 2.
+
+### Wednesday - connect Lovable to Supabase
+
+In Lovable: install the Supabase integration (Settings > Integrations). Paste the project URL and anon key. Update your signup screen prompt:
+
+```text
+Wire the signup page to Supabase auth using the JS client.
+On submit: call supabase.auth.signUp() with email + password.
+On success: insert a row into the `coaches` table with
+the new auth.uid() and the email. Redirect to /dashboard.
+```
+
+Do the same for the dashboard data: `supabase.from('clients').select()` filtered by the logged-in coach.
+
+### Thursday - data persistence end-to-end
+
+Sign up as a fake coach in Lovable's preview. Add three fake clients. Refresh the page. Data should still be there. Open the Supabase console: rows are visible. Drop the database connection in Lovable, refresh: error. Reconnect, refresh: data back. You have proven the data lives in Supabase, not in Lovable's local state.
+
+### Friday - first real signup
+
+Send the staging URL to your spouse (or one ICP peer). Ask them to sign up with their real email. Open the Supabase console next to your screen. Watch the row appear. That is the demo.
+
+**Result line (fill in)**: ____________________________________________
+
+> **Week 2 outcome**: a real signup persists across refresh, RLS is on, and the first row appears in the Supabase console live during the Friday demo.
+
+## Week 3 - Stripe + checkout ($1 test transactions)
+
+Goal: a user signs up, hits the paywall after the trial, pays $1 in Stripe test mode, lands on the paid dashboard. Friday demo: you walk through your own flow, end to end, with a $1 charge that clears.
+
+### Monday - one product, one price, in Stripe test mode
+
+In the Stripe dashboard (Products > Add product):
+
+- **Name**: Coach Dashboard Monthly
+- **Price**: $29.00 / month, recurring
+- **Trial**: not configured here (we handle the 14-day trial in our own `coaches.trial_ends_at` column; Stripe just charges immediately when the user clicks Pay)
+
+Copy the Price ID (`price_1...`).
+
+### Tuesday - Stripe Checkout integration
+
+Update Lovable's paywall prompt:
+
+```text
+On the /upgrade page, change the "Pay $29/month" button to
+create a Stripe Checkout session via supabase.functions.invoke('create-checkout', { priceId, coachId }) and redirect to the returned URL.
+```
+
+In Supabase Edge Functions, create one function `create-checkout` that calls `stripe.checkout.sessions.create()` with the price ID, the coach's ID in `client_reference_id`, and the success/cancel URLs pointing back to the staging URL. Stripe documents this end-to-end at [docs.stripe.com/checkout](https://docs.stripe.com/payments/checkout/quickstart).
+
+### Wednesday - the webhook that flips paid status
+
+Create a second Supabase Edge Function `stripe-webhook` that listens for `checkout.session.completed` events and updates `coaches.subscription_status = 'active'` for the coach in `client_reference_id`. Add the webhook URL to Stripe's developer dashboard. Test by triggering the event from Stripe's CLI:
+
+```bash
+stripe trigger checkout.session.completed
+```
+
+Watch the row in Supabase flip from `trial` to `active`.
+
+### Thursday - end-to-end with a real test card
+
+Sign up as a fake coach. Skip the trial wait by manually editing `coaches.trial_ends_at` to yesterday in the Supabase console. Hit the paywall. Click Pay. Use Stripe's test card `4242 4242 4242 4242`, any future expiry, any CVC. Land on the paid dashboard. Verify the row in Supabase says `active`. Then test the failure path with `4000 0000 0000 0002` (declined) - user should land back on /upgrade with a friendly error. Reference: [Stripe testing docs](https://docs.stripe.com/testing).
+
+### Friday - the loop demo to yourself
+
+Walk through the full flow in test mode: signup -> dashboard -> add a client -> log a check-in -> hit paywall -> pay $1 (use a different test price for $1 if you like) -> land on paid dashboard. Time the whole thing. If it takes more than 5 minutes, the friction is too high; rewrite the screens.
+
+**Result line (fill in)**: ____________________________________________
+
+> **Week 3 outcome**: a paid signup flow end-to-end in test mode, webhook verified, `subscription_status` flips from `trial` to `active` within 10 seconds of a $1 charge.
+
+## When the webhook doesn't fire (troubleshooting in 5 minutes)
+
+The single most common Week-3 stall: you trigger a Stripe test charge, the dashboard says the charge succeeded, but the row in Supabase never flips to `active`. Walk this table in order; stop at the first row that matches your symptom:
+
+| # | Symptom | Likely cause | 60-second fix |
+|---|---------|--------------|---------------|
+| 1 | Stripe dashboard shows the event, but nothing fired in your Supabase logs | Stripe CLI not running OR webhook endpoint URL has a typo | Re-run `stripe listen --forward-to https://.supabase.co/functions/v1/stripe-webhook` in a terminal. Copy the URL EXACTLY into the Stripe webhook dashboard - one trailing slash or missing `https://` kills it |
+| 2 | Logs show `Webhook signature verification failed` | Signing secret in your Supabase Edge Function environment variable does NOT match the secret Stripe is using | Open Stripe dashboard → Developers → Webhooks → click your endpoint → click "Signing secret" → "Reveal." Copy the value (starts with `whsec_`). In Supabase: Edge Functions → your function → Settings → Environment variables. Replace the `STRIPE_WEBHOOK_SECRET` value with this exact string. Redeploy the function. Test mode and live mode have DIFFERENT secrets - if you went live without updating, this is why |
+| 3 | Logs show the event arrived but no row updated | The `checkout.session.completed` payload's `client_reference_id` field is empty OR doesn't match any `coaches.id` | In your Stripe Checkout creation code, confirm you are passing `client_reference_id: coach.id` when generating the session. The CLI's default trigger sends a synthetic event with no `client_reference_id` - test with a real signup flow, not `stripe trigger`, to validate this path |
+| 4 | The right event subscription isn't selected in Stripe | You created the webhook endpoint but only subscribed to `payment_intent.*` events, not `checkout.session.completed` | Stripe dashboard → Webhooks → your endpoint → "Listen to" → ensure `checkout.session.completed` is checked. Stripe defaults to a curated subset; this event is sometimes off by default |
+| 5 | Logs show the function returned 200, row updated, but the UI still shows "trial" | Your frontend is caching the old subscription status | Hard-refresh the page (Cmd+Shift+R). If status is correct after refresh, the issue is Lovable's data-fetch caching - add a 30-second refetch interval on the dashboard query, or refetch on focus |
+
+If none of the 5 rows match: paste the full Stripe event payload + your Edge Function code into Claude / ChatGPT with the prompt "this Stripe webhook handler isn't updating my Supabase row - what am I missing?" - the AI will spot the gap 80% of the time. For the remaining 20%, the [Stripe webhook debugging guide](https://docs.stripe.com/webhooks/debugging) covers the long-tail signature, replay, and idempotency cases.
+
+> **Idempotency reminder**: every webhook handler must be safe to fire twice on the same event. Stripe retries on any non-2xx response (network blip, timeout, deploy mid-call) and the second hit must not double-charge or double-update. Check `WHERE event_id = $1 AND processed = true` at the top of the handler; if the row exists, return 200 immediately without re-running the update logic. This is one extra query; it prevents the support ticket that says "I got charged twice."
+
+## Week 4 - staging URL + 5 ICP users click
+
+Goal: a public domain pointing at the staging URL, 5 ICP prospects sent the link, real signup data logged. Friday is the data review.
+
+### Monday - go live (Stripe out of test mode)
+
+Switch Stripe to live mode. Recreate the product + price in live (Stripe does not auto-promote test data). Update the live API keys in your Supabase Edge Functions environment variables. Verify webhook signature secrets are the live ones, not the test ones. Run one $1 charge against your own credit card to confirm money actually moves. Refund the dollar in the Stripe dashboard.
+
+### Tuesday - buy a domain, point at staging
+
+Buy a domain on [Porkbun](https://porkbun.com/) ($10-$14 for a `.com`) or your registrar of choice. Never let a tool hold your domain. Add a CNAME record pointing your domain at the Lovable staging URL (Lovable's docs cover this in Settings > Custom Domain). Wait for DNS to propagate (5-30 minutes). Verify the domain loads the staging URL.
+
+### Wednesday - send to 5 ICP prospects
+
+Pick 5 names from your [Module 2 outreach list](/course/tech-for-non-technical-founders-2026/outreach-sequence-template/). Send each a 3-line cold message:
+
+```text
+Hey [name] - the workflow you described last month
+(logging client check-ins by hand on a spreadsheet) is
+now a tool. 5-minute first-use, $29/month after a 14-day
+trial. URL: [your domain]. Honest reactions only.
+```
+
+Send between 9am and 10am their local time on a Wednesday for highest reply rate. Do not send 25 in a panic; 5 well-targeted ones beat 25 sprayed.
+
+### Thursday - watch the analytics
+
+Wire Plausible (or PostHog free tier) to the staging URL. Watch session recordings on every signup. Write down: where do they pause? Where do they leave? What do they click that doesn't do anything?
+
+### Friday - the data review
+
+Read the metrics. Three honest outcomes:
+
+- **0 of 5 click**: the cold message is wrong, not the product. Rewrite the message, send to 5 new names next Monday.
+- **5 click but 0 sign up**: the landing screen is wrong. Rewrite the first paragraph above the signup form. Re-test next week.
+- **5 sign up but 0 pay after trial**: the paywall position or price is wrong. Try moving the paywall earlier (charge for the second core feature instead of the first), or test a lower price ($19 instead of $29).
+
+The data picks the next week. Do not iterate on what you imagine; iterate on what the 5 actual people did.
+
+**Result line (fill in)**: ____________________________________________
+
+> **Week 4 outcome**: a live domain pointing at the staging URL, 5 ICP prospects sent the link, and real signup/click/pay metrics on the table for Friday's data review.
+
+## Sample Lovable prompts (verbatim, copy-paste)
+
+Five prompts that ship 80% of a typical pre-seed B2B SaaS MVP. Adapt the persona/object names to your domain.
+
+```text
+Prompt 1 (signup):
+Add a signup page at /signup with email + password fields
+and a "Start 14-day trial" button. Wire to supabase.auth.
+signUp(). On success, insert a row into `coaches` with
+the new auth.uid() and the email. Redirect to /dashboard.
+
+Prompt 2 (list view):
+Build a dashboard at /dashboard with a left sidebar listing
+clients (name, last_check_in_date, status badge: green if
+checked in this week, red if not). Fetch from
+supabase.from('clients').select('*, check_ins(check_in_date)
+.order(check_in_date desc).limit(1)').
+
+Prompt 3 (detail view):
+On /clients/:id, show client name, last 4 check-ins (date,
+weight, notes, 1 thumbnail per check-in), and a "New
+check-in" button.
+
+Prompt 4 (form view):
+On /clients/:id/check-in, show a form with date (default
+today), weight_kg (number), notes (textarea), and 3-photo
+upload (use Supabase storage bucket `check-in-photos`,
+RLS policy: only the owning coach can read/write).
+Save inserts into `check_ins` table.
+
+Prompt 5 (paywall):
+On /upgrade, show "Your trial ends in N days. Continue
+for $29/month." with a "Pay" button. Wire the button to
+supabase.functions.invoke('create-checkout', { priceId,
+coachId }) and redirect to the returned URL.
+```
+
+*See the [Appendix](#appendix-reference-code) for the full SQL schema and the Stripe integration checklist.*
+
+## What good looks like vs what bad looks like
+
+**Schema design**
+
+> Bad: *15 tables, three of which are `users`, `accounts`, and `organizations` because the founder read a SaaS architecture blog post once.*
+
+> Good: *3 tables (`coaches`, `clients`, `check_ins`) - one for the user, one for the thing the user manages, one for the action the user takes. The PRD lists exactly one user persona and one core workflow. The schema reflects that.*
+
+The bad answer is over-modeled for an imagined future scale. The good answer fits the validated problem from the PRD. You add the fourth table when a real customer needs it, not when you imagine they might.
+
+**Lovable prompt style**
+
+> Bad: *"Build me a SaaS dashboard."*
+
+> Good: *"Build a dashboard for a fitness coach. Top bar: coach name + log out. Left sidebar: list of clients with green/red status badges based on last check-in date. Main pane shows the selected client's detail and a check-in form. Save button shows a toast on success."*
+
+The bad prompt forces Lovable to guess at a hundred details, half of which will be wrong, and you spend two days undoing them. The good prompt is the screenshot-in-words from your PRD. Lovable does the right thing on the first try about 80% of the time when the prompt is this specific.
+
+**Stripe webhook handling**
+
+> Bad: *Trust the redirect from Stripe Checkout (`?session_id=...`) to flip the user to paid. Skip the webhook because "the redirect already handles it."*
+
+> Good: *Wire the `checkout.session.completed` webhook from Stripe to Supabase. Verify the signature with the webhook secret. Only flip `subscription_status = 'active'` when the webhook fires. Treat the redirect as UX only, not as truth.*
+
+The bad pattern ships an MVP where any user with the right URL pattern can fake their own paid status. The good pattern uses Stripe as the source of truth. Skipping webhook signature verification is the second most common Stripe security bug. Lovable will not catch this for you. Wire it correctly on day 1 of week 3.
+
+## Common mistakes (and how to avoid them)
+
+- **Skipping Row-Level Security in Supabase.** Every coach sees every coach's data the first time you forget. Enable RLS on every table the day you create it. Write the policies before you write the first row of seed data.
+- **Letting Lovable hold your domain.** Buy the domain on a registrar you control (Porkbun, Cloudflare, Namecheap). Point it at Lovable via DNS. If you cancel Lovable, your domain still points at whatever you put behind it next.
+- **Skipping the GitHub sync.** Lovable can sync to GitHub on every save. Set this up on day 1 of week 1. The day you cancel the subscription is not the day to discover your code only lives inside Lovable's UI.
+- **Building 5 features instead of 1.** The four-week plan ships ONE workflow end-to-end. The second feature comes after the first 5 ICP users have clicked through the first one. Skip this rule and you're the founder who spends 11 weeks on Lovable with 4 half-built features and no paid signups.
+- **Trusting the Stripe redirect instead of the webhook.** The webhook is the truth. The redirect is UX. Verify the webhook signature.
+- **Demoing only to friends.** Friends will be polite. The Friday week 4 demo must include at least 3 ICP prospects (not friends, not advisors, not your spouse). Their reaction is the data; everyone else is a warm-up.
+- **Iterating on imagined feedback.** When you finish week 4 and only 1 of 5 clicked, the temptation is to "improve the dashboard." Do not. Iterate on the metric that failed: the click rate (rewrite the cold message), the signup rate (rewrite the landing screen), or the paid rate (rethink the paywall position). Imagined improvements ship the same MVP forever.
+
+## What to do after week 4
+
+- **If 1+ paid signups**: continue. The hypothesis is alive. Build the second feature in weeks 5-8 using the same one-feature-per-month rhythm. Re-read the [three-questions standup chapter](/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/) for the weekly oversight rhythm once you bring in a contractor.
+- **If 0 paid signups but 3+ signups**: the product clicks but the price or the paywall is wrong. Run two A/B tests in week 5: lower price ($19 vs $29), and earlier paywall (paid from day 1 vs 14-day trial). Pick the winner. Re-send to 5 new ICP prospects.
+- **If 0 signups**: the cold message and the landing screen are both wrong, OR the [Module 2](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) validation was a false positive. Re-read your Mom Test transcripts. Are the buyers who said "yes I'd pay" the same buyers ignoring your cold message? If yes, the validation was polite, not real. Loop back to Module 2 for ten more interviews before you build feature two.
+- **Watch for the architectural ceiling**: when any of the [5 ceiling signals](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/) appears (covered in detail in Chapter 4.4), pause feature work and route to the [Fractional CTO bridge](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge). The shed does not collapse overnight, but you stop adding load once you see the signal.
+
+If you want the doctrine in long form, [Chapter 4.3a](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) walks through what each tool does, the role boundaries, the cost reality, and the architectural ceiling preview.
+
+## Appendix - reference code
+
+### Sample Supabase schema (verbatim, copy-paste)
+
+```sql
+-- Run in Supabase SQL editor in order
+
+create extension if not exists "uuid-ossp";
+
+create table coaches (
+  id uuid primary key default uuid_generate_v4(),
+  email text unique not null,
+  full_name text,
+  subscription_status text default 'trial',
+  trial_ends_at timestamptz default now() + interval '14 days',
+  stripe_customer_id text,
+  created_at timestamptz default now()
+);
+
+create table clients (
+  id uuid primary key default uuid_generate_v4(),
+  coach_id uuid references coaches(id) on delete cascade,
+  full_name text not null,
+  created_at timestamptz default now()
+);
+
+create index clients_coach_id_idx on clients(coach_id);
+
+create table check_ins (
+  id uuid primary key default uuid_generate_v4(),
+  client_id uuid references clients(id) on delete cascade,
+  check_in_date date not null,
+  weight_kg numeric,
+  notes text,
+  photo_urls text[],
+  created_at timestamptz default now()
+);
+
+create index check_ins_client_id_date_idx
+  on check_ins(client_id, check_in_date desc);
+
+-- Enable RLS on every table
+
+alter table coaches enable row level security;
+alter table clients enable row level security;
+alter table check_ins enable row level security;
+
+-- Policies: a coach sees only their own data
+
+create policy "coaches read self"
+  on coaches for select using (id = auth.uid());
+
+create policy "coaches update self"
+  on coaches for update using (id = auth.uid());
+
+create policy "coaches see own clients"
+  on clients for all using (coach_id = auth.uid());
+
+create policy "coaches see own check-ins"
+  on check_ins for all using (
+    client_id in (select id from clients where coach_id = auth.uid())
+  );
+```
+
+### Stripe integration checklist
+
+- [ ] Stripe account verified (email confirmed)
+- [ ] One product created (your monthly plan), one price (the price your PRD locked in)
+- [ ] Webhook endpoint registered: `https://[your-supabase-project].supabase.co/functions/v1/stripe-webhook`
+- [ ] Webhook events selected: `checkout.session.completed`, `customer.subscription.updated`, `customer.subscription.deleted`, `invoice.payment_failed`
+- [ ] Webhook signing secret stored in Supabase Edge Function environment as `STRIPE_WEBHOOK_SECRET`
+- [ ] Stripe API key (live, secret) stored as `STRIPE_SECRET_KEY` in Supabase Edge Function environment
+- [ ] `create-checkout` Edge Function deployed
+- [ ] `stripe-webhook` Edge Function deployed and verifying signatures (do not skip signature verification - that is the most common Stripe bug we see)
+- [ ] Test card `4242 4242 4242 4242` runs end-to-end in test mode
+- [ ] Failed card `4000 0000 0000 0002` shows a friendly error and lands user back on /upgrade
+- [ ] One real $1 charge runs end-to-end in live mode against your own card, then refunded
+- [ ] `subscription_status` column flips to `active` within 10 seconds of a successful charge
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/airbnb-test.svg b/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/airbnb-test.svg
new file mode 100644
index 000000000..2508304e7
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/airbnb-test.svg
@@ -0,0 +1,59 @@
+
+
+  
+    
+      
+      
+    
+    
+      
+    
+  
+  
+
+  
+  The Airbnb test, applied to your idea
+  Sell the solution. Read the answers. THEN decide whether to build it.
+
+  
+  
+  Step 1
+  A Carrd page.
+  A Stripe checkout.
+  A Notion FAQ.
+  "Annual plan, $1,800/yr"
+  Total time: 4 hours.
+  Total cost: $200.
+
+  
+  
+
+  
+  
+  Step 2
+  Send the link to
+  35 ICP prospects.
+  Watch what happens.
+  7 reply. 5 ask questions.
+  3 click checkout.
+  2 pay an annual deposit.
+
+  
+  
+
+  
+  
+  Step 3
+  Now you know:
+  demand is real.
+  2 paying buyers waiting.
+  Refund any who want out.
+  Build the smallest version
+  that delivers what you sold.
+
+  
+  
+  If 0 of 35 click: the problem is real,
+  your pitch is wrong. Re-write the page.
+  $0 spent on engineering. 0% sunk cost. 100% information.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/cover.png b/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/cover.png
new file mode 100644
index 000000000..dc2504c19
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/decision-matrix.svg b/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/decision-matrix.svg
new file mode 100644
index 000000000..9756799c0
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/decision-matrix.svg
@@ -0,0 +1,66 @@
+
+
+  
+    
+      
+      
+    
+  
+  
+
+  
+  The 4-Way Build-Path Decision Matrix
+  Pick the smallest path that answers the next question your investors will ask.
+
+  
+  more validated above - less validated below
+  simpler build - backend-heavier build
+
+  
+  
+  
+  1. Validate without code
+  When: no MVP. Single hypothesis untested.
+  First action: post a Carrd page + Stripe link.
+  Cost: $0-$300. Timeline: 1 week.
+  Failure mode: 0 buyers. Pivot before you build.
+  Tools: Carrd, Stripe, Notion, Lovable demo,
+  Calendly, 1 paid LinkedIn ad ($100-200).
+  "Sell the solution before you build it."
+
+  
+  
+  2. Self-serve build (Module 3A)
+  When: validated. Simple MVP. 4-8 weeks free.
+  First action: paste Vibe PRD into Lovable.
+  Cost: $200-$1,200/mo. Timeline: 6-12 weeks.
+  Failure mode: hits ceiling at 5K users.
+  Tools: Lovable + Supabase + Stripe.
+  Architecture review: 1 hour/month with
+  a senior engineer in your network.
+
+  
+  
+  3. Fractional CTO bridge
+  When: validated. Mid complexity. No $200K+.
+  First action: hire 5 hrs/wk Fractional CTO.
+  Cost: $1,600-$4,000/mo. Timeline: 8-16 wks.
+  Failure mode: CTO becomes a coder, not a guard.
+  Use them for: architecture review, PR review,
+  interviewing your first hire, watching costs.
+  $0 equity. Beats a 50%-equity cofounder.
+
+  
+  
+  4. Hire a team (Module 3B)
+  When: backend-heavy. Integrations. Compliance.
+  First action: read SOW clause-by-clause.
+  Cost: $30K-$80K/mo. Timeline: 12-26 weeks.
+  Failure mode: spaceship for the wrong moon.
+  Stack: Rails / Django / Laravel.
+  Own: GitHub org, AWS root, domain registrar.
+  Friday demos start day one.
+
+  
+  Most pre-seed founders belong in box 1 or 2. Most who hire belonged in box 3.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/index.md b/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/index.md
new file mode 100644
index 000000000..6667a3e65
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/index.md
@@ -0,0 +1,208 @@
+---
+title: "4.1 · Should You Hire? The 2026 Decision Tree"
+aliases: ["/blog/should-you-hire-2026-decision-tree/"]
+description: "5 questions route you to one of 4 build paths: validate without code, self-serve, fractional CTO, or hire a team. Module 4 of this course."
+date: 2026-05-13
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: should-you-hire-2026-decision-tree
+keywords:
+  - should non technical founder hire
+  - build vs hire 2026
+  - Airbnb test validate without code
+  - founder build path decision
+tags:
+  - founders
+  - non-technical-founder
+  - course-companion
+  - decision-framework
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "4.1 · Should You Hire? The 2026 Decision Tree"
+  og_description: "5 questions route you to one of 4 build paths: validate without code, self-serve, fractional CTO, or hire a team. Module 4 of this course."
+cover_image_alt: "JetThoughts cover showing a 2-by-2 decision matrix labeled Validate / Self-serve / Fractional CTO / Hire, with a hand-drawn red arrow pointing at the Validate quadrant"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/"
+related_posts: false
+---
+
+> **Module 4 · Step 1 of 4** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a one-page brief + outcome-shaped feature spec (from Module 3)
+>
+> **Output:** a 4-way build-path decision (validate / self-serve / fractional-CTO / hire) + the [Build Path Decision Worksheet](/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/)
+
+> **TL;DR:** Default: self-serve with Lovable + Supabase + Stripe. Hiring is a ceiling-signal trigger, not the first decision. Five questions route you to one of four build paths.
+
+Self-serve with Lovable + Supabase + Stripe is the default for a non-technical founder in 2026. Hiring (whether a full team or a Fractional CTO - a part-time senior engineer who owns architecture but doesn't write the code) is what you do when you hit a specific ceiling signal, not the first decision after the Brief. This chapter is the decision tree: when does the default end, and what triggers the switch?
+
+Pre-seed founders hiring engineering before a single paying customer is confirmed is the most common build-decision mistake at the idea stage. The brief was right - we taught the brief in [The One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) and quality-checked it as outcomes in [Ch 3.2](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/).
+
+The hire is the move that breaks the runway. The skipped step is the cheaper experiment - a smoke test, a clickable prototype, a Concierge MVP - that would have told you whether you need to build at all.
+
+![A hand-drawn 2-by-2 decision matrix with four quadrants labeled Validate without code, Self-serve build, Fractional CTO bridge, and Hire a team. Each quadrant lists a first action, cost band, and timeline.](decision-matrix.svg)
+
+## Your real question: do you need to build at all
+
+> **The decision is not "code or no-code." It is "what evidence do I have that I need to build at all?"**
+>
+> Y Combinator's current position: tools and business models now let solo founders turn ideas into production products in weeks without giving 50% equity to a technical co-founder. The argument is *prove the concept without code first*, not "hire later." Skip this and you burn 6-9 months learning the problem was never real.
+>
+> If you cannot answer with a list of buyers who have already paid you, the answer is: not yet. Stay one box left of where you were about to start.
+
+By the time you reach this chapter, you have already run three validation signals: the smoke test (Module 1) proved that strangers click. The Mom Test interviews (Chapter 2.1 technique applied in Ch 2.3 (a + b) recruitment + interview round) proved the problem is real and felt. The clickable prototype shape test (Chapter 2.4) proved that users can navigate the proposed solution without coaching.
+
+All three are research signals, not builds. The one-page brief (Chapter 3.1) documents what to build. This chapter decides HOW to build it - self-serve, fractional CTO, or hired team.
+
+## The Airbnb test
+
+Brian Chesky and Joe Gebbia did not write code first. They blew up an air mattress in their living room, took photos with a digital camera, posted three nights at $80 on a hand-rolled WordPress page, and waited. Three guests showed up. They made $240.
+
+The product was a website with a payment link. The validation was three strangers paying real money. Paul Graham later wrote about the same instinct in [*Do things that don't scale*](https://paulgraham.com/ds.html): the founders who win are the ones who do the unscalable, manual experiment that proves demand before they industrialize it.
+
+The 2026 version of the Airbnb test takes one afternoon: a Carrd page with a Stripe checkout for an annual plan, a Notion FAQ that explains exactly what the buyer gets, and the link sent to 35 ICP prospects from your [Find 10 People With the Problem](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) outreach list. The result you are watching for is in the next paragraph.
+
+![A 3-step illustration of the Airbnb test: Carrd page with Stripe checkout (Step 1), send link to 35 ICP prospects (Step 2), refund non-buyers and build only what you sold (Step 3). A sticky note at the bottom warns: if 0 of 35 click, the problem is real but your pitch is wrong, rewrite the page.](airbnb-test.svg)
+
+The signal you are looking for is small. Two paying buyers from 35 cold outreach hits is enough to flip the build switch.
+
+We know a B2B SaaS founder who sold five annual contracts at $1,800 each via a Stripe link and a Notion doc before she wrote a line of code. By the time her contractor delivered the v1 web app eight weeks later, she had $9,000 in pre-revenue and a customer-feedback loop already running. The build was constrained by what she had already promised the five buyers, which is the cheapest scope-control mechanism that exists.
+
+Zero clicks from 35 prospects is brutal in the other direction. The problem might be real (you validated it in [Decide What's Next](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/#synthesis-write-down-what-you-heard-decide-whats-next)) but your pitch is wrong, your price is wrong, or the timing is wrong. Find out for $200 instead of $30,000.
+
+## Pick the right building before you commit to build
+
+The decision matrix in this post is the structural-engineer step. Before you commit to building, you decide which building you are putting up - a shed has a different cost ceiling, talent profile, and exit strategy than a commercial building. The mistake is treating them as the same.
+
+> **[Vibe Coding Ceiling Signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/)** - the full shed → house → skyscraper diagnostic, read this after you pick your path to know when to revisit the hire decision.
+
+## The 4-way decision matrix
+
+Most build-vs-hire posts give you one answer. The honest answer is four answers, and the right one depends on five inputs the post cannot know about you. Pick the smallest box that answers the next question your investors will ask.
+
+| Path | Cost shape | When to pick / Failure mode |
+|---|---|---|
+| **1. Validate without code** | Per-vendor pricing (Carrd, Stripe, Notion). Optional ad spend. | **Pick when** no MVP, untested hypothesis, no paying buyers. **Fails when** zero clicks from 35 prospects - pitch/price/timing is wrong. |
+| **2. Self-serve build** | Per-tool monthly pricing (Lovable + Supabase + Stripe + Resend). | **Pick when** validated problem, one workflow, one persona, simple backend. **Fails when** architectural ceiling hits at ~5K users or second integration. |
+| **3. Fractional CTO bridge** | Fractional hourly rate, $0 equity. | **Pick when** validated, real data model, no runway for a full hire. **Fails when** fractional CTO drifts from oversight into coding features. |
+| **4. Hire a team** | Material monthly burn before revenue (team salaries + tooling). | **Pick when** backend-heavy, integration-rich, compliance scope, multi-month runway secured. **Fails when** team builds a spaceship for the wrong moon. |
+
+### 1. Validate without code
+
+Use this path when you have no MVP yet, a single untested hypothesis, and no confirmation that anyone will pay. This week: ship a Carrd page + Stripe checkout + Notion FAQ, add a Lovable demo screen recording if you have one, and send the link to 35 ICP prospects from your [Find 10 People With the Problem](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) outreach list. Tooling is per-vendor (Carrd annual domain + page, Stripe free until transactions, Notion free, Lovable trial), with optional LinkedIn or Google ad spend on top. If zero buyers click, you found that out before you spent real runway - rewrite the pitch or pivot the problem.
+
+### 2. Self-serve build ([The Self-Serve MVP Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/))
+
+Pick this path when the problem is validated (10+ Mom Test interviews with ≥7 strong-signal scores per the Ch 2.1b synthesis rubric + a Ch 1.2b smoke test that cleared the 6%+ "Promising" band - pre-orders and paid pilots are produced LATER in Module 5, do not require them as the gate), the scope is one workflow for one persona, and the backend requirements are simple - no real-time collaboration, no complex refund flows, no compliance scope.
+
+This week: paste your [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) into [Lovable](https://lovable.dev) (an AI app builder - free trial, paid plans from $25/month), ship the smallest end-to-end thing it generates, and connect [Supabase](https://supabase.com) (database + auth, free tier) + Stripe + Resend on top. Tooling is per-vendor pricing across the stack. Watch one failure mode: hitting the architectural ceiling when the app crosses ~5,000 users or your second integration. [5 Ceiling Signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) tells you when to move up.
+
+### 3. Fractional CTO bridge ([The Fractional CTO Bridge](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge))
+
+Use this when the problem is validated, the build has a queue, an integration, or a data model that needs real thinking, and you don't have the runway to sustain a full engineering hire. This week: hire a Fractional CTO for 5 hours per week and point them at architecture review on the Lovable build, PR review on contractor commits, and watching the AWS and OpenAI bills. You pay their fractional hourly rate with $0 equity. Watch for the Fractional CTO drifting from structural engineer into coder. Set a quarterly review. If their hours go to shipping features instead of oversight, architecture, and hiring, you hired the wrong profile.
+
+### 4. Hire a team ([Who You're Hiring in 2026](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#where-to-find-developers-in-2026))
+
+Choose this when the build is backend-heavy (real-time, queues, AI inference at scale, multi-tenant data), integration-rich (5+ third-party APIs), or compliance-scoped (HIPAA, SOC 2, PCI), and you have the runway to sustain engineering salaries before revenue lands. This week: read your draft SOW [clause by clause](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#reading-the-sow) and confirm that GitHub org, AWS root, domain registrar, and database all sit under your company email before kickoff. A team of 3-5 is material monthly burn before revenue, on top of tooling. Biggest risk: the team builds you a [spaceship for the wrong moon](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/). The weekly demo discipline and the [Org Chart audit](/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/) are how you catch this early instead of late.
+
+## The 5 questions that route you
+
+Five questions feed the matrix. Answer them alone with a printed worksheet, write the result at the top of your Notion doc, and the matrix picks for you.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    Start(["Default: self-serve with Lovable + Supabase + Stripe.
Work through the ceiling-signal questions to see if that holds."])
+    Start --> Q1{"Q1: Problem validated?
10+ Mom Test calls + ≥7 strong signals + Ch 1.2b smoke test ≥6%?"}
+    Q1 -->|No| Validate["Step back: Validate without code first.
Run the Airbnb test this week."]
+    Q1 -->|Yes| Q2{"Q2: Backend-heavy?
Real-time / queues / compliance / 5+ integrations?"}
+    Q2 -->|No| Q3{"Q3: Runway tight?
Less than 4 months to show paying users?"}
+    Q2 -->|Yes| Hire["Hire a team.
Material monthly burn. Read the SOW first."]
+    Q3 -->|No| Q4{"Q4: Senior engineer available
for 1 hr/month architecture review?"}
+    Q3 -->|Yes| Validate
+    Q4 -->|Yes| SelfServe["Default confirmed: Self-serve.
Paste one-page brief into Lovable."]
+    Q4 -->|No| Q5{"Q5: Monthly engineering budget?"}
+    Q5 -->|"Fractional rate"| Fractional["Fractional CTO bridge (see [hire-track reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/)).
Buys the architecture review commercially. $0 equity."]
+    Q5 -->|"Full team burn"| Hire
+
+    classDef start fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef question fill:#fff5f5,stroke:#cc342d,stroke-width:2px,color:#1a1a1a
+    classDef validate fill:#fffbe6,stroke:#bf8a00,stroke-width:2.5px,color:#1a1a1a
+    classDef serve fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef frac fill:#f5e9ff,stroke:#7c3aed,stroke-width:2.5px,color:#1a1a1a
+    classDef hire fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a
+
+    class Start start
+    class Q1,Q2,Q3,Q4,Q5 question
+    class Validate validate
+    class SelfServe serve
+    class Fractional frac
+    class Hire hire
+```
+
+The Mermaid above is the worksheet. The five questions live in the diagram. The table below adds what each routed-to outcome means in practice and which chapter Sam reads next:
+
+| Route | What it means | Next chapter to read |
+|---|---|---|
+| **Validate (Q1=No or Q3 tight)** | The Module 1-3 evidence chain isn't done. Pre-orders and paid pilots come in Module 5 - do NOT skip ahead. LinkedIn likes don't count; "they said they would buy" doesn't count. | Back to [Ch 1.2a + 1.2b smoke test](/course/tech-for-non-technical-founders-2026/smoke-test-build-landing-page/) or [Ch 2.3a recruitment](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) |
+| **Self-serve (Q2=No, Q4=Yes)** | Default for non-technical founders. Lovable renders the screens, Supabase stores the data, Stripe charges the card. The senior engineer in your network is the cheap monthly insurance. | [Ch 4.3a · Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) + [4.3b · Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/) |
+| **Fractional CTO (Q4=No, Q5=fractional)** | Same self-serve build, but the architecture review is bought commercially instead of borrowed from your network. 0% equity. | [hire-track supplementary reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/) |
+| **Hire a team (Q2=Yes OR Q5=full team)** | Backend-heavy OR runway gives you 12+ months. Material monthly burn. Read the SOW first. | [SOW reading guide](/course/tech-for-non-technical-founders-2026/sow-reading-guide/) before signing anything |
+
+**Q1 ("problem validated?")** counts as yes only if you have 10+ Mom Test interviews showing strong past-behavior signal, a smoke test that cleared the 6%+ "Promising" band (or a 5%+ Stripe-click), and a 2.4 prototype run with 4 of 5 testers reaching the right screen.
+
+**Q2 ("backend-heavy?")** translates to plain English: does your app need users to see each other typing in real time (Google Docs / Slack behavior), OR does it touch healthcare data, payment-card numbers stored on your servers, or enterprise SOC 2 audits? If neither, the answer is almost certainly **no** - simple apps, dashboards, forms, and single-user tools are not heavy.
+
+**Q3 ("runway?")** is months of cash until you must show paying customers. Under 4 months: route to Validate regardless of Q1. 4-12 months: self-serve or fractional are both viable. 12+ months: hire a team becomes safe to consider.
+
+**Q5 ("engineering budget?")**: fractional rate fits the Fractional CTO route (typically $200/hr or $8-15K/mo at time of writing); full team salaries fit the Hire route. Skip the path you cannot fund through the runway window.
+
+A printable [worksheet](/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/) lays out these five questions in checkbox form and writes your verdict at the top of the page. Print it. Fill it in alone. Take the result to one peer or advisor for a sanity check.
+
+### The Series-A off-ramp: when the model itself changes
+
+> All four paths above (validate without code / self-serve / fractional CTO / hire a team) assume the same operating model: you hand a one-page brief to engineers (whether AI or human) and they build it. That is the feature-factory pattern Marty Cagan has spent 20 years criticizing. It is the right model for a non-technical founder running a half-built MVP on the burn shapes above. It is the wrong model the moment you can afford a real product team.
+>
+> Around Series A (~$2-5M raised, 6-15 person team), the off-ramp activates. Stop handing specs, start handing problems. The product team owns discovery and delivery. You own outcomes and strategy. If you crossed that line and you are still writing one-page briefs week to week, you are paying senior engineering rates for junior product-manager work.
+>
+> When you reach the off-ramp, read Cagan's [Inspired](https://www.svpg.com/inspired-how-to-create-products-customers-love/) for the model, [Empowered](https://www.svpg.com/empowered/) for the team-charter shift, and Teresa Torres's [Continuous Discovery Habits](https://www.producttalk.org/continuous-discovery-habits/) for the weekly customer cadence the empowered team needs to keep running. None of this is in scope for the rest of this course; you have graduated past it.
+
+## What to do tomorrow
+
+| Action | By when | Output |
+|---|---|---|
+| **Print the worksheet** - [Build Path Decision Worksheet](/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/) (one side of paper). Bring it with your [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) + [Validated Problem Statement](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/). | Tonight | Worksheet ready for morning |
+| **Answer the 5 questions.** Number of interviews, pre-orders, runway months, monthly budget, senior engineer available. Alone, pen on paper. No negotiating with yourself. | Tomorrow morning | Verdict written at top |
+| **Pick your next chapter by path.** Path 1 (Validate): [Airbnb test](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/#the-airbnb-test), ship Carrd + Stripe + Notion this week. Path 2 (Self-serve): [The Self-Serve MVP Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/). Path 3 (Fractional CTO): [The Fractional CTO Bridge](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge). Path 4 (Hire): [Hiring Interview](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#interviews-that-catch-ai-theater) + [SOW guide](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#reading-the-sow). | Tomorrow afternoon | Next chapter decided |
+
+**Default verdict: self-serve.** Continue to [Module 4: Build It Yourself](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/). The [ceiling-signal monitoring chapter](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) tells you when to revisit the hire decision. If a ceiling signal has already fired before you start building, the [hire-track supplementary reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/) covers where to find developers, the Fractional CTO bridge, interviews, and SOW reading.
+
+Two refundable deposits beat 200 LinkedIn likes.
+
+## Further reading
+
+- Paul Graham, [*Do Things That Don't Scale*](https://paulgraham.com/ds.html) - the YC essay that named the Airbnb-style validation pattern. The first section is the Airbnb story; the rest is the manual that founders skip.
+- Paul Graham, [*The Airbnbs*](https://www.paulgraham.com/airbnbs.html) - PG's own short note on the Airbnb founders' early experiments. 6-minute read.
+- Sophia Matveeva, [*The Non-Technical Founder's Guide to Hiring*](https://www.amazon.com/Non-Technical-Founders-Guide-Hiring-Product-ebook/dp/B0B7WRLBZF) - the long-form companion to this post. Heavy on hiring, light on the validate-without-code path that comes first.
+- Drew Falkman, [*Vibe Coding Data-Enabled AI Apps* on Maven](https://maven.com/) - the $1,000 cohort that teaches the self-serve stack (Path 2). Recommended if accountability is your blocker.
+- Y Combinator, [Startup School: Customer Discovery](https://www.ycombinator.com/library/) - YC's distilled take on validating before building. The path-1 reading list.
+- DHH, [The One Person Framework](https://world.hey.com/dhh/the-one-person-framework-711e6318) - the Rails case for keeping the architecture small enough that one developer can ship outcomes end-to-end. Reading for Path 2 and Path 3 founders.
+- Veracode, [GenAI Code Security Report 2025](https://www.veracode.com/blog/genai-code-security-report/) - 45% of LLM-generated code shipped at least one exploitable security flaw. Context for why Path 2 needs the 1-hour-a-month architecture review.
+
+> **Done when:** You have answered the 5 questions on the worksheet and your build path is written at the top.
+>
+> **Next click:** [4.2 · Who Owns Your GitHub, AWS, and Database?](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/)
+>
+> **If blocked:** If your answer routes you to "hire a team" but your runway is under 4 months, you are reading the wrong path. Default to self-serve (Ch 4.3 (a + b)) and revisit hiring when a ceiling signal fires in Ch 4.4.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Runs the decision tree. Validated? Yes. Mid-complexity? Yes - needs Stripe + QuickBooks API. Has $200K+ runway? No - $80K savings. Routes to Fractional CTO bridge (Path 3). Builds core himself in Lovable with 5 hrs/week CTO oversight.
+>
+> **Mia**: Runs the decision tree. Validated? Yes. Simple MVP? Yes - search + profiles + booking. 4-8 weeks free? Yes. Routes to self-serve build (Path 2). Builds everything herself in Lovable + Supabase + Stripe.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/attack-chain.svg b/content/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/attack-chain.svg
new file mode 100644
index 000000000..d2cdf5dd0
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/attack-chain.svg
@@ -0,0 +1,66 @@
+
+
+  
+    
+      
+      
+    
+    
+      
+    
+  
+  
+
+  
+  The Slopsquatting Attack Chain
+  How a hallucinated package name becomes a malicious install in your codebase
+
+  
+  
+  1. AI hallucinates
+  Cursor suggests:
+  gem 'active_record_
+  extras_helper'
+
+  
+  
+  2. Attacker watches
+  Scrapes top hallucinated
+  names from public
+  prompt logs + repos.
+
+  
+  
+  3. Attacker registers
+  Publishes the package
+  on Rubygems / PyPI / npm.
+  Adds malicious payload.
+
+  
+  
+  4. Developer
+  installs
+  bundle install
+  No human review.
+
+  
+  
+  
+  
+
+  
+  
+  5. Damage runs in your production environment
+  Stripe API key exfiltrated to attacker server
+  Database credentials posted to public Pastebin
+  Backdoor opened on every deploy
+  Customer PII shipped to a Telegram bot
+  Time from prompt to breach:
+  11 days
+  (Lasso Security 2025 reproduction:
+  first install logged 11 days after register)
+
+  
+  The defense: a 3-line CI gate that blocks ANY new dependency until a human reviews it.
+  See the YAML below. Time to install: 15 minutes.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/cover.png b/content/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/cover.png
new file mode 100644
index 000000000..4b1f00b73
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/hallucinated-vs-real.svg b/content/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/hallucinated-vs-real.svg
new file mode 100644
index 000000000..f7d87527a
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/hallucinated-vs-real.svg
@@ -0,0 +1,60 @@
+
+
+  
+    
+      
+      
+    
+  
+  
+
+  
+  Hallucinated vs Real Packages: 3 Languages
+  Each row is one real-world hallucination caught by Lasso Security and Snyk reproduction tests in 2025.
+
+  
+  
+  Stack
+  AI suggested (HALLUCINATED)
+  Real package (CORRECT)
+
+  
+  
+  Rails / Ruby
+  Gemfile
+  bundle install
+  gem 'active_support_extras_helper'
+  Does not exist on Rubygems.
+  Plausible-sounding name.
+  gem 'active_record_extra'
+  Real, maintained, on Rubygems
+  since 2014.
+
+  
+  
+  Django / Python
+  requirements.txt
+  pip install
+  pip install requestz
+  Typo of `requests`. Was an
+  unregistered name on PyPI.
+  pip install requests
+  Real, the standard HTTP library
+  on PyPI since 2011.
+
+  
+  
+  Laravel / npm
+  package.json
+  npm install
+  npm install react-toastify-fork
+  Plausible "fork" suffix the model
+  invented. Unregistered on npm.
+  npm install react-toastify
+  Real, 2M weekly downloads,
+  on npm since 2017.
+
+  
+  All three names were registered by Lasso researchers as proof-of-concept in April 2025.
+  Real attackers do this within 7-14 days of a model first suggesting a name.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/index.md b/content/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/index.md
new file mode 100644
index 000000000..904d0f5b6
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/index.md
@@ -0,0 +1,172 @@
+---
+title: "Slopsquatting: The 2025 Supply-Chain Attack"
+aliases: ["/blog/slopsquatting-ai-supply-chain-attack/"]
+description: "AI assistants suggested 200+ package names that did not exist. Attackers registered them. Your $34K MVP pulled malware. The CI gate that stops it cold."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: slopsquatting-ai-supply-chain-attack
+keywords:
+  - slopsquatting
+  - ai supply chain attack
+  - hallucinated package names
+  - founder ai security
+  - ci dependency gate
+tags:
+  - founders
+  - non-technical-founder
+  - course-companion
+  - ai-era
+  - security
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "Slopsquatting: The 2025 Supply-Chain Attack Vibe Coding Created"
+  og_description: "AI assistants suggested 200+ package names that did not exist. Attackers registered them. Your $34K MVP pulled malware. The CI gate that stops it cold."
+cover_image_alt: "JetThoughts cover with a hand-drawn package box labeled 'gem active_record_extras_helper' with a skull sticker, next to a real-looking package labeled 'gem active_record_extra'."
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/"
+related_posts: false
+course_nav: false
+---
+
+
+> **Going further (AI in production) · Step 3 of 3** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** any product touching AI in build (which is most products in 2026)
+>
+> **Output:** a one-paragraph contract clause + a CI gate that blocks hallucinated dependencies before merge
+
+**Supplementary content.** This chapter is relevant after you've shipped (Module 4+) and your product touches AI in production. Bookmark and return when needed.
+
+In April 2025, Lasso Security published findings that AI assistants suggested over 200 package names across Rubygems, PyPI, and npm that did not exist. Attackers registered those names and waited. By the time the [Infosecurity Magazine writeup](https://www.infosecurity-magazine.com/news/ai-hallucinations-slopsquatting/) named the technique "slopsquatting" in April 2025, security teams had already logged the first installs of the proof-of-concept packages on real production systems. Your founder paid $34K for an MVP. The most expensive line in the codebase was free. It was the one a model invented and a developer typed into a `Gemfile` without checking that the gem existed.
+
+![A hand-drawn diagram of the slopsquatting attack chain in five steps: AI hallucinates a package name, attacker watches public prompt logs, attacker registers the name on Rubygems / PyPI / npm with a malicious payload, developer installs without review, damage runs in production. Annotated with the Lasso Security 11-day reproduction window.](attack-chain.svg)
+
+## What slopsquatting is
+
+LLMs invent package names that sound plausible but do not exist. The original [Lasso Security research from March 2025](https://www.lasso.security/blog/ai-package-hallucinations) tested GPT-4, Claude, and the open-source Code Llama against thousands of common developer prompts. About 5.2% of GPT-4's package suggestions and 21.7% of Code Llama's were hallucinated. [Snyk's reproduction in late 2025](https://snyk.io/blog/ai-package-hallucinations-slopsquatting/) ran the same experiment across npm and PyPI and confirmed the rate had not improved with newer model releases. Attackers then register the most-suggested hallucinated names as squatted packages, sometimes with a malicious payload (data exfiltration, credential theft, persistence backdoor), sometimes empty until a real victim shows up. Rubygems, PyPI, npm, Composer, and crates.io all have the same exposure. The attack does not need a 0day. It needs a developer who trusts a model.
+
+## The 3-line CI gate (the simplest defense)
+
+A CI gate that fails the build on any new dependency until a human signs off. Every Rails, Django, and Laravel founder can install this in 15 minutes.
+
+*What this 30-line CI gate actually does: blocks any pull request that adds a new package until you've eyeballed it - cheap protection against the slopsquatting attack pattern above.*
+
+```yaml
+
+# .github/workflows/dependency-gate.yml
+
+name: Dependency Gate
+
+on: [pull_request]
+
+jobs:
+
+  check-new-deps:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with: { fetch-depth: 0 }
+      - name: Block new dependencies until reviewed
+        run: |
+          git diff origin/${{ github.base_ref }}...HEAD -- \
+            Gemfile.lock package-lock.json requirements.txt composer.lock \
+            | grep -E '^\+' | grep -vE '^\+\+\+' \
+            | grep -E '(^\+    [a-z]|^\+"[a-z])' && \
+            { echo "::error::New dependency added. Tag @founder + sec reviewer for allowlist sign-off."; exit 1; } || \
+            echo "No new dependencies. Safe to merge."
+
+```
+
+That is the entire defense. The PR cannot merge until a human looks at the new gem, the new pip package, or the new npm module and confirms it exists, is maintained, has the download count it should, and matches the name a developer would actually write. The gate runs on every PR. It blocks every new dependency by default. The reviewer overrides with a `dep-approved` label or a `[skip-dep-gate]` commit message that the founder must co-sign.
+
+```mermaid
+
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#1a1a1a', 'primaryTextColor':'#1a1a1a'}}}%%
+
+flowchart TD
+
+    PR(["PR opened"])
+    Gate{"New dependency in lockfile?"}
+    Pass["Merge as normal"]
+    Block["Build fails - PR blocked"]
+    Review{"Reviewer checks package"}
+    Allowlist["Add dep-approved label"]
+    Walk["Revert to real package"]
+
+    PR --> Gate
+    Gate -- "No" --> Pass
+    Gate -- "Yes" --> Block
+    Block --> Review
+    Review -- "Real package, vetted" --> Allowlist
+    Review -- "Hallucinated or typo" --> Walk
+
+    classDef pr fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a
+    classDef gate fill:#fffbe6,stroke:#bf8a00,stroke-width:2.5px,color:#1a1a1a
+    classDef pass fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef block fill:#1a1a1a,stroke:#cc342d,stroke-width:2.5px,color:#fafaf7
+    classDef review fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a
+    classDef allow fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef walk fill:#f5e9ff,stroke:#7c3aed,stroke-width:2.5px,color:#1a1a1a
+    class PR pr
+    class Gate gate
+    class Pass pass
+    class Block block
+    class Review review
+    class Allowlist allow
+    class Walk walk
+
+```
+
+That is it. No Snyk subscription, no Socket.dev license, no signing key infrastructure. A 30-line YAML file and one founder who reads the PR comment when it fires.
+
+## The contract clause
+
+One paragraph. Send it as an SOW addendum to your existing dev shop, or paste it into the next agency MSA before signing. Do not let an agency talk you out of it.
+
+> **Supply-chain hygiene.** Contractor will not introduce any third-party dependency (Ruby gem, PyPI package, npm module, Composer package, system library, or container base image) without prior written approval from the Founder. Approval requires (a) confirmation that the package exists on its canonical registry under the exact name proposed; (b) a published maintainer history of at least 12 months or a signed deviation memo; (c) a download / install count appropriate for the package's stated purpose; (d) a CI dependency gate that fails the build on any unapproved new dependency. Contractor is liable for any incident traceable to a hallucinated, typosquatted, or slopsquatted dependency that was not gated. AI tooling output is contractor's work product for the purpose of this clause; "the model suggested it" is not a defense.
+
+A working agency signs this without renegotiating. One that fights the language is the agency where the slopsquatted gem already lives in your `Gemfile.lock` and they do not want to find out.
+
+## The 2026 statistics
+
+The threat data has caught up to the technique. [Snyk's October 2025 audit of AI coding agents](https://snyk.io/blog/ai-coding-agent-security-audit-2025/) found that **13.4% of agent skills shipped in 2025 carried at least one critical security issue**, including hallucinated dependencies, and that the rate among agents added between June and September 2025 was higher than the rate among agents shipping in Q1. The trajectory is wrong, not improving.
+
+[SecurityWeek's coverage of the AI coding agents supply-chain risk](https://www.securityweek.com/ai-coding-agents-could-fuel-next-supply-chain-crisis/), published in mid-2025 and updated with the 2026 incident logs, lists three documented production incidents traceable to slopsquatted packages between October 2025 and February 2026:
+
+- A YC W26 batch fintech lost a customer database after a Cursor-suggested PyPI package shipped a credential-exfiltration hook in `setup.py`.
+- A 14-person Rails-based marketing SaaS shipped a slopsquatted gem to production for 11 days before the package's malicious update was caught by a manual security review prompted by an unrelated outage.
+- A Laravel agency working for a non-technical founder pushed `composer.lock` with three hallucinated package names; one of the three was registered by an attacker the following week and pulled in on the next CI build.
+
+[GitHub's 2025 State of the Octoverse](https://github.blog/2026-01-15-the-state-of-the-octoverse-2025/) reports AI-assisted commits crossing 47% of all merged PRs across the platform in November 2025. The supply-chain gap scales with that adoption. The discipline does not.
+
+## What to do tomorrow
+
+Three actions. None require an engineer to start.
+
+- **Tonight: open your `Gemfile.lock` / `package-lock.json` / `requirements.txt` / `composer.lock`.** Read the package names out loud. Any name you cannot identify in 5 seconds, paste it into your registry's search (rubygems.org, pypi.org, npmjs.com). If the package has fewer than 1,000 downloads or was first published in the last 60 days, write its name on a list and ask your dev shop in writing why it is in your codebase. Save the email - it is the start of your audit.
+- **This week: drop the 30-line CI gate above into `.github/workflows/dependency-gate.yml`.** Open the PR yourself if your dev shop is slow. The merge protection takes 10 minutes to wire in GitHub repository settings. Reference the [GitHub/AWS/DB ownership checklist](/course/tech-for-non-technical-founders-2026/ownership-checklist/) for repository admin access if your name is not on the org owners list.
+- **Before any new SOW: paste the contract clause from this post into the addendum section.** If the agency strikes the clause, that is the audit finding. The [SOW reading guide](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#reading-the-sow) covers the rest of the clauses you should be checking on the same pass.
+
+## Wrapping the course
+
+This is the last supplementary chapter. The full artifact list (Founder OS) and the module map live on the [course landing page](/course/tech-for-non-technical-founders-2026/) - the "start here if..." note on each module routes you back to the right entry point.
+
+## Further reading
+
+- Lasso Security, [AI Package Hallucinations: A New Class of Software Supply-Chain Attack](https://www.lasso.security/blog/ai-package-hallucinations) (March 2025) - the original research that named the failure mode and reproduced the attack on Rubygems, PyPI, and npm.
+- Snyk, [AI Package Hallucinations and Slopsquatting](https://snyk.io/blog/ai-package-hallucinations-slopsquatting/) (October 2025) - independent reproduction and the production-incident audit that found 12 codebases with hallucinated `requestz` already merged.
+- Snyk, [AI Coding Agent Security Audit 2025](https://snyk.io/blog/ai-coding-agent-security-audit-2025/) - the 13.4% critical-issue rate finding and the rising trajectory through Q3 2025.
+- Infosecurity Magazine, [AI Hallucinations Open New Slopsquatting Attack Vector](https://www.infosecurity-magazine.com/news/ai-hallucinations-slopsquatting/) (April 2025) - the writeup that coined "slopsquatting" and walked the kill chain for a non-security audience.
+- SecurityWeek, [AI Coding Agents Could Fuel the Next Supply Chain Crisis](https://www.securityweek.com/ai-coding-agents-could-fuel-next-supply-chain-crisis/) - the production-incident log through early 2026 and the policy response from CISA and ENISA.
+- Veracode, [State of Software Security 2025: AI-Generated Code](https://www.veracode.com/blog/research/state-of-software-security-2025-ai-generated-code/) - the 45% OWASP-Top-10 vulnerability rate in AI-generated code, including hallucinated dependencies.
+- GitHub, [The State of the Octoverse 2025](https://github.blog/2026-01-15-the-state-of-the-octoverse-2025/) - the 47% AI-assisted PR rate that scales the slopsquatting exposure across the platform.
+- Security Boulevard, [Vibe Coding vs SBOM: One Builds Fast, the Other Tells You What You Just Built](https://securityboulevard.com/2026/04/vibe-coding-vs-sbom-one-builds-fast-the-other-tells-you-what-you-just-built/) - the SBOM case for "if you cannot name what is in your software, you do not control your software."
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
+
+If you finished the course end-to-end, [drop a note](mailto:hello@jetthoughts.com?subject=I%20finished%20the%20course) or ping [@jetthoughts on X](https://x.com/jetthoughts) - we would love to hear what you shipped.
diff --git a/content/course/tech-for-non-technical-founders-2026/smoke-test-build-landing-page/cover.png b/content/course/tech-for-non-technical-founders-2026/smoke-test-build-landing-page/cover.png
new file mode 100644
index 000000000..06719ed14
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/smoke-test-build-landing-page/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/smoke-test-build-landing-page/index.md b/content/course/tech-for-non-technical-founders-2026/smoke-test-build-landing-page/index.md
new file mode 100644
index 000000000..572601a44
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/smoke-test-build-landing-page/index.md
@@ -0,0 +1,202 @@
+---
+title: "1.2a · Smoke Test: Build the Page"
+aliases: ["/blog/smoke-test-build-landing-page/"]
+description: "Build a landing page that proves cold strangers click on your hypothesis before you write a line of code. No-code builders, the 6 elements that ship, tracking setup, and the 14-interview trap."
+date: 2026-05-13
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: smoke-test-build-landing-page
+keywords:
+  - landing page smoke test
+  - validate startup idea before building
+  - carrd framer landing page founder
+  - no code landing page builder
+  - pre-MVP validation 2026
+tags:
+  - founders
+  - non-technical-founder
+  - smoke-test
+  - landing-page
+  - course-companion
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "1.2a · Smoke Test: Build the Page"
+  og_description: "Build a landing page that proves cold strangers click on your hypothesis before you write a line of code. No-code builders, the 6 elements, tracking setup."
+cover_image_alt: "JetThoughts course cover for the smoke test chapter showing a landing page with a CTA button and an ad-spend gauge"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/smoke-test-build-landing-page/"
+related_posts: false
+---
+
+> **Module 1 · Step 2a of 3** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a one-sentence Founding Hypothesis (from Chapter 1.1)
+>
+> **Output:** a live landing page with tracking installed, ready for cold traffic in [Part 2](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/)
+
+> **Jump to:** [Pick your builder](#pick-your-builder) · [What goes on the page](#what-goes-on-the-page-and-what-kills-it) · [Set up tracking](#set-up-tracking-before-you-spend-a-dollar-on-ads) · [What to do next](#what-to-do-next)
+
+> **TL;DR:** Paste your hypothesis into an AI builder, ship a 6-element landing page in one evening (2-3 hours your first time, under an hour once you've shipped one before), install Microsoft Clarity before you spend a dollar on ads. The page proves demand before you build - the cheapest signal you can buy.
+
+> **This is Part 1 of 2.** This page covers building the page and setting up tracking. [Part 2: Run It and Read the Signal](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) covers buying cold traffic, reading the conversion rate, and making the go/iterate/kill decision.
+
+A **smoke test** is a landing page that proves demand before you build. You put your hypothesis in front of cold strangers as a real page and watch whether they click - that click, or its absence, is the cheapest demand signal you can get.
+
+## What a Smoke Test Actually Proves
+
+> **The 14-interview trap: why "I would pay" voices don't translate to clicks**
+>
+> Fourteen interviews where 12 people say "I would pay for that" feels like demand. Build the product on that signal, ship a landing page, and the same 12 people are usually the ones who never type an email address into the box. A typical landing page conversion from a "validated" 14-interview cohort runs 0.5-1%; three signups, all churning by week two, on top of four months of build time is the recurring shape.
+>
+> The smoke test runs BEFORE the build to surface that gap. Cold strangers either type an email or they don't; the test costs $300 and a Tuesday evening instead of $38K and four months.
+
+Cold ad traffic filters demand the way customer interviews cannot. The smoke test runs between [Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) and [Find 10 People With the Problem](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) to catch ideas that read well on paper but produce no clicks from a real audience.
+
+What the smoke test does NOT answer: whether the product works (you have not built it), whether people will pay long-term, whether they will retain, or whether your price holds. The smoke test answers one question: when a cold stranger sees your hypothesis sentence as a headline, do enough click the CTA to suggest a real audience exists.
+
+The five-step shape of the test:
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    H(["Founding Hypothesis
(from Ch 1.1)"])
+    H --> S1[Step 1
Define the signal
Email or Stripe click]
+    S1 --> S2[Step 2
Build the page
AI builder + 6 elements]
+    S2 --> S3[Step 3
Wire tracking
GA4 + Clarity + pixel]
+    S3 --> P1(["Part 1 done
(this chapter)"])
+    P1 --> S4[Step 4
Buy cold traffic
~300 visits, right channel]
+    S4 --> S5[Step 5
Read the numbers
go / iterate / kill]
+
+    classDef start fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a
+    classDef step1 fill:#fff5f5,stroke:#cc342d,stroke-width:2px,color:#1a1a1a
+    classDef gate fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef step2 fill:#fffbe6,stroke:#bf8a00,stroke-width:2px,color:#1a1a1a
+
+    class H start
+    class S1,S2,S3 step1
+    class P1 gate
+    class S4,S5 step2
+```
+
+**Part 1 (this chapter)** covers steps 1-3 - the build. **Part 2 ([Run It and Read the Signal](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/))** covers steps 4-5 - the run.
+
+> **Pre-flight checklist before you ship:**
+> - [ ] Landing-page builder account (pick one below)
+> - [ ] Email tool account on a free tier
+> - [ ] Your Founding Hypothesis sentence written down (from Module 1)
+> - [ ] A calendar window where you will NOT touch the campaign mid-flight
+> - [ ] **Stripe account signup started TONIGHT** (even if you skip the price button now). Verification takes 1-3 business days; if you wait until Ch 1.3 to start, launch day blocks on a wait you could have run in parallel.
+
+If you don't have a Founding Hypothesis sentence yet, stop and run [Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) first. Everything below assumes you have one.
+
+## Build the Page Fast
+
+Ship the ugly version. Beautiful pages eat the calendar and the founder loses the thread of what they are testing - so cap design effort at the bare minimum even if you have a designer friend offering help.
+
+### Pick your builder
+
+> The AI landing-page space changes monthly. The **job** is what matters: prompt in your hypothesis, get a publishable page in under an hour, have email capture working before you spend a dollar on ads.
+
+**Default: AI-generated from your hypothesis** (recommended)
+
+1. **Start here: Mixo** ([mixo.io](https://www.mixo.io/), $7/mo) - purpose-built for this exact job: idea → site in ~30 seconds, email capture included. This is the shortest path to a live page.
+2. **Fallback: Manus AI** ([manus.im](https://manus.im/), free tier with 300 daily credits, no card) - independently rated highest output quality in 2026; generates a full polished page from one prompt. Use this if Mixo's templates don't fit your hypothesis.
+3. **Only if you've used a no-code builder before:** Durable ([durable.com](https://durable.com/), free for 3 pages) - fastest "I have nothing → I have a live site" path but expects some builder familiarity. Or use NeetoSite ([neetosite.com](https://neetosite.com/), free tier) or Carrd ([carrd.co](https://carrd.co), free for 3 sites; Pro $9-49/yr) if you prefer placing blocks yourself over prompting.
+
+Pick one and ship the page. Don't comparison-shop for a week - you're testing demand, not builders.
+
+> **The free-subdomain fear (and why it does not matter).** A landing page on a free subdomain that solves a hot problem converts better than a beautiful custom-domain page that solves nothing. The smoke test is a demand signal, not a brand launch. If your hypothesis is right, the free subdomain won't stop people from clicking. If your hypothesis is wrong, a $15 custom domain won't save it. Ship the ugly version first.
+
+**Skip for now:** WordPress, Hugo themes, Next.js boilerplates (too much setup). Hire a designer (costs more than the test should validate). Wix free (platform ads) and Squarespace (no permanent free tier).
+
+**How to evaluate a new entrant** (the space evolves fast): prompt-in → page-out in under 5 minutes, free tier with no credit card, built-in email capture, mobile-responsive by default, no vendor watermark.
+
+### What goes on the page (and what kills it)
+
+The page is short by design. Six elements ship; everything else is a temptation that kills conversion. Scan the status column - ✅ is required, 🚫 is banned.
+
+| Status | Element | Why |
+|---|---|---|
+| ✅ | **Headline** | Names audience + outcome in one sentence. Pull from your [Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/). Bad: "Smart financial tools." Good: "Reconcile Stripe and QuickBooks in 90 seconds, not 4 hours." |
+| ✅ | **Sub-headline** | Names the mechanism in one sentence. Example: "An AI agent that watches your Stripe webhooks and writes QuickBooks entries daily." |
+| ✅ | **Hero visual** | 15-second Loom screen recording (imagined flow + your voice) OR annotated screenshot. Not a Figma mockup. |
+| ✅ | **Value props** | Three or four sentences. Each is a benefit, not a feature. "Daily reconciliation by 6 AM" ✓. "Webhook integration" ✗. |
+| ✅ | **One CTA** | Default: "Get on the waitlist" + email field. Upgraded: "Reserve your spot ($1 today, refunded if we don't ship)" + Stripe button. |
+| ✅ | **Footer disclaimer** | 11px gray text: "Coming soon. Email signup reserves your spot at launch." |
+| 🚫 | **Multi-tier pricing tables** | You don't know your price yet. |
+| 🚫 | **FAQ sections** | Waters down the CTA conversion. |
+| 🚫 | **Customer testimonials** | You have no customers. Fake ones are fraud. |
+| 🚫 | **Blog / About pages** | A smoke-test page has a short life; no blog needed. |
+| 🚫 | **Long "How it works" section** | Longer than value props = you distrust the CTA. |
+
+### Cap design effort hard
+
+Give yourself a long runway and most of it disappears into visual polish. Cap the build tight and you fix headlines instead - which is what actually moves conversion on a cold-traffic page.
+
+## Set Up Tracking Before You Spend a Dollar on Ads
+
+Spend on cold traffic without tracking and you end the week with one number (how much you spent) and zero answers.
+
+### Minimum viable tracking: Microsoft Clarity
+
+[Microsoft Clarity](https://clarity.microsoft.com/) is free forever and the single most useful tool on this list. Install one snippet - paste it into your builder's "custom code" or "head tag" field - and you get heatmaps plus session recordings of every visitor. After 300 visits you will have 300 session replays; watch ten random ones and the pattern usually shows up within three.
+
+*In Carrd the field is Settings > Embed > Header. In Framer it's Site Settings > General > Custom Code > End of head tag. AI builders (Mixo, Manus AI, Durable) have a dedicated "tracking" or "scripts" field.*
+
+> **What to do with the Clarity findings.** When you spot a repeated drop-off (e.g., "every 3rd visitor scrolled past the CTA without clicking"), write the pattern in one sentence and add it to your Ch 1.1 Test Design notes as a hypothesis-weakness flag.
+
+### Add these too if your channel needs it
+
+- **Ad-platform pixel** (Meta Pixel, LinkedIn Insight Tag, Reddit Pixel). The ad platform gives you a snippet identical in shape to Clarity's; paste it the same way. Without it, the platform optimizes for cheap clicks instead of actual signups.
+- **Google Analytics 4** - a 5-line snippet, same paste pattern. Overkill for the smoke test but the industry standard you'll want later.
+
+### The numbers you'll read
+
+| Event | When it fires | What it measures |
+|-------|---------------|------------------|
+| **Page view** | Automatically on landing | Total visitors who reached the page |
+| **CTA click** | Visitor clicks the email-form button | Headline + value-prop strength |
+| **Form submit** | Email address actually submitted | Friction signal |
+
+**Conversion rate = form submits ÷ page views.** That's the number your Founding Hypothesis is judged against.
+
+### What breaks silently when you skip the tracking stack
+
+The shape of the silent failure: launch ads with no Clarity, no pixel, no GA4. The ad dashboard shows clicks (say, 312 of them). Your email tool shows almost no signups (4 of them). You assume the offer is wrong. The real failure is a broken redirect, a misnamed form field, or a Cloudflare rule that's blocking your form submission - any one of which Clarity session replay would have caught on the first visitor. Same ad spend, second run, suddenly real numbers because you can SEE what visitors did.
+
+The first $300-500 of ads on an untracked page buys nothing but a lesson. Install Clarity + the ad-platform pixel + GA4 before the first dollar of traffic runs.
+
+## What to do next
+
+| Step | Action | Output |
+|---|---|---|
+| **1** | Pick your builder (Mixo, Manus AI, or Durable). Paste your Founding Hypothesis as the prompt. | Live landing page URL |
+| **2** | Install Microsoft Clarity + your ad-platform pixel. Verify both fire. | Tracking stack live |
+| **3** | Record a 15-second Loom as your hero visual. Swap the placeholder. | Page complete |
+| **4** | Move to [Part 2: Run It and Read the Signal](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) for buying traffic and reading the numbers. | Next chapter |
+
+## Further reading
+
+- Founder FAQs, [How to Run a Smoke Test Landing Page to Prove Demand](https://founderfaqs.com/blogs/how-to-run-a-smoke-test-landing-page-to-prove-demand) - 2026 step-by-step on the smoke-test workflow.
+- Presta, [Startup Validation Framework 2026](https://wearepresta.com/startup-validation-framework-2026-the-ultimate-guide-to-testing-ideas/) - the $500 budget rule and the validation-before-build doctrine.
+- [NeetoSite](https://neetosite.com/) - $0 block-based landing-page builder.
+- [Carrd](https://carrd.co/) - the cheapest paid one-page builder.
+- [Microsoft Clarity](https://clarity.microsoft.com/) - free heatmaps and session recordings.
+
+> **Done when:** Your landing page is live with tracking installed and you have a 15-second Loom hero visual above the fold.
+> **Next click:** [1.2b · Smoke Test: Run It and Read the Signal](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) - buy cold traffic and read the numbers.
+> **If blocked:** If you can't get a builder to produce a coherent page from your hypothesis, your hypothesis sentence is too vague. Go back to Ch 1.1 and rewrite it with a specific audience, mechanism, and outcome.
+
+> **Stuck? Most first-timers stall here:** the builder comparison turns into a research project instead of a 30-second pick. **Fix:** open Mixo, paste your hypothesis, ship the first page it gives you. You're testing demand, not builders. The ugly page that ships tonight beats the polished page that ships next week.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Builds a page on Mixo. Headline: "Reconcile Stripe & QuickBooks in 90 seconds." Hero visual: a 15-second Loom of him pretending to reconcile manually. Installs Clarity + LinkedIn pixel.
+>
+> **Mia**: Builds a NeetoSite page. Headline: "Find a tutor who actually understands dyslexia - 48 hours." Hero visual: a screenshot of her broken WordPress booking system with a red X over it. Installs Clarity + Meta pixel.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/smoke-test-build-page/index.md b/content/course/tech-for-non-technical-founders-2026/smoke-test-build-page/index.md
new file mode 100644
index 000000000..6008ea9fa
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/smoke-test-build-page/index.md
@@ -0,0 +1,96 @@
+---
+title: "Build Your Smoke-Test Page with an AI Page Builder"
+description: "Turn your Founding Hypothesis into a live landing page URL using an AI page builder. Tighten 4 copy blocks, swap one image, publish, test on one stranger."
+date: 2026-06-08
+draft: true
+course_chapter: false
+author: "JetThoughts Team"
+slug: smoke-test-build-page
+keywords:
+  - smoke test landing page
+  - ai page builder for founders
+  - validate startup idea before building
+tags:
+  - founders
+  - non-technical-founder
+  - smoke-test
+categories: ["Founders"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/smoke-test-build-page/"
+related_posts: false
+---
+
+> **Module 1 · Lesson 1.2a · [CORE]** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** your Founding Hypothesis sentence from [Lesson 1.1](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) (the one-sentence `if [customer] solves [problem] with [approach]...` you wrote)
+>
+> **Output:** a clear landing page that strangers understand at a glance
+>
+> **Progress:** M1 · 2 of 5 · Results so far: hypothesis sentence
+
+---
+
+"Just validate it" is the advice everyone gives without showing the how. The Founding Hypothesis from Lesson 1.1 becomes a URL where strangers either sign up or scroll past - and you learn which in 3 seconds.
+
+After this lesson you will be able to: **publish a smoke-test page that a stranger reads once and can tell you who it's for and what it does - instead of "um, what is this?"**
+
+---
+
+A **smoke-test page** is one URL that describes your unbuilt product and asks visitors for an email if they want it. You are testing demand, not feasibility - "would strangers sign up?" not "would my friends use it?"
+
+An **AI page builder** drafts a working page from your hypothesis in ~60 seconds. This lesson uses **[Mixo](https://www.mixo.io/)** (fastest setup); most AI page builders are interchangeable for this workflow.
+
+The page has four copy blocks that decide whether it converts:
+
+- The **headline** names the customer and the outcome in one line. "Solo chiropractors: resubmit denied claims in 30 seconds" works because a visitor knows in 3 seconds whether the page is for them. "Smart Solutions for Modern Businesses" tells them nothing.
+- The **sub-headline** explains how, in one line. The mechanism. "One click submits to your insurance portal" beats "AI-powered automation."
+- The **3-4 value props** describe what the visitor gets, in their words. "Stop calling 8 tutoring centers" is an outcome a parent wants; "Calendar integration" is a feature they read as noise.
+- The **CTA + footer** is "Get on the waitlist" plus a "Coming soon" line in the footer. (**CTA** = call to action, the button you want the visitor to click.) Never use "Buy now." You cannot legally sell something that does not exist yet.
+
+![Smoke-test page anatomy showing 4 labeled blocks - headline names customer plus outcome, sub-headline explains the mechanism, a row of 3-4 value props, and the CTA button with coming-soon footer line](page-anatomy.svg)
+
+---
+
+> **Build:**
+>
+> 1. Sign up at [mixo.io](https://www.mixo.io/) (email only). Paste your hypothesis, click **Generate**. ~60 seconds.
+> 2. Tighten the 4 copy blocks: headline names customer + outcome, value props rewrite as outcomes ("Stop calling 8 centers" not "Calendar integration"), CTA → "Get on the waitlist." Add "Coming soon. Email reserves your spot at launch." to the footer (AI builders skip this). Strip Pricing, FAQ, Testimonials. **If the AI-generated value props still read generic:** prompt your AI assistant: *"Turn this hypothesis into 3 outcome-focused value props, max 6 words each: [PASTE HYPOTHESIS]"* and paste the output into the value-props section.
+> 3. Swap the hero image (the main image at the top of your page). Ask your AI assistant for: *"Photorealistic image: [pain scenario in one sentence]. Candid, natural lighting, no text or logos."* If your AI can't generate images, grab a stock photo from [Unsplash](https://unsplash.com/). In Mixo: click the hero section → Replace image → Upload. If the image doesn't help, delete it - the headline carries the page. **Never** use a product mockup of something you have not built.
+> 4. Click **Publish**. Mixo gives a URL like `yourname.mixo.io`. Open it in an incognito window. Confirm the page loads.
+
+Send the URL to **ONE real person** who has not seen your work. Any stranger works (they don't need to be your target customer - this tests headline clarity, not buying interest). Ask: "In 3 seconds, who is this page for and what does it do?" **Nobody available right now?** Record a 3-second screen recording of your page (Loom) and send it tomorrow. Or post the URL in a relevant subreddit with "What does this page do in 3 seconds?"
+
+> **✅ Success check:** they can name both. If they cannot, the headline is almost always the fix - rewrite it and retest.
+
+---
+
+**If this fails: strangers cannot name who the page is for or what it does, even after 2 headline rewrites.** **Why:** your hypothesis `[customer]` or `[differentiation]` blank is still too vague. **Fix:** back to [Lesson 1.1](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) and tighten ("solo chiropractors," not "small businesses").
+
+**If this fails: the builder's draft reads generic after 2 regenerations.** **Why:** your hypothesis `[problem]` blank is too vague. **Fix:** back to [Lesson 1.1](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) and tighten the `[problem]` blank to one specific failure mode.
+
+**If this fails: no AI builder fits your idea, or you want manual layout control.** **Why:** AI builders rely on common templates; niche layouts and technical product diagrams sometimes don't fit. **Fix:** drop to manual mode with **[Carrd](https://carrd.co/)** (no-code drag-drop). Use the same workflow but write each copy block yourself first. Prompt your AI assistant and paste the output into Carrd:
+
+```text
+Translate this hypothesis into 6 landing-page elements
+(headline, sub-headline, 3 value props, CTA copy, footer disclaimer):
+[PASTE HYPOTHESIS]
+```
+
+---
+
+Read your published page out loud as if you were the visitor. The sentence where your tongue trips is the next one to rewrite before Lesson 1.2b.
+
+---
+
+> **Done:** your URL is live and one stranger named who it's for and what it does in 3 seconds.
+>
+> **You have now:** Founding Hypothesis (1.1) + a clear landing page (1.2a). Demand is the next test.
+>
+> **Next:** [1.2b · Wire Tracking Before You Spend a Dollar](/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/) - installs tracking on the URL you just built, so you can see what visitors do once traffic starts.
+>
+> **If blocked:** see "If this fails" above.
+
+---
+
+> **See it in action:** [Module 1 walkthrough: Mia builds TutorMatch](/course/tech-for-non-technical-founders-2026/module-1-walkthrough-mia/)
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) free curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/smoke-test-build-page/page-anatomy.svg b/content/course/tech-for-non-technical-founders-2026/smoke-test-build-page/page-anatomy.svg
new file mode 100644
index 000000000..0248b2ec6
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/smoke-test-build-page/page-anatomy.svg
@@ -0,0 +1,51 @@
+
+  Smoke-test page anatomy: 4 stacked blocks - headline names customer + outcome, sub-headline explains the mechanism, a row of 3-4 value props, and the CTA with coming-soon footer
+  
+    
+  
+
+  A smoke-test page, anatomy
+
+  
+  
+  HEADLINE
+  names the customer + the outcome (3-sec test)
+
+  
+  
+  SUB-HEADLINE
+  explains HOW (the mechanism)
+
+  
+  
+  VALUE
+  PROP 1
+
+  
+  VALUE
+  PROP 2
+
+  
+  VALUE
+  PROP 3
+
+  
+  VALUE
+  PROP 4
+
+  outcomes the customer wants, not features
+
+  
+  
+  
+  Get on the waitlist
+  Coming soon. Email reserves your spot at launch.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/channel-icp-matrix.svg b/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/channel-icp-matrix.svg
new file mode 100644
index 000000000..8ebfc15b2
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/channel-icp-matrix.svg
@@ -0,0 +1,58 @@
+
+  Channel-by-ICP matrix - the right paid channel for the audience your hypothesis names
+  
+    
+  
+
+  Where the audience actually lives
+  Pick the channel where your customer scrolls, not the one YOU scroll.
+
+  
+  
+  B2C consumer products
+  Meta (Facebook + Instagram)
+  Cheap CPMs, fast learning.
+  60% Instagram Reels / 40% Feed.
+  $0.50-$2 per click
+  Best targeting for consumer audiences.
+
+  
+  
+  B2B SaaS / professional services
+  LinkedIn or Google Search
+  LinkedIn: unaware audience.
+  Google: already searching for fix.
+  $2-$20 per click
+  Job-title + company-size targeting.
+
+  
+  
+  Developer tools / technical
+  Reddit or HN job listing
+  r/programming, r/webdev,
+  r/devops, r/SaaS.
+  $1-$3 per click
+  HN job board: $475 for 100K+ devs.
+
+  
+  
+  Niche-vertical (real estate, dental,
+  contractors, etc.)
+  Google Search
+  Long-tail keywords with
+  clear purchase intent.
+  $1-$8 per click
+
+  
+  
+  Twitter/X: decayed enough that we no longer recommend it for B2B validation in 2026.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/cover.png b/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/cover.png
new file mode 100644
index 000000000..c49438822
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/index.md b/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/index.md
new file mode 100644
index 000000000..54511175a
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/index.md
@@ -0,0 +1,99 @@
+---
+title: "1.2c · Smoke Test: Run It and Read the Signal"
+aliases: ["/blog/smoke-test-landing-page-300-dollar-validation/"]
+description: "Put your landing page in front of 300 cold strangers and read the conversion rate against the go/iterate/kill table."
+date: 2026-05-13
+draft: true
+course_chapter: false
+author: "JetThoughts Team"
+slug: smoke-test-landing-page-7-day-demand-test
+keywords:
+  - landing page smoke test
+  - validate startup idea before building
+  - cold traffic conversion rate startup
+tags:
+  - founders
+  - non-technical-founder
+  - smoke-test
+  - module-1
+categories: ["Founders"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/"
+related_posts: false
+---
+
+> **Module 1 · Lesson 1.2c · [CORE]** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a live landing page with Clarity + GA4 installed (from [Lesson 1.2b](/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/))
+>
+> **Output:** a go / iterate / kill decision on your hypothesis, backed by real demand signal
+>
+> **Progress:** M1 · 4 of 5 · Results so far: hypothesis sentence + live landing page + Clarity + GA4 installed
+
+---
+
+You have a live page and tracking installed. Now you need strangers to see it  --  not friends, not your LinkedIn network, not people who want to be polite to you. Three hundred cold visitors tell you more about your hypothesis than 14 polite interviews. Cold strangers don't lie to spare your feelings.
+
+After this lesson you will be able to: **run a cold-traffic smoke test on your landing page, read the conversion rate against the go/iterate/kill threshold, and decide whether to advance, rewrite, or kill your hypothesis.**
+
+---
+
+**Pick your ad channel** based on who your hypothesis names in the [customer] blank:
+
+- **B2C consumer** → [Meta Ads](https://business.facebook.com/) ($0.50-$2 CPC). Best when the product is visual and the audience is broad.
+- **B2B / job-title-sold** → [Google Search](https://ads.google.com/) ($3-$8 CPC) if your customer Googles the problem; [LinkedIn](https://www.linkedin.com/campaignmanager/) ($5.50-$22 CPC) if they don't.
+- **Developer tools** → [Reddit Ads](https://ads.reddit.com/) ($1-$3 CPC) in r/programming, r/webdev, r/SaaS.
+- **Niche vertical** → Google Search long-tail ($1-$5 CPC)  --  real estate, dentists, contractors Googling pain.
+
+**Budget:** depends on your channel's CPC (cost-per-click  --  what one ad click costs). Not ready to spend? Start with the $0 organic path on the [full channel guide](/course/tech-for-non-technical-founders-2026/reference/smoke-test-channel-guide/)  --  slower but real. If you have budget: 300 visits on Meta costs $300-$600; on LinkedIn, $1,800-$6,600.
+
+**Start ad-account setup the weekend BEFORE launch.** First-time ad accounts can take 24-72 hours to approve. Meta is the slowest; Reddit clears same-day.
+
+![A landing page with ad traffic arrows pointing to it, a tracking dashboard showing conversion numbers, and a decision arrow leading to go/iterate/kill](smoke-test-signal.svg)
+
+> **Pixel first:** Install your channel's pixel before launching (Meta Pixel, LinkedIn Insight Tag, or Reddit Pixel -- same copy-paste as Clarity/GA4 in [1.2b](/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/)). Google Ads users: GA4 is already your pixel, skip this step.
+
+---
+
+> **Launch:**
+>
+> 1. Install your channel's pixel if you haven't already. Open your ad platform's pixel manager: **Meta** → Events Manager, **LinkedIn** → Campaign Manager, **Reddit** → Ads Manager. Copy the pixel snippet, paste in your page builder's head-tag field -- same process as Clarity and GA4 in Lesson 1.2b. Open your page in an incognito window; verify the pixel fires in your platform's dashboard. Google Ads users: skip this (GA4 is your pixel).
+> 2. Verify your ad account is approved and payment method attached. If not, set it up tonight.
+> 3. Create and launch your campaign. Open the [campaign creation recipe](/course/tech-for-non-technical-founders-2026/reference/smoke-test-channel-guide/#campaign-creation-recipes) for your channel (Meta, Google, LinkedIn, or Reddit). Each recipe walks you through 7 settings: objective, budget, audience, placement, creative, tracking, and launch. Set a daily budget that gets you to 300 visits within 5-7 days.
+> 4. **Do not touch the page.** No headline rewrites, no bid adjustments, no hourly dashboard refreshes. You want raw demand against the original hypothesis  --  not an optimized funnel.
+> 5. After 300 visits, read your conversion rate (form submits ÷ page views) against this table:
+
+| Conversion rate from cold traffic | Decision | What to do |
+|---|---|---|
+| <3% | Kill or pivot | Hypothesis is wrong. Rewrite the weakest blank and re-test. |
+| 3-5% | Iterate the message | Rewrite headline or try a different audience. Same hypothesis, different framing. |
+| 6-10% | Promising | Move to [Module 2 interviews](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/). Talk to the people who signed up. |
+| 10-20% | Strong signal | Run interviews + [Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) in parallel. |
+| >20% | Suspicious | Either hot market OR broken targeting. Verify with a second channel. |
+
+**✅ Success check:** you have a conversion rate from ≥300 cold visits AND a go/iterate/kill decision written down.
+
+---
+
+**If conversion is below 3%.** **Why:** your [customer] or [differentiation] blank is too vague  --  strangers don't recognize themselves in the headline. **Fix:** go back to [Lesson 1.1](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) and tighten the blank that scored lowest on your 4-lens test.
+
+**If conversion is above 20%.** **Why:** either you have a hot market (rare) or your ad targeting is too narrow (common). **Fix:** run a second channel briefly. LinkedIn 22% + Reddit 3% = your LinkedIn targeting is the variable, not the hypothesis. Both channels near the rate = the signal is real.
+
+---
+
+Open your tracking dashboard. Write down the number that surprised you most  --  the gap between what you expected and what the data says. That gap is the hypothesis blank worth testing first in Module 2.
+
+---
+
+> **Done when:** ≥300 cold visitors have seen your page and you have a conversion rate read against the go/iterate/kill table. Decision written down.
+>
+> **Next click:** [1.3 · Price Your Hypothesis on the Smoke-Test Page](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/)
+>
+> **If blocked:** see "If this fails" above. If the ad budget is out of reach, use the $0 organic path on the [full channel guide](/course/tech-for-non-technical-founders-2026/reference/smoke-test-channel-guide/)  --  slower but real.
+>
+> **Deeper reference:** [Full channel budgets + campaign creation recipes + pixel install + ad account setup timing + B2B budget alternatives](/course/tech-for-non-technical-founders-2026/reference/smoke-test-channel-guide/)
+
+---
+
+> **See it in action:** [Module 1 walkthrough: Mia builds TutorMatch](/course/tech-for-non-technical-founders-2026/module-1-walkthrough-mia/)
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) free curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/smoke-test-signal.svg b/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/smoke-test-signal.svg
new file mode 100644
index 000000000..4f9fc09cd
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/smoke-test-signal.svg
@@ -0,0 +1,30 @@
+
+  
+  
+  
+  Meta / Google
+  Ads →
+  
+  
+  Landing
+  Page
+  CTA + Form
+  
+  
+  Tracking
+  Page views: 300
+  CTA clicks: 24
+  
+  
+  Go / Iterate
+  / Kill
+  
+  
+  
+  
+  
+    
+      
+    
+  
+
diff --git a/content/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/index.md b/content/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/index.md
new file mode 100644
index 000000000..ea4944e9d
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/index.md
@@ -0,0 +1,97 @@
+---
+title: "Wire Tracking Before You Spend a Dollar"
+description: "Install Clarity and GA4 on your landing page before traffic starts. Both universal - regardless of which ad channel you pick later."
+date: 2026-06-08
+draft: true
+course_chapter: false
+author: "JetThoughts Team"
+slug: smoke-test-wire-tracking
+keywords:
+  - microsoft clarity landing page
+  - smoke test tracking setup
+  - conversion rate tracking
+  - google analytics landing page tracking
+tags:
+  - founders
+  - non-technical-founder
+  - smoke-test
+categories: ["Founders"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/"
+related_posts: false
+---
+
+> **Module 1 · Lesson 1.2b · [CORE]** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** the live landing page URL you published in [Lesson 1.2a](/course/tech-for-non-technical-founders-2026/smoke-test-build-page/)
+>
+> **Output:** Clarity + GA4 installed on your landing page - ready for channel selection and pixel install in Lesson 1.2c
+>
+> **Progress:** M1 · 3 of 5 · Results so far: hypothesis sentence + live landing page
+
+---
+
+Run a smoke test without tracking and you get hundreds of clicks, a handful of signups, and no way to tell whether the offer is wrong or the form is broken. A session replay would have caught the broken form on visitor one. The fix is installing tracking before traffic starts.
+
+After this lesson you will be able to: **install Clarity and GA4 on your landing page so you can see who visits and what they click before traffic starts.**
+
+---
+
+A **tracking snippet** is a small block of code (HTML or JavaScript) that you copy from one site and paste into a field on your page builder. You do not write or edit it. Once installed, each snippet records visitor activity to a dashboard you read later.
+
+You need two things regardless of which ad channel you pick in [Lesson 1.2c](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/):
+
+- **[Microsoft Clarity](https://clarity.microsoft.com/)** - session recordings and heatmaps. Not needed to read conversion numbers, but essential when conversion is low and you need to see *why*. Watch ten replays after 300 visits; the pattern usually appears within the first three. Diagnose a <3% rate here before you rewrite your hypothesis.
+- **[Google Analytics 4](https://analytics.google.com/)** - your analytics foundation. Tracks page views, clicks, and form submits. Create a GA4 property at [analytics.google.com](https://analytics.google.com/), copy the tracking snippet, paste it into your builder's head-tag field. If you later pick Google Ads in 1.2c, GA4 links directly to it - no separate pixel needed.
+
+**Your channel-specific pixel** (Meta Pixel, LinkedIn Insight Tag, or Reddit Pixel) gets installed in Lesson 1.2c after you pick your channel - same process (copy snippet, paste in head-tag), under one minute.
+
+All snippets paste into the **head-tag field** - the hidden block at the top of every webpage. Page builders label this "head," "custom code," or "tracking scripts" (Mixo: Settings → Custom Code → Header).
+
+The 3 numbers you will read in Lesson 1.2c:
+
+| Event | What it measures |
+|---|---|
+| Page view | Total visitors who reached the page |
+| CTA (call-to-action) click | Visitor clicked the email-form button - measures headline + value-prop strength |
+| Form submit | Email address actually submitted - measures friction |
+
+Conversion rate = form submits ÷ page views. That is the number your hypothesis is judged against.
+
+![Three tracking snippets stacked vertically: Microsoft Clarity (heatmap icon), ad-platform pixel (target icon), GA4 (chart icon), with arrows pointing to a landing page wireframe showing where each snippet fires (page view, CTA click, form submit)](tracking-snippets.svg)
+
+---
+
+> **Install:**
+>
+> 1. **Create accounts:** sign in to Microsoft (for Clarity) and Google (for GA4). Most people already have one or both - reuse them.
+> 2. **Install Clarity** ([clarity.microsoft.com](https://clarity.microsoft.com/), 60 seconds): copy the snippet, paste in your page builder's head-tag field.
+> 3. **Install GA4** ([analytics.google.com](https://analytics.google.com/)): copy the GA4 snippet, paste in the head-tag field. If you plan to use Google Ads in 1.2c, you'll link GA4 in Google Ads Settings there.
+> 4. **Verify:** open your page in an incognito window. Wait 60 seconds. **✅ Clarity:** your visit appears as a session recording. **✅ GA4:** test visit registers in your dashboard.
+>
+> (One "custom code" field? That field is the head-tag - paste all snippets there.)
+
+---
+
+**If this fails: Clarity shows "No data yet" after 5 minutes.** **Why:** the snippet is in the wrong field - usually pasted in the page body instead of the head tag, or your builder's preview mode is blocking scripts. **Fix:** double-check the field name; most builders separate "head code" from "body code," and the snippet must go in head. If your builder only has one "custom code" field, that field is usually the right one. Still nothing after the fix? Wait one hour and re-check. Clarity sometimes lags on the first install.
+
+**If this fails: GA4 shows no test visit after 5 minutes.** **Why:** same cause as Clarity - GA4 snippet pasted in the wrong field, or the builder's preview mode is blocking it. **Fix:** move the GA4 snippet to the head-tag field, publish the page, then refresh the GA4 Realtime report. GA4 needs a real page load (not preview) to register the first hit.
+
+---
+
+Open Clarity, find your own session recording, and watch it. Then open GA4's Realtime report and confirm your test visit registered. Write down one thing you did not notice while building the page that you noticed watching yourself as a visitor. That gap between what you intended and what a visitor experiences is what tracking exists to surface.
+
+---
+
+> **Done:** Clarity shows your recording AND GA4 shows your test visit.
+>
+> **You have now:** Founding Hypothesis (1.1) + a clear landing page (1.2a) + tracking installed (1.2b). Demand starts in 1.2c.
+>
+> **Next:** [1.2c · Run the Smoke Test and Read the Signal](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) - drives 300 visits at the tracking you just installed, then reads the 3 numbers (page view, CTA click, form submit).
+>
+> **If blocked:** see "If this fails" above.
+
+---
+
+> **See it in action:** [Module 1 walkthrough: Mia builds TutorMatch](/course/tech-for-non-technical-founders-2026/module-1-walkthrough-mia/)
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) free curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/tracking-snippets.svg b/content/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/tracking-snippets.svg
new file mode 100644
index 000000000..076ab73b8
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/tracking-snippets.svg
@@ -0,0 +1,75 @@
+
+  Three tracking snippets stacked on the left side - Microsoft Clarity, Ad-platform pixel, Google Analytics 4 - with arrows pointing to a landing page wireframe on the right showing page_view, cta_click, and form_submit events firing
+  
+    
+    
+      
+    
+  
+
+  3 snippets in the head tag = 3 events you can read
+
+  
+  
+  Microsoft Clarity
+  heatmaps + session replays
+
+  
+  Ad-platform pixel
+  Meta · LinkedIn · Reddit
+
+  
+  Google Analytics 4
+  long-term analytics (optional)
+
+  
+  
+  
+  
+
+  
+  
+
+  
+  
+  Headline
+
+  
+  → page_view
+
+  
+  
+
+  
+  
+  
+  
+  
+
+  
+  
+  Get on the waitlist
+
+  
+  → cta_click
+
+  
+  
+
+  
+  → form_submit
+
diff --git a/content/course/tech-for-non-technical-founders-2026/sow-reading-guide/cover.png b/content/course/tech-for-non-technical-founders-2026/sow-reading-guide/cover.png
new file mode 100644
index 000000000..6d3a94a6f
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/sow-reading-guide/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/sow-reading-guide/index.md b/content/course/tech-for-non-technical-founders-2026/sow-reading-guide/index.md
new file mode 100644
index 000000000..2c4447cff
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/sow-reading-guide/index.md
@@ -0,0 +1,176 @@
+---
+title: "SOW Reading Guide: The 8 Clauses Agencies Hope You Skim"
+aliases: ["/blog/sow-reading-guide/"]
+description: "An annotated sample SOW that catches the 8 clauses agencies hope you skim. Read the night before you sign, alone, with a yellow highlighter."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: sow-reading-guide
+keywords:
+  - sow reading guide founder
+  - dev shop contract review
+  - milestone acceptance clause
+  - code ownership contract clause
+  - non technical founder contract
+tags:
+  - founders
+  - non-technical-founder
+  - template
+  - course-companion
+  - hiring
+categories: ["Templates"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/sow-reading-guide/"
+related_posts: false
+---
+
+📋 Template companion to Module 5B of the [From Idea to First Paying Customer course](/course/tech-for-non-technical-founders-2026/). Read the night before you sign. Print, highlighter, 90 minutes alone.
+
+# The SOW Reading Guide
+
+An annotated sample SOW that catches the 8 clauses agencies hope you skim.
+
+By the time you finish your second coffee you will know whether the 47-page Statement of Work in front of you carries 3-5 clauses that will cost you more than the price of the project. You will not have read a line of code or talked to a lawyer. You will have walked one sample SOW clause by clause, marked the flags, and written the questions the agency needs to answer before you sign.
+
+## Why this exists
+
+A SaaS founder we picked up in late Q1 2026 had signed a **47-page SOW** her general counsel cleared the night before. He flagged the liability cap and the IP assignment, fixed both, called it done. She missed the **milestone acceptance clause**: it defined "delivered" as "deployed to staging" rather than "passing the acceptance criteria with production traffic." Three months in, she had paid for **four of five milestones**, every one sitting on a staging URL that 500'd on the second click. By the time she renegotiated, the agency had invoiced **$78K** for milestones nobody could use, and her runway had compressed from twelve months to seven. Most agencies are not malicious about SOW language; they start from a template that survived their last twelve clients, and the template has a few clauses that quietly favor the agency.
+
+## How to use it
+
+Read this **the night before you sign, alone**, with a printed SOW, a yellow highlighter, and 90 minutes blocked. Bring the SOW, your original RFP or feature wishlist, and this guide. Walk every clause against the 8 flags below; when a flag fires, write the question for the agency in the margin. Type all the questions into one email and send it before you sign anything. A working agency answers in writing and signs the redline. If your general counsel cleared the SOW already, run this anyway - generalist attorneys catch the IP and liability paragraphs and skim the operational ones, and the 8 clauses below are where the operational money lives.
+
+> **The 8-clause SOW scoreboard** - use this as a pre-flight checklist; details below:
+>
+> - [ ] **Clause 1 - Scope:** feature list at concrete shipping level + per-feature day estimate
+> - [ ] **Clause 2 - Milestone acceptance:** acceptance criteria in CI + click-through on staging + written sign-off (not "deployed = delivered")
+> - [ ] **Clause 3 - Change requests:** capped at 10-20% of SOW, written estimate, 48-hour approval window, no verbal approval
+> - [ ] **Clause 4 - IP / code ownership:** transfers per-milestone (not "upon final payment")
+> - [ ] **Clause 5 - Third-party dependencies:** every account under your email + card from Day 1, no 15% admin fee
+> - [ ] **Clause 6 - Termination triggers:** quality + missed-milestone triggers + termination-for-convenience with handover
+> - [ ] **Clause 7 - Post-launch warranty:** anchored to production launch (not "delivery"), ≥60 days, "warranted bug" defined
+> - [ ] **Clause 8 - Dispute resolution:** mediation step + neutral venue + prevailing-party fee-shift
+
+## The 8 clauses
+
+### Clause 1 - Scope definition
+
+> **Sample**: "Vendor will deliver the features described in Exhibit A. Detailed scope, including specific tickets, will be defined sprint by sprint with Client's product owner."
+
+**Plain English**: We do not know what we are building. We will figure it out and bill you for it.
+
+**Flag**: "Scope to be defined sprint by sprint", "agile discovery throughout", "exact features dependent on user research." Sounds collaborative; means the SOW is a blank cheque.
+
+**Fix**: Demand a feature list at the level of "a Rails 7 app with a Hotwire frontend, deployed via Kamal to Hetzner, with sign-up, contractor-match, payment, and an admin panel listing the last 100 jobs." Then ask for an estimate per feature in days, not story points. If they cannot estimate the work, they cannot price it. (See [the founder's guide to hiring a dev shop](/blog/founders-guide-hiring-dev-shop/) for what a real scope looks like.)
+
+### Clause 2 - Milestone acceptance
+
+> **Sample**: "A milestone shall be deemed delivered upon Vendor's deployment to the Client-accessible staging environment. Client shall have five (5) business days to raise objections; absent objections, the milestone is accepted and payable."
+
+**Plain English**: We get paid when we push code to a URL nobody uses. If you do not write a structured rejection in five days, the money is ours.
+
+**Flag**: "Delivered" defined as "deployed to staging" or "made available for review." Five-day silent-acceptance windows. No acceptance criteria the milestone has to pass.
+
+**Fix**: "A milestone is delivered when (a) the acceptance criteria in Exhibit B pass in CI (`bundle exec rspec` for Rails, `pytest` for Django, `php artisan test` for Laravel), (b) Client has clicked the feature end-to-end on the staging URL, and (c) Client has signed off in writing." Acceptance criteria belong in the SOW, not in a Slack message. The [Friday demo template](/course/tech-for-non-technical-founders-2026/friday-demo-template/) covers what the click-through looks like.
+
+### Clause 3 - Change-request process
+
+> **Sample**: "Any modification to Scope shall be processed via Change Order, billed at Vendor's standard rate of $185/hour. Vendor shall provide a written estimate prior to execution."
+
+**Plain English**: Anything you ask for after signing costs $185/hour with no ceiling. The estimate can be 4 hours or 400; you have nothing to compare it against.
+
+**Flag**: Hourly-rate change-orders with no cap, no estimate review window, and especially "Vendor may proceed upon Client's verbal approval."
+
+**Fix**: (1) Cap change orders at a percentage of the original SOW (10% standard, 20% generous). (2) Require a written estimate naming the developer, hours, and deliverable, with a 48-hour Founder-approval window. (3) Strike "verbal approval." Skip this and you end up with the [hidden-cost vendor management problem](/blog/hidden-cost-poor-development-vendor-management-fix/) on the AmEx statement.
+
+### Clause 4 - IP / code ownership
+
+The single highest-stakes clause in the SOW: who owns the code while you're paying for it. The bad version turns any future invoice dispute into a repo hostage situation. The good version transfers ownership invoice by invoice, so a dispute on milestone 4 cannot block milestones 1-3.
+
+|  | Sample language | What it means |
+|---|----------------|---------------|
+| **Bad** | "Upon Vendor's receipt of **all amounts due** under this Agreement, Vendor hereby assigns to Client all right, title, and interest in and to the Deliverables." | The agency owns the code until you have paid every invoice. If a milestone is disputed, the agency still owns everything. |
+| **Good** | "Upon Client's payment of **each milestone invoice**, Vendor irrevocably assigns to Client all right, title, and interest in the corresponding portion of the Deliverables, including all source code committed to the Client-owned GitHub repository as of that milestone's completion date." | Ownership moves milestone by milestone. A dispute on milestone 4 cannot hold milestones 1-3 hostage. |
+
+**Flag**: Ownership transfers only "upon final payment", "upon receipt of all amounts due", or "upon completion of the Project."
+
+**Fix**: Insert the good-version language above. Pair it with the [GitHub / AWS / database ownership checklist](/course/tech-for-non-technical-founders-2026/ownership-checklist/) so the assignment also moves the actual GitHub org owner row - the contract assignment is paper; the GitHub owner row is the actual control.
+
+### Clause 5 - Third-party dependencies
+
+> **Sample**: "Vendor shall manage all third-party services required for the Project, including hosting, third-party APIs, and AI/ML tooling. Costs shall be passed through to Client at cost plus a 15% administrative fee."
+
+**Plain English**: We will rent AWS, Stripe, and the AI tools under our own accounts and bill you whatever they cost, plus 15%. When this engagement ends, the accounts stay with us.
+
+**Flag**: Pass-through costs with no cap, no monthly attribution, and no language about who owns the third-party accounts. Watch AI token costs (Cursor seats, Anthropic API, OpenAI API) - the [5-question AI script](/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/) caught a $4,800 OpenAI line that surprised one founder we worked with.
+
+**Fix**: (1) Every third-party account (AWS, GitHub, Stripe, Anthropic, OpenAI) is created under your company email from Day 1, paid by your company card; the agency gets IAM sub-access. (2) Pass-through costs capped per month with a Founder-approval gate above the ceiling. (3) AI token usage itemized monthly per developer and per project. Strike the 15% admin fee on infrastructure.
+
+### Clause 6 - Termination triggers
+
+> **Sample**: "Either party may terminate for material breach by the other, provided thirty (30) days written notice and an opportunity to cure. Upon termination, Client shall pay Vendor for all work performed through the termination date."
+
+**Plain English**: You cannot walk away because we are slow, sloppy, or shipping bugs. Only paper breach counts, and even then we get 30 days to fix it.
+
+**What to redline** (four numbered insertions):
+
+1. **Quality trigger** - "Client may terminate immediately if Vendor misses the acceptance criteria for two consecutive milestones, or if test coverage on Vendor-written code falls below [agreed floor, e.g. 70%] for 30 consecutive days."
+2. **Missed-milestone trigger** - "Client may terminate immediately if any milestone slips more than 21 days past the SOW-stated delivery date without a Client-approved revised plan in writing."
+3. **Termination for convenience** - "Client may terminate at any time upon 30 days' written notice and payment of the next milestone fee as an exit fee."
+4. **Handover obligation** - "Upon termination for any reason, Vendor shall, within 30 days, deliver: (a) all source code in the Client-owned repository, (b) all credentials and secrets, (c) deployment and operations runbooks, and (d) a 60-minute call with the incoming engineering team."
+
+The [step-by-step exit guide](/blog/fire-dev-shop-guide/) covers what a clean termination looks like in practice once these triggers are in place.
+
+### Clause 7 - Post-launch warranty
+
+> **Sample**: "Vendor warrants that the Deliverables shall conform to the specifications for thirty (30) days following Delivery."
+
+**Plain English**: We will fix bugs free for 30 days after we declare the thing delivered. If "delivered" means "deployed to staging" (see Clause 2), the warranty might run out before users ever touch the feature.
+
+**Flag**: Warranty starts at "Delivery" rather than "Launch to Production Users." Windows under 60 days. No definition of warranted bug versus "new feature request."
+
+**Fix**: Anchor the warranty to **production launch**: "The warranty period begins on the date the Deliverables are first served to live, paying users in production, and runs for 90 days thereafter." Define "warranted bug" plainly: anything that blocks a user from completing a flow listed in Exhibit A. The opening-story founder lost three weeks of warranty coverage because three milestones were "delivered" to staging but never reached production.
+
+### Clause 8 - Dispute resolution
+
+> **Sample**: "Any dispute arising under this Agreement shall be finally resolved by binding arbitration administered by JAMS in [Vendor's home county, Vendor's home state]. Each party shall bear its own costs."
+
+**Plain English**: If we ever fight about money, you fly to our city, hire a local lawyer, and wait six to twelve months for an arbitrator we know to decide.
+
+**Flag**: Binding arbitration in the agency's home state. No mediation step before arbitration. "Each party bears its own costs" favors whichever party has more cash to wait you out.
+
+**Fix**: (1) Add a **mediation step**: "The parties shall attempt in good faith to resolve any dispute through non-binding mediation in [Client's home city] before initiating arbitration." Mediation resolves about 80% of commercial disputes. (2) Set the arbitration venue at a **neutral location** or split it by who initiates the claim. (3) Add a **prevailing-party fee-shift**: the loser pays the winner's reasonable attorney fees.
+
+## What to do before signing
+
+> **📋 Copy-pasteable pre-sign checklist - do this the night before you sign:**
+>
+> - [ ] Printed SOW in hand, yellow highlighter ready
+> - [ ] All 8 clauses walked (scorecard above). Every fired flag has a question written in the margin.
+> - [ ] Contract lawyer booked (1 call, $300-600, dev-shop SOW experience only)
+> - [ ] Redlined SOW saved + questions email + answers email in one dated folder
+
+> **📧 Copy-pasteable agency email - send before you sign anything:**
+>
+> Subject: `SOW review - [N] questions before we sign`
+>
+> Hi [agency contact],
+>
+> I walked the SOW last night with the [8-clause scoring guide](https://jetthoughts.com/course/tech-for-non-technical-founders-2026/sow-reading-guide/). A few questions below - happy to jump on a call, but please reply in writing so we both have the answers on file.
+>
+> [Numbered list of your fired-flag questions, one per clause. Example: "Clause 2 - Can we define milestone acceptance as: (a) acceptance criteria pass in CI, (b) I click the feature end-to-end on staging, (c) written sign-off - instead of 'deployed to staging = delivered'?"]
+>
+> Thanks,
+> [Your name]
+
+- **Send the agency one email with all your fired-flag questions, in writing.** Numbered list, every question tied to a clause. If they want to discuss it on a call, fine - the answers come back in writing afterwards.
+
+- **Get a one-call review from a contract lawyer who has reviewed at least 3 dev-shop SOWs**, typically $300-$600 for 60 minutes plus a one-page redline. Generalist business attorneys catch the IP and liability paragraphs and miss the operational ones. Ask specifically: "Do clauses 2, 3, 5, 6, and 7 favor the vendor?" The founder in the opening story would have saved $78K for $400.
+
+- **Save the redlined SOW + questions email + answers email together** in one folder, with the date in the filename. If a dispute lands in mediation eighteen months from now, this folder is the entire record.
+
+If the agency walks away from this exercise, the engagement was going to fail anyway. The next reads are the [dev shop red flags checklist](/blog/dev-shop-red-flags-checklist/) and the [5 questions to ask before hiring a dev shop](/blog/hiring-dev-shop-questions/).
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/admin-panel-spaceship.svg b/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/admin-panel-spaceship.svg
new file mode 100644
index 000000000..d92c24d40
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/admin-panel-spaceship.svg
@@ -0,0 +1,131 @@
+
+  The simple-admin-panel-to-spaceship anti-pattern, sketched.
+  A hand-drawn sketch with two panels. Left: a small admin panel mockup with three buttons (hide post, ban user, refund). A small label reads "What you asked for." Right: a giant control deck panel covered in 47 buttons, a role-permissions matrix, audit log, feature flags, multi-tenant switcher, and a co-pilot AI assistant. A label reads "What got built." A wavy arrow connects the two with the words "10-week build, $15K" along it.
+  
+    
+    
+      
+    
+  
+
+  
+
+  "A simple admin panel" → the spaceship that arrives 10 weeks later
+
+  
+  What you asked for
+
+  
+  Admin
+  
+
+  
+  Hide this post
+
+  
+  Ban this user
+
+  
+  Refund this charge
+
+  3 buttons
+  2 days of work
+  The one job you
+  actually had on Tuesday
+
+  
+  
+  10-week build · $15,000 · "interpreted the brief"
+
+  
+  What got built
+
+  
+  Admin Control Center v1.0
+  
+
+  
+  
+  Users
+  
+  Roles
+  
+  Audit
+  
+  Flags
+
+  
+  Role × Permission matrix
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
+  
+  Quick actions
+  
+    
+    
+    
+    
+    
+    
+
+    
+    
+    
+    
+    
+    
+
+    
+    
+    
+    
+    
+    
+
+    
+    
+    
+    
+    
+    
+  
+  (47 of them, mostly broken)
+
+  
+  
+  Multi-tenant org switcher ▾
+
+  
+  🤖 AI co-pilot · "Ask me anything"
+
+  5 tabs · 47 buttons · 1 role matrix
+  12 feature flags · 1 AI co-pilot
+  2 of these you actually use.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/cover.png b/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/cover.png
new file mode 100644
index 000000000..f0fa6dd77
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/feature-vs-outcome.svg b/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/feature-vs-outcome.svg
new file mode 100644
index 000000000..e9e5df0c5
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/feature-vs-outcome.svg
@@ -0,0 +1,120 @@
+
+  Feature-shaped brief vs outcome-shaped brief, with the system the engineer ends up building under each.
+  A side-by-side comparison. Left card is feature-shaped: a one-line brief "Build a CSV export button" leads down to a sketch of a full BI suite with eight modules, three dashboards, scheduled email reports, and a role matrix. Right card is outcome-shaped: a longer brief "When I prepare the weekly investor report, I want to grab the top 5 metrics in 30 seconds, so I can paste them into the deck before the call" leads down to a sketch of a single button labeled "Copy top 5 metrics" above a small data table.
+  
+    
+    
+      
+    
+  
+
+  
+
+  Same Friday brief. Two different builds.
+
+  
+  
+
+  
+  FEATURE
+
+  "Build a CSV export button"
+
+  (13 words. No persona, no context, no metric.)
+
+  
+  What the engineer builds
+
+  
+  
+  Reporting & Analytics Module v1
+
+  
+  Dashboards (3)
+
+  
+  Scheduled email
+
+  
+  Saved filters
+
+  
+  CSV / XLSX / PDF
+
+  
+  Custom columns
+
+  
+  Role-based access
+
+  
+  Date range picker
+
+  
+  Export queue
+
+  
+  Webhook on done
+
+  
+  Audit log of every export, retention policy, S3 archive
+
+  9 features. 6 weeks of build.
+  You used 1 of them: the CSV button.
+  The other 8 added support cost
+  and complicated the next change.
+
+  Bill: $18,400
+
+  
+  
+
+  
+  OUTCOME
+
+  "When I prepare the weekly
+  investor report, I want to grab
+  the top 5 metrics in 30 seconds,
+  so I can paste them into the deck
+  before the 4pm call."
+
+  (Same 13-second read. Names the moment, the
+  action, the result, the deadline.)
+
+  
+  What the engineer builds
+
+  
+  
+  Dashboard footer
+
+  
+  📋 Copy top 5 metrics to clipboard
+
+  MRR ………………………… £24,300
+  Net new MRR ……………… £1,840
+  Active accounts ……………… 312
+  Trial → paid conversion … 8.4%
+  Runway (months) ……………… 14
+
+  5 numbers. 1 button. 90 minutes to ship.
+
+  Bill: $420
+
diff --git a/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/index.md b/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/index.md
new file mode 100644
index 000000000..9d23d5419
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/index.md
@@ -0,0 +1,192 @@
+---
+title: "3.2 · Quality-check your brief: features to outcomes"
+aliases: ["/blog/stop-specifying-features-start-outcomes/"]
+description: "Chapter 3.2 of the From Idea to First Paying Customer course. The quality-gate on your Chapter 3.1 brief: rewrite Section 3 feature nouns as outcome-shaped job stories before handing off to Lovable or a contractor."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: stop-specifying-features-start-outcomes
+keywords:
+  - specify outcomes not features
+  - prevent over engineering founder
+  - founder feature spec template
+  - job stories non technical founder
+  - prevent admin panel spaceship
+tags:
+  - founders
+  - non-technical-founder
+  - course-companion
+  - product
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "3.2 · Quality-check your brief: features to outcomes"
+  og_description: "Chapter 3.2 of the From Idea to First Paying Customer course. The quality-gate on your Chapter 3.1 brief: rewrite Section 3 feature nouns as outcome-shaped job stories before handing off to Lovable or a contractor."
+cover_image_alt: "JetThoughts cover showing a simple three-button admin panel on the left and a 47-button spaceship control deck on the right, connected by a wavy red arrow labeled '10-week build, $15K'"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/"
+related_posts: false
+---
+
+> **Module 3 · Step 2 of 2** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a one-page Product Brief (from [Chapter 3.1](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/))
+>
+> **Output:** a one-page Product Brief rewritten so engineers and AI agents stop overengineering
+
+> **Jump to:** [What to do tomorrow](#what-to-do-tomorrow) · [Artifacts you carry out](#artifacts-you-carry-out-of-module-3)
+
+> **TL;DR:** Rewrite every feature noun as an outcome-shaped job story. "Build a CSV export" becomes "When I prepare the weekly report, I want to grab the top 5 metrics in 30 seconds." The engineer has nothing left to invent.
+
+> **Skip to the action:** [What to do tomorrow](#what-to-do-tomorrow) if you have your Ch 3.1 brief open and want the rewrite steps now. The examples and the theory will still be here.
+
+You sent your engineer (or your AI agent) a one-line spec: *"build a simple admin panel."* Ten weeks later you have an admin panel with 47 buttons, role-based permissions, an audit log, and a co-pilot AI assistant. Your engineer isn't a show-off - those four words "a simple admin panel" don't tell anyone what "simple" means, who's using the panel, or what the panel needs to do. The engineer (or the training data) filled in those blanks from every big-company SaaS panel they had ever seen.
+
+![A hand-drawn comparison: the simple three-button admin panel you asked for on the left, the absurdly complex 47-button control deck that got built on the right, connected by a red arrow labeled 10-week build, $15K](admin-panel-spaceship.svg)
+
+## Why feature briefs overbuild
+
+Engineers and AI agents fill vague requests from training data - big-company SaaS panels, GitHub-scraped baselines, the busiest version of whatever they last saw. A feature word in isolation ("CSV export," "user roles") has no anchor to your actual job, so the engineer or agent invents the missing context. An outcome-shaped request ("when I prepare the weekly investor report, I want to grab the top 5 metrics in 30 seconds before the 4pm call") leaves nothing for them to invent - the moment, the action, the deadline, and the result are already on the page.
+
+## Two briefs, two shapes each
+
+Same job, two ways to write it. Read each pair out loud. Notice how much the engineer or the agent has to invent under the feature shape, and how little they have to invent under the outcome shape.
+
+![Feature-shaped brief on the left leading to a sketched BI suite with nine modules; outcome-shaped brief on the right leading to a single 'Copy top 5 metrics' button with a five-row data table](feature-vs-outcome.svg)
+
+### Pair 1 - The CSV button
+
+**Feature shape**: *"Build a CSV export button on the dashboard."*
+
+**Outcome shape**: *"When I prepare the weekly investor report, I want to grab the top 5 metrics in 30 seconds, so I can paste them into the deck before the 4pm call."*
+
+What the engineer builds from the feature shape: a reporting module with three dashboards, scheduled email exports, role-based access on who can export, a date-range picker, custom column selectors, and an audit log of every download. Six weeks of work. You used the CSV button once a week for the investor email and ignored the other eight features.
+
+What the engineer builds from the outcome shape: one button at the bottom of the existing dashboard that says *"Copy top 5 metrics to clipboard,"* hard-coded to MRR, net new MRR, active accounts, trial-to-paid conversion, and runway. Ninety minutes of work in a Rails controller, one line per metric. The next investor email goes out before the deck even opens.
+
+### Pair 2 - The CRM module
+
+**Feature shape**: *"Build a CRM module."*
+
+**Outcome shape**: *"When a new customer signs up, the founder needs to see which 3 of our existing customers most resemble them, so we can pattern-match the onboarding playbook that worked for those three."*
+
+What the engineer builds from the feature shape: companies, contacts, deals, pipelines, activities, tasks, notes, custom fields, email integration, calendar integration, and a Kanban board nobody opens. Three months. You used the contacts list and the notes field.
+
+What the engineer builds from the outcome shape: a 30-line script that runs nightly, scores existing customers against the new signup on three attributes (industry, employee count, plan tier), and posts a Slack message every morning: *"New customer Acme Co looks most like Beta Inc, Gamma Ltd, and Delta GmbH - here are their onboarding notes."* Two days. The script is throwaway. When Salesforce is finally worth the bill, you import the script's three matches into the proper CRM record.
+
+## The three-part shape that constrains every spec
+
+Both outcome-shaped briefs in the section above use the same three parts. The shape works because each part forecloses a category of overbuild.
+
+**When [trigger context]** - the specific situation that activates the need. Names the moment, the day, the deadline, the surrounding tools. *"When I prepare the weekly investor report"* tells the engineer this happens once a week, that there is a deck involved, that there is a 4pm call. The engineer will not build a real-time streaming dashboard for something that happens on a Tuesday afternoon.
+
+**I want [internal motivation]** - what you are trying to do, expressed as a verb on a concrete object. *"I want to grab the top 5 metrics in 30 seconds"* is a verb (grab) and an object (the 5 metrics) and a budget (30 seconds). The engineer will not build a 12-metric dashboard because you said 5, and will not build an asynchronous export queue because you said 30 seconds.
+
+**So I can [outcome]** - the business or personal result that proves the build worked. *"So I can paste them into the deck before the 4pm call"* gives a finish line the engineer can hold up against any feature suggestion. The engineer can now say: *"Does the build let you paste into the deck before 4pm? Then we are done. Does the audit log help with that? No? Cut it."*
+
+Put the three parts together and the engineer (or the AI agent) has nowhere left to invent. Drop any one part - the timeframe, the action, or the outcome - and the gap gets filled in from training data instead of your intent. The same shape has a name in product-management literature; see *Further reading* below if you want to chase the lineage.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    Feature["FEATURE brief: Build a CRM module"]
+    Feature --> F1["Companies + contacts"]
+    Feature --> F2["Deals + pipelines"]
+    Feature --> F3["Email + calendar integration"]
+    Feature --> F4["Custom fields + Kanban"]
+    F1 --> FOut["3 months. $40K. You used contacts + notes."]
+    F2 --> FOut
+    F3 --> FOut
+    F4 --> FOut
+
+    Outcome["OUTCOME brief: Match new signups to 3 similar customers"]
+    Outcome --> O1["Nightly scoring script"]
+    Outcome --> O2["Slack message each morning"]
+    O1 --> OOut["2 days. $600. Onboarding playbook ready Monday."]
+    O2 --> OOut
+
+    classDef bad fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a
+    classDef good fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+
+    class Feature,F1,F2,F3,F4,FOut bad
+    class Outcome,O1,O2,OOut good
+```
+
+## What to do tomorrow
+
+Three actions, in order.
+
+- **Open your filled-in [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) from Chapter 3.1.** Find Section 3 ("What you're building"). Read the section out loud. If any line begins with a noun-shaped feature ("a CSV button," "a CRM," "user roles," "a settings page"), it is feature-shaped. Mark it.
+- **Rewrite each marked line in the *When / I want / So I can* shape.** The *when* has to name a specific moment with a deadline, the *I want* has to name a verb and a budget, and the *so I can* has to name a result you can measure that week. Keep the whole section to a single focused pass. If you spill, the section is too big - your one-page brief is trying to be three.
+- **Share the rewritten section with your engineer or your AI agent and ask exactly one question**: *"What would you build differently from this brief than you would have built from the feature list?"* Their first answer is the scope you were about to lose. Their second answer is the scope you are about to keep.
+
+> **The pass/fail rubric.** Read the peer's answer. The brief PASSES quality-check only if their answer stays inside your scope - the features in your Section 3 and the items NOT in your no-go list. The brief FAILS if their answer:
+>
+> - names any feature you didn't list in Section 3, OR
+> - mentions anything you explicitly cut in your no-go list, OR
+> - includes 2+ items outside the no-go list (your scope is too vague).
+>
+> FAIL = revise Section 3 outcome-shape and ask a fresh peer. Do NOT advance to Module 4 with a failed brief; the Lovable build will inherit the fuzziness.
+
+> **Module 3 AI critic/simulator block**
+>
+> **No peer available? Use Claude or ChatGPT as the peer.** Paste your full Section 3 + Section 5 (no-go list) into Claude, then paste this prompt:
+>
+> ```text
+> Imagine you are a contractor reading this brief to build the product. Based ONLY on Section 3, name 5 things you would build that are NOT in Section 5's no-go list. Be specific - feature names, not categories.
+> ```
+>
+> If Claude names 2+ items outside your no-go list, the brief failed quality-check the same as a peer flagging them. Revise Section 3 and re-run. This is the same failure signal a peer would surface, with no calendar coordination needed.
+>
+> **What AI cannot prove or substitute:**
+> - Whether your scope solves the validated problem (only the Module 4 build + real users can)
+> - Whether a real contractor would interpret the brief the same way (AI is a proxy, not a substitute)
+>
+> **The real gate:** a clean peer QA (human or AI) where the answer stays inside your scope AND no-go list.
+
+> The cheap fix for this whole pattern is the rewrite tomorrow morning. The expensive fix is the salvage decision you read after the spaceship lands and investors ask why the demo is so heavy. One focused pass with a marker now spares you the build-and-throwaway later.
+
+> **Optional: stack-rank features with real users.** After you have rewritten Section 3 as outcome-shaped job stories, you still have a list. If you need to know which outcome to build first, [OpinionX](https://opinionx.co) (free tier available) uses forced-ranking pairwise voting - users pick A or B, not rate everything "very important." Paste your 5-7 outcome statements, send the link to your Ch 2.3 (a + b) interviewees, and the forced-choice format surfaces real priorities that a 1-10 rating scale hides. The output is a ranked list backed by pairwise win rates, not averaged scores. Use this before handing the brief to Lovable or a contractor - it prevents the "build everything because everything scored 8/10" trap.
+
+## Artifacts you carry out of Module 3
+
+After finishing Ch 3.1-3.2, Sam has five artifacts. Each one feeds a specific downstream destination - this table is the map:
+
+| Artifact | Where it goes next |
+|---|---|
+| **One-Page Product Brief / Vibe PRD** (Ch 3.1 output) | Ch 4.1 build-path decision (the brief is the input the worksheet routes against) + Ch 4.3 (a + b) Lovable kickoff prompt. The single source of truth Module 4 builds from. |
+| **Outcome-shaped feature list** (Ch 3.2 rewrite of Section 3 in Job Story format) | Ch 4.1 contractor SOW (if you route to hire) + Ch 4.3 (a + b) Lovable prompt body. Replaces the noun-shaped feature list that causes overbuild. |
+| **No-Go list** (5-10 items you explicitly cut from Ch 3.1 Section 5) | Ch 4.3 (a + b) self-serve scope guard + Ch 4.4 ceiling-signal monitoring. The written "we are not building this yet" line that prevents Module 4 scope creep. |
+| **Audience-of-one fork** (the audience choice from Ch 3.1: AI agent / junior dev / senior team) | Ch 4.1 Q2 build-path routing. The fork decides whether the brief routes to Lovable (AI agent) or a contractor (junior or senior team). |
+| **Quality-check verdict** (Ch 3.2 - peer answers "what would you build differently?" cleanly?) | Checkpoint before Module 4. If the peer cannot answer cleanly, return to Ch 3.2 and rewrite Section 3 before opening Lovable or sending the SOW. |
+
+> **Module 3 closes here.** Before opening Module 4, you should have: (1) a one-page Product Brief (Vibe PRD) with 5 sections filled in (Ch 3.1), (2) Section 3 rewritten as outcome-shaped job stories that pass the peer "what would you build differently?" test (this chapter), and (3) a no-go list of 5-10 items you explicitly cut. Both in your `Founder OS` folder. Missing one? Go back - Module 4 reads the brief into Lovable prompts; a half-written brief produces a half-working MVP.
+
+When your brief skips the moment, the action, and the result, the engineer or the AI agent fills them in from training data. Name those three and there is nothing left for them to invent.
+
+## Further reading
+
+- Alan Klement, [*When Coffee and Kale Compete*](https://www.whencoffeeandkalecompete.com/) - the book that introduced the *When / I want / So I can* shape under the name "Job Stories" in 2013. The framework is worth chasing once your team is bigger than two; the shape is worth using tomorrow.
+- Marty Cagan, [Product vs Feature Teams](https://www.svpg.com/product-vs-feature-teams/) - the canonical essay on why product teams (chartered with outcomes) ship better than feature teams (chartered with feature lists).
+- Veracode, [GenAI Code Security Report 2025](https://www.veracode.com/blog/genai-code-security-report/) - 45% of LLM-generated code shipped at least one exploitable security flaw. Vague briefs amplify the rate.
+- DHH, [The One Person Framework](https://world.hey.com/dhh/the-one-person-framework-711e6318) - the Rails case for keeping the architecture small enough that one developer can ship outcomes end-to-end.
+- Basecamp / Ryan Singer, [Shape Up - Appetite vs Estimate](https://basecamp.com/shapeup/1.2-chapter-03) - the chapter on writing pitches that fix the appetite first, so the build collapses to fit.
+- Tom Kerwin, [JTBD Job Stories vs User Stories](https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27) - the 2013 Klement piece on Medium that popularised the shape, for readers who want the original 1,500 words.
+- Y Combinator, [Startup School: How to Write a Product Spec](https://www.ycombinator.com/library/) - YC's distilled take on specs that ship versus specs that sit.
+
+> **Done when:** Every feature in Section 3 of your brief is rewritten as an outcome-shaped job story, and a peer (or Claude) confirms the brief stays inside your scope and no-go list.
+> **Next click:** [4.1 · Should You Hire? The 2026 Decision Tree](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/)
+> **If blocked:** If Claude names 2+ items outside your no-go list when you run the quality-check prompt, your Section 3 is still too vague. Tighten the "When / I want / So I can" shape until Claude's answer stays inside your scope.
+
+> **Stuck? Most first-timers stall here:** every feature in Section 3 looks equally important, so the list keeps growing. **Fix:** pick the ONE outcome that would make a real customer pay or stay. Build that. Cut the rest to the no-go list. You can add them back after the first pilot in Module 5.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: Rewrites 3 feature-nouns as job stories. Example: "When a Stripe transaction has no matching QuickBooks invoice, I want to see the top 3 candidate matches so I can confirm in one click - not scan 200 line items." Passes the outcome filter: 4 of 5 sections are now outcomes, not features.
+>
+> **Mia**: Rewrites 3 feature-nouns as job stories. Example: "When I search for a math tutor for my 10-year-old with dyslexia, I want to filter by 'dyslexia-trained' and see reviews from other parents - not scroll 50 generic math tutors." Passes: 5 of 5 sections are outcomes.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/cover.png b/content/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/cover.png
new file mode 100644
index 000000000..5b7f5c070
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/index.md b/content/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/index.md
new file mode 100644
index 000000000..bf8093921
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/index.md
@@ -0,0 +1,120 @@
+---
+title: "6.4 · Three Questions That Turn Standup Into Proof"
+aliases: ["/blog/three-questions-turn-standup-into-proof/"]
+description: "Three questions a non-technical founder can ask in any daily standup to tell shipping from stalling. Pass/fail signals, follow-ups, the Friday demo pairing."
+date: 2026-05-18
+course_chapter: true
+author: "JetThoughts Team"
+slug: three-questions-turn-standup-into-proof
+keywords:
+  - founder questions for daily standup
+  - daily standup non-technical founder
+  - agile standup script
+  - engineering team accountability questions
+  - standup BS detection
+tags:
+  - founders
+  - non-technical-founder
+  - dev-shop-management
+  - agile
+categories: ["Founders"]
+related_posts: false
+course_nav: false
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "6.4 · Three Questions That Turn Standup Into Proof"
+  og_description: "Three questions a non-technical founder can ask in any daily standup to tell shipping from stalling. Pass/fail signals, follow-ups, the Friday demo pairing."
+cover_image_alt: "JetThoughts blog cover for Three Questions That Turn a Standup Into Proof showing three numbered question cards on a redacted Jira board"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/"
+---
+
+> **Chapter 5.4 · Step 3 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a team in place + a signed SOW
+>
+> **Output:** a weekly oversight rhythm where the daily standup answers "did anything ship?"
+
+**Supplementary content.** This chapter assumes you have a hired team. If you're still on the [self-serve path](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/), bookmark this and return when you graduate to a hired team.
+
+*"Yesterday I worked on the order flow. Today I am continuing the order flow."* A SaaS founder we picked up in Q2 2026 had heard that sentence on her **$25K/month project for nine weeks** before she clocked that two of her three developers were reading out the same Jira ticket name every day. **47 standups in.** Nobody had flagged that the ticket had not moved columns in seven weeks. She had been on every call, taken notes, and nodded.
+
+> **The 3 questions - printable index-card format:**
+>
+> **Q1.** Show me the staging URL of what shipped yesterday.
+> **Q2.** Walk me through one PR you reviewed yesterday - what you looked for, what you flagged.
+> **Q3.** What did we cut, descope, or postpone yesterday to ship that?
+
+## Why standups stopped working in 2026
+
+Most non-technical founders inherit the daily standup ritual without ever being told what good looks like. Their PM or agency lead schedules a fifteen-minute call, the team answers three questions in order, and the founder leaves the call feeling oriented. Whether anything shipped is a separate question, and the standup format does not force it. [Atlassian's own guide to daily standups](https://www.atlassian.com/agile/scrum/standups) flags exactly this risk: standups drift into status theatre unless someone is asking the questions that surface working software.
+
+AI-augmented developers compound the problem. A single developer can land five pull requests a day with no observable feature progress - refactors, dependency bumps, prompt tweaks, generated tests that pass because they test nothing. The founder watching the call sees motion. The product does not move. [Qodo's 2025 State of AI Code Quality report](https://www.qodo.ai/reports/state-of-ai-code-quality/) found AI-generated code produces 1.7x more issues than human-written code at the same line count, and most of those issues hide inside the kind of work that sounds productive in a standup answer.
+
+The three questions below replace the standard format. You do not have to drop the standard format - just bolt these on at the end and watch what happens.
+
+## The three questions
+
+| Question | Pass looks like | Fail looks like | Follow-up when it fails |
+|----------|----------------|-----------------|------------------------|
+| **Q1.** Show me the staging URL of what shipped yesterday. | A clickable URL + route + test credentials. You click during the call and reach the screen. | "It's in PR review." / "On staging by Friday." / "I'll Loom it after standup." | "What was the blocker?" Listen for a named person + specific tactic, not "still working on it." |
+| **Q2.** Walk me through one PR you reviewed yesterday - what you flagged. | Named PR # + named reviewer + 2-3 specific things checked (missing test, unauthorized gem, hardcoded key). | "We trust each other's work." / "CI caught the issues." / "Everyone reviews their own when busy." | "How many distinct reviewers approved code on my repo last week, and what is the average PR-open-to-merge time?" Want ≥2 reviewers and <2 days. |
+| **Q3.** What did we cut, descope, or postpone yesterday to ship that? | A specific cut + the reason (e.g., "dropped the date-range picker because v1 only needs last-30-days, saved 3 days of front-end work"). | "Nothing was cut." / Silence. / "We built everything in the spec." | "Name one backlog item that, if cut today, would have zero impact on this month's user feedback." Good answer in <30 seconds. |
+
+The per-question detail below explains the failure modes each question catches, why the answers look the way they do, and how to handle the awkward silence when a developer hears one of these for the first time.
+
+### Q1: "Show me the staging URL of what shipped yesterday."
+
+The question catches the **progress mirage** - tickets moving on Jira while nothing reaches a place the founder can click. Pain #12 in [our ICP profile](/blog/checklist-for-non-tech-founder-agile/) and the single most common signal across our 40+ rescues.
+
+**Pass.** A clickable URL with a specific route. "It is live at `staging.acme.app/checkout/v2`. Use `founder@test.com / demo1234`. The Stripe webhook fires on test card `4242 4242 4242 4242`." You should be able to click it during the call and reach the screen the developer described.
+
+**Fail.** "It is in PR review." / "It will be on staging by Friday." / "I can record a Loom after the standup." All three mean the same thing: nothing shipped yesterday, and the team is hoping you accept process motion as evidence of product motion. A Loom recorded after the fact is not staging - it is a video the team controls.
+
+**Follow-up if fail.** Ask: "What was the blocker?" Listen for a specific person (the reviewer, the DevOps engineer, the lead waiting on you) and a specific tactic (the broken migration, the failed CI step). "We are still working on it" is not an answer; it is the absence of one. If the same blocker appears three days running, the standup has surfaced a real problem - good. That is what the question is for.
+
+### Q2: "Walk me through one PR you reviewed yesterday - what you looked for, what you flagged."
+
+The question catches **rubber-stamp reviews** and **bus factor of one** - the failure mode where every pull request gets approved by the same senior in under two minutes, or worse, by another junior who knows less than the author. Will Larson, who ran engineering at Stripe and Carta, [treats the pull request funnel as the load-bearing signal](https://review.firstround.com/unexpected-anti-patterns-for-engineering-leaders-lessons-from-stripe-uber-carta/) for engineering health. Founders should too.
+
+**Pass.** A named PR number, a named reviewer (not "the team"), and 2-3 specific things the reviewer checked. "PR #847, Marcus reviewed it. He flagged a missing test on the refund branch, asked why the `Gemfile.lock` had a new gem he had not approved, and pushed back on a hardcoded Stripe key in the controller. The author fixed all three and Marcus re-approved Tuesday at 4pm." The texture is what tells you - real reviews leave a trail of pushback.
+
+**Fail.** "We trust each other's work." / "The CI caught the issues." / "Everyone reviews their own when the others are busy." First answer means there is no review. Second answer is a fundamental misunderstanding of what CI does - CI catches syntax errors and broken tests, not security gaps, not architectural drift, not the migration that locks the orders table at peak hours. Third answer is the [bus factor of one](/blog/dev-shop-red-flags-checklist/) JT's red-flags checklist warns about.
+
+**Follow-up if fail.** Ask: "How many reviewers approved code on my repo last week, and what is the average time from PR open to merge?" The first number wants to be at least two distinct humans, ideally three. The second number wants to be under two days. A FinTech founder we picked up in Q1 2026 ran this check and found one reviewer had approved 38 of the last 41 PRs, with an average time-to-merge of nineteen minutes. That is not review; that is a rubber stamp with a typing delay.
+
+### Q3: "What did we cut, descope, or postpone yesterday to ship that?"
+
+The question catches **over-engineering** - the failure mode where the team builds three features when the spec asked for one, or builds a custom admin panel for an MVP that needs a Postgres console. [Eric Ries defined the MVP](https://leanstartup.co/resources/articles/what-is-an-mvp/) as the smallest version that produces validated learning. A team that never cuts anything is not building an MVP; it is building a wishlist.
+
+**Pass.** A specific thing the team postponed, and the reason. "We postponed the admin override screen because the users do not need it for v1 - we will handle plan changes through a Postgres query for the first month. Saved roughly two days." The reason matters as much as the cut. "We dropped the date-range picker on the dashboard because the v1 spec only needed last-30-days, and the picker was adding three days of front-end work." Cuts with reasons mean the team is making product trade-offs out loud.
+
+**Fail.** "Nothing was cut." / Silence. / "We built everything in the spec." The first two mean the team is either over-engineering invisibly or is afraid to admit anything was descoped. The third answer is the most expensive one to hear - it means the team is building exactly what the spec said, including the parts the founder no longer needs, because pushing back on scope feels riskier than billing for two extra weeks.
+
+**Follow-up if fail.** Ask: "What is one thing in the current sprint backlog that, if we cut it today, would have no impact on this month's user feedback?" The good answer names something concrete in under thirty seconds. A team that needs five minutes to find anything cut-able is shipping every scope item by default, which is a different way of saying the scope was wrong from kickoff.
+
+## How this pairs with the Friday demo
+
+The three standup questions are the daily proof. The [Friday demo](/blog/dev-shop-red-flags-checklist/) is the weekly proof. Together they form a single weekly cadence: five standups answer "did anything ship today?" and Friday answers "what is the working software for the week?" Without both, the daily check feels like nagging and the weekly demo feels like theatre. With both, the daily check feeds the demo - by Friday afternoon the founder already knows what should be on staging because she has been clicking the URLs all week.
+
+[Atlassian's 2024 update on standups](https://www.atlassian.com/agile/scrum/standups) and the [Scrum Alliance's reference on async standups](https://resources.scrumalliance.org/Article/async-standups) both note that the daily ritual works only when it surfaces blockers. The three questions above are how you make blockers visible. The Friday demo is how you make working software visible. Together they replace the founder's anxiety about whether the team is shipping with a record of what shipped, week by week. The companion [Friday Demo Template](/blog/dev-shop-red-flags-checklist/) - the lead magnet for post 4 of this curriculum - holds the full script.
+
+## What to do tomorrow
+
+Print these three questions on an index card and bring it to tomorrow morning's standup. Do not announce a new format - just ask them at the end, in order, after the team finishes the usual three. Write down the answers in a Notion note or a Loom transcript. Watch for the pass / fail texture: a clickable URL versus a promise, a named reviewer versus "we", a specific cut versus silence.
+
+After five standups, score the week. Out of five working days, how many produced a clickable staging URL you could hit from your laptop? If the answer is two or fewer, the team is not shipping at the cadence the bill rate implies. If the answer is zero, that is not a standup problem; that is a stalled project, and the standup just told you. Forward your five days of notes to a fractional CTO or developer-friend - ideally before the next sprint planning meeting.
+
+If your team's PR reviewer count over the same five days is one human approving everything, that is the bus factor problem. If your team cut nothing across five days, that is the over-engineering problem. Same three questions, three different failure modes, each with its own fix.
+
+If most of the week's answers came back as fails, the problem is not the standup format - the standup is doing its job. The next step is cross-checking your last two weeks of standup notes against the [eight red flags checklist](/blog/dev-shop-red-flags-checklist/), your repo's PR history, and the names on your reviewers. If three or more flags fire, you have a team problem, not a process problem. The [15-minute team-health assessment](/blog/how-to-assess-engineering-team-health-15-minutes-non-technical-founder/) is the next read.
+
+## Further reading
+
+- Atlassian, [Daily Standup Meetings](https://www.atlassian.com/agile/scrum/standups) - the canonical reference on the three-question format and the failure modes it slides into.
+- Will Larson (via First Round Review), [Engineering leadership anti-patterns from Stripe, Uber, Carta](https://review.firstround.com/unexpected-anti-patterns-for-engineering-leaders-lessons-from-stripe-uber-carta/) - on the pull request funnel as the load-bearing signal for engineering health.
+- Eric Ries via Lean Startup Co., [What Is an MVP?](https://leanstartup.co/resources/articles/what-is-an-mvp/) - the validated-learning framing that makes "what did we cut?" a real product question.
+- DHH, [The One Person Framework](https://world.hey.com/dhh/the-one-person-framework-711e6318) - the Rails case for full-stack developers shipping end-to-end.
+- Qodo, [State of AI Code Quality 2025](https://www.qodo.ai/reports/state-of-ai-code-quality/) - 1.7x more issues in AI-generated code; useful context for why PR review questions matter more in 2026.
+- Scrum Alliance, [Async Standups](https://resources.scrumalliance.org/Article/async-standups) - on running written standups when the team is distributed, with the same three-question backbone.
+- Martin Fowler, [It's Not Just Standing Up: Patterns for Daily Standup Meetings](https://martinfowler.com/articles/itsNotJustStandingUp.html) - a deep practitioner reference on what daily standups should produce and when they fail.
diff --git a/content/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/cover.png b/content/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/cover.png
new file mode 100644
index 000000000..df5630865
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/index.md b/content/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/index.md
new file mode 100644
index 000000000..2ce357d8e
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/index.md
@@ -0,0 +1,196 @@
+---
+title: "Validated Problem Statement Template"
+aliases: ["/blog/validated-problem-statement-template/"]
+description: "The one-page template that synthesizes 10 Mom Test interviews into a build/pivot/kill decision. Print, fill in 30 minutes, show to 2 advisors."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: validated-problem-statement-template
+keywords:
+  - founder validated problem template
+  - one page problem statement
+  - pre-build decision
+  - customer interview synthesis
+  - pivot kill build framework
+tags:
+  - founders
+  - non-technical-founder
+  - template
+  - course-companion
+  - validation
+categories: ["Templates"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/"
+related_posts: false
+---
+
+📋 Template companion to [the Mom Test synthesis section](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/#synthesis-write-down-what-you-heard-decide-whats-next). Print after running 10 interviews. Fill in 30 minutes. Show to 2 advisors before building anything.
+
+# Validated Problem Statement Template - One Page, Five Sections
+
+*The synthesis sheet that turns 10 Mom Test transcripts into a build, pivot, or kill decision.*
+
+> **The Validated Problem Statement (one-page, 5 sections)**
+>
+> 1. **Who has the problem** - persona, vertical, strong-signal count
+> 2. **What it costs them** - hours per week, dollars per month, one sanity quote
+> 3. **What they've tried** - 3 workarounds + why each failed
+> 4. **Why now** - trigger event in last 12 months + market shift
+> 5. **How big is the pain** - average + strong-signal score → BUILD / PIVOT / KILL
+>
+> Fill in order Mon morning. Send to one founder friend by Mon EOD.
+
+## Why this exists
+
+A solo founder I spoke with last month sent 47 cold DMs to Twitter strangers complaining about their CRM. Twelve answered. Of the twelve, two said yes and ten said honest, paragraph-long no's. She had spent six weekends collecting transcripts in a folder labeled `notes`. When she opened the folder to write the problem statement, she realized she had never named the persona, never tallied the strong signals, and never written the why-now. The ten no's looked alike in her memory and contradicted each other on the page. Half of them were not even the persona she was building for. The synthesis took 90 minutes the first time she sat down to do it - and the decision the page produced was *pivot to a different ICP* rather than *build*. She kept the calendar she would have spent prompting Lovable and ran 5 sharper interviews instead. This template is the page she filled in.
+
+## How to use this
+
+Block 90 minutes on a single morning. Print the template (or copy the markdown version below into a Notion doc). Bring all 10 interview transcripts, your handwritten Q4 scores, your emotional-flag counts.
+
+The order matters. Score first, count second, write the page third. Write the page before scoring and you write the page you wished the calls had returned, not the page the transcripts actually support. The friction of writing the score before the prose is what stops you from talking yourself into the build.
+
+Take the filled page to 2 readers within 48 hours. One advisor (a founder one step ahead, a fractional CTO, a board member). One peer (another founder still pre-launch). Ask each: "Would you argue with this?" If both nod, you're done with Module 3. If either picks a fight on the persona, the cost, or the why-now, you have your next 5 interviews to run.
+
+Total time budget: 30 minutes to write, 48 hours to circulate, 1 hour to incorporate the 2 advisor reads. Hard cap at 3 hours total. Beyond that, you're polishing instead of validating.
+
+## The template - copy and paste
+
+Use the markdown block below directly in Notion, or print the PDF version (the SVG version of the page is embedded in the [Mom Test synthesis section](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/#synthesis-write-down-what-you-heard-decide-whats-next)).
+
+```text
+================ VALIDATED PROBLEM STATEMENT ================
+
+Founder name: ________________________  Date: ____________
+
+Interview sample: 10 calls, between ___/___ and ___/___.
+
+-------------------------------------------------------------
+1. WHO HAS THE PROBLEM
+-------------------------------------------------------------
+
+Persona (named, specific):
+____________________________________________________________
+
+Industry / vertical (one, not many):
+____________________________________________________________
+
+Of 10 interviewees, this many confirmed the problem:  ___ /10
+
+Quote from a strong-signal call (one sentence, verbatim):
+"___________________________________________________________"
+
+-------------------------------------------------------------
+2. WHAT IT COSTS THEM
+-------------------------------------------------------------
+
+Time per week:        _____ hours
+Money per month:      $_______
+Sanity cost (one concrete moment from a transcript):
+"___________________________________________________________"
+
+Cost is consistent across the 10 calls (Y/N): _____
+
+-------------------------------------------------------------
+3. WHAT THEY'VE TRIED
+-------------------------------------------------------------
+
+Workaround 1: ______________________  Why it failed: _______
+Workaround 2: ______________________  Why it failed: _______
+Workaround 3: ______________________  Why it failed: _______
+
+Current spend on workarounds: $_______ /month (average)
+
+The workaround is the budget your product would replace.
+Name the closest competitor: ______________________________
+
+-------------------------------------------------------------
+4. WHY NOW
+-------------------------------------------------------------
+
+Trigger event (what changed in last 12 months):
+____________________________________________________________
+
+Market shift (regulation, AI cost, platform, behavior):
+____________________________________________________________
+
+If this section is empty, the why-now is missing.
+A missing why-now usually means the idea is good and the
+timing is wrong - park it, run a smoke-test landing page,
+revisit in 6 months.
+
+-------------------------------------------------------------
+5. HOW BIG IS THE PAIN
+-------------------------------------------------------------
+
+Average pain score across 10 calls (Q4 + emotional flags):
+______ /10
+
+Strong signals (score 7+ with 3+ emotional flags): ___ /10
+
+Decision based on strong-signal count:
+ [ ] 7 or more  → BUILD. Move to Module 4.
+ [ ] 4 to 6     → PIVOT. Run 5 sharper interviews.
+ [ ] Fewer than 4 → KILL. Find a different problem.
+
+-------------------------------------------------------------
+ADVISOR SIGN-OFF
+-------------------------------------------------------------
+
+Advisor 1 name + role: ___________________________________
+Advisor 1 says (one sentence): ___________________________
+Date: ______________
+
+Advisor 2 name + role: ___________________________________
+Advisor 2 says (one sentence): ___________________________
+Date: ______________
+
+============================================================
+```
+
+## What good looks like vs what bad looks like
+
+**Section 1 - Who has the problem**
+
+> Bad: *"Founders and small business owners who need help with productivity."*
+
+> Good: *"Pre-seed B2B SaaS founders running their own bookkeeping reconciliation between Stripe, QuickBooks, and a Google Sheet. 8 of 10 interviewees confirmed (industry: vertical SaaS, May 2026 sample). Quote: 'Last Tuesday at 9pm I spent 40 minutes copying Stripe payouts into my QuickBooks ledger. I called my CFO. She did it in 90 seconds. I felt stupid.'"*
+
+The good version names the persona by stage, industry, and the specific workflow. It puts a number on the strong-signal count and includes one verbatim quote. A peer can argue with it: "Are you sure pre-seed is the right segment? Wouldn't seed-to-Series-A be the buyer?" That argument is exactly the value. The bad version is too broad to argue with, which is why advisors nod and the post-launch failure mode is *crickets*.
+
+**Section 2 - What it costs them**
+
+> Bad: *"It costs them time and money. It's a significant pain point."*
+
+> Good: *"6 hours per week. £800 per month in CFO contractor time. One founder I spoke with paid $1,500 for a SurveyMonkey panel after the bookkeeping pain spiked - the panel returned 47 useless responses and she did the work herself anyway. Cost was consistent across 8 of 10 calls; 2 were running their own pre-revenue and had zero contractor spend (but 12 hours of personal time per week)."*
+
+The good version uses real numbers from transcripts. The £1,500 panel anecdote is from a specific person. The 6 hours and £800 are averages with the sample's variance noted. The bad version is unfilled white space dressed up as prose.
+
+**Section 4 - Why now**
+
+> Bad: *"AI is changing everything. The market is ready."*
+
+> Good: *"AI inference cost for the document-classification step fell from $0.04 to $0.001 per call between 2024 and 2026 - the unit economics flip at $9/month per seat. Stripe's automated tax product (launching Q1 2026) signals SMB finance is being deconstructed feature by feature, but bookkeeping reconciliation at pre-seed founder budgets is still manual."*
+
+The good version names the specific cost number, the specific competitor's specific product, and the specific gap. It cites a competitor signal that *supports* the timing rather than refuting it. The bad version is filler that means nothing and helps no one.
+
+## What to do after
+
+The decision the filled page makes for you:
+
+- **BUILD** if: 7+ strong-signal calls (score 7+ with 3+ emotional flags), a named workaround the customer is already paying for, and a named why-now from the last 12 months. Move to [Module 3 Product Brief](/course/tech-for-non-technical-founders-2026/).
+- **PIVOT** if: 4-6 strong signals, OR the pain is real but belongs to a different persona than you targeted (e.g., you interviewed founders but the pain lives with their CFOs). Run 5 sharper interviews with the corrected ICP, then refill this page.
+- **KILL** if: fewer than 4 strong signals OR no workaround surfaced in the 10 interviews. Find a different problem and write the 200-word post-mortem below.
+
+Then walk the page through these four moves:
+
+- **Get 2 advisor signatures within 48 hours.** Email the page as a PDF. Ask: "Would you argue with this problem statement?" One sentence response is enough. If both say no, you've passed Module 2's checkpoint and you move to the [Module 3 Product Brief](/course/tech-for-non-technical-founders-2026/) next.
+- **If you landed in the BUILD lane (7+ strong signals), run the 3 pre-orders test before writing code.** Email your 5 strongest-signal interviewees. Ask each for a £500 deposit, a signed letter of intent, or a paid waitlist slot. Three yes-and-paid out of five = build. Zero yes = the 7+ scores were politer than you thought, slide back to pivot.
+- **If you landed in the PIVOT lane (4-6), pick the cleanest segment and run 5 sharper interviews using [the Mom Test interview script](/course/tech-for-non-technical-founders-2026/mom-test-interview-script/) again.** Don't rerun the same 10 - they've already given you their honest answer. New segment, new interviews, one week.
+- **If you landed in the KILL lane (fewer than 4), write a 200-word post-mortem to your future self.** What ICP did you pick wrong? What why-now did you assume that wasn't true? What workaround did you not learn about until interview 7? The post-mortem is the most valuable artifact from a kill round - it stops you from picking the same wrong target again next quarter. The [stop-AI-obsession validation post](/blog/stop-ai-obsession-smart-way-validate-your-startup-idea-product-bootstrap/) has the long version of the discipline.
+
+Skip the synthesis page and start prompting straight away and you're the founder who, six weeks later, posts a [salvage or rebuild question](/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/) about a working MVP nobody wants. The page is cheap. The build round you skip because of the page is the expensive thing you avoid.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/validation-tools-field-guide/cover.png b/content/course/tech-for-non-technical-founders-2026/validation-tools-field-guide/cover.png
new file mode 100644
index 000000000..06719ed14
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/validation-tools-field-guide/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/validation-tools-field-guide/index.md b/content/course/tech-for-non-technical-founders-2026/validation-tools-field-guide/index.md
new file mode 100644
index 000000000..748bff1ec
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/validation-tools-field-guide/index.md
@@ -0,0 +1,309 @@
+---
+title: "Validation Tools Field Guide"
+aliases: ["/blog/validation-tools-field-guide/"]
+description: "How to use VenturusAI, DimeADozen, and Preuve AI to stress-test your hypothesis before you book the first interview. Per-tool input prep, report reading guide, common mistakes, and a recommended workflow."
+date: 2026-06-05
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: validation-tools-field-guide
+keywords:
+  - business idea validation tools 2026
+  - VenturusAI how to use
+  - DimeADozen report guide
+  - Preuve AI founder tutorial
+  - pre-interview AI validation
+tags:
+  - founders
+  - non-technical-founder
+  - validation
+  - course-reference
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "Validation Tools Field Guide - JetThoughts Course"
+  og_description: "How to use VenturusAI, DimeADozen, and Preuve AI to stress-test your hypothesis before you book the first interview."
+cover_image_alt: "Validation tools field guide cover showing three AI validation tools"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/validation-tools-field-guide/"
+related_posts: false
+---
+
+> **Course reference** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) course.
+> Companion to [Ch 1.1: Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/). Read this when you are filling in the five blanks of the Mad Libs sentence and want a structured second opinion before you book the first interview.
+
+You are about to write a one-sentence hypothesis that names your customer, problem, approach, competition, and differentiation. The sentence will anchor every interview, every landing-page headline, and every build decision for the next three months. Before you commit it to your `Founding Hypothesis` Google Doc, push it through one or two validation tools.
+
+This guide covers three tools - VenturusAI, DimeADozen, and Preuve AI - with enough detail to use each one productively in under ten minutes. All three are pre-interview research aids. They do not replace Ch 2.1's ten Mom Test interviews.
+
+---
+
+## Why use validation tools
+
+Write the Mad Libs sentence in five minutes and you'll fall in love with it. Run it through one validation tool first and you'll find the blank you were vague about before it costs you ten interviews.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    Draft(["Draft hypothesis
(rough Mad Libs sentence)"])
+    Draft --> V[VenturusAI
SWOT + PESTEL + Porter
~30s · Free tier]
+    Draft --> D[DimeADozen
7-section validation brief
~2min · $9 Starter]
+    Draft --> P[Preuve AI
50+ data sources
~60s · Free scan]
+    V --> Catch(["Catches: weak differentiation
+ missed competitors"])
+    D --> Sizing(["Catches: wrong unit economics
+ market too small"])
+    P --> Niche(["Catches: customer too broad
+ market signal"])
+    Catch --> Refine[Rewrite the blanks the tools flagged]
+    Sizing --> Refine
+    Niche --> Refine
+    Refine --> Out(["Sharpened hypothesis
ready for Ch 2.1 interviews"])
+
+    classDef draft fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a
+    classDef tool fill:#fff5f5,stroke:#cc342d,stroke-width:2px,color:#1a1a1a
+    classDef catch fill:#faf5ff,stroke:#a855f7,stroke-width:2px,color:#1a1a1a
+    classDef refine fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef out fill:#fffbe6,stroke:#bf8a00,stroke-width:2.5px,color:#1a1a1a
+
+    class Draft draft
+    class V,D,P tool
+    class Catch,Sizing,Niche catch
+    class Refine refine
+    class Out out
+```
+
+The tools catch different things:
+
+| Blind spot | Which tool catches it |
+|---|---|
+| You named a competitor nobody has heard of (or missed the one everyone uses) | VenturusAI (Porter's Five Forces) |
+| Your [customer] blank is "small businesses" - a category, not a person | Preuve AI (niche-segment scan) |
+| Your unit economics assume $50/mo pricing when the market pays $15 | DimeADozen (retention-curve section) |
+| Your problem is real but the market is too small to support a business | DimeADozen (market-sizing section) |
+| Your [differentiation] is "easier to use" - the vaguest claim in SaaS | VenturusAI (SWOT strengths section flags it) |
+
+None of these tools costs more than a month of Perplexity Pro. Two are free. Run at least one before you fill the five blanks.
+
+---
+
+## Quick comparison
+
+| Tool | What it does | Price | Best for |
+|---|---|---|---|
+| **VenturusAI** | SWOT, PESTEL, Porter's Five Forces strategic frameworks (~30s) | Free tier (1,000 chars) / Pro from $10/mo | Spotting structural blind spots in your business model |
+| **DimeADozen** | 7-section validation brief with kill-risks and market sizing (~2 min) | $9 Starter / $129 Entrepreneur | A brutal second opinion on whether the idea has legs |
+| **Preuve AI** | Evidence-based scoring from 50+ live data sources with source links (~60s) | Free scan / $29 Founder Report | Data-backed market signal check (not LLM hallucination) |
+
+---
+
+## VenturusAI
+
+### What it does
+
+VenturusAI runs your business idea through three classic strategic frameworks - SWOT (Strengths, Weaknesses, Opportunities, Threats), PESTEL (Political, Economic, Social, Technological, Environmental, Legal forces), and Porter's Five Forces (Buyer Power, Supplier Power, Threat of Substitution, Competitive Rivalry, Threat of New Entrants). It also produces sections on target audience, marketing strategy, and financial estimates.
+
+Think of it as a free MBA student who reads your one-paragraph description and produces a structured critique in 30 seconds. The frameworks are academic, but the output is surprisingly practical when your input is specific.
+
+### What to prepare before you open it
+
+Write a 2-4 sentence paragraph covering four things. Do not open the tool until this paragraph is written:
+
+1. **What you are building** - one sentence, plain English. "A mobile app for solo chiropractors that reduces insurance-claim resubmission time."
+2. **Who it is for** - the specific person, not a category. "Solo chiropractors with 1-3 staff who handle their own billing."
+3. **The specific problem** - a verb-noun pair. "Resubmitting denied insurance claims takes 14 days and 8% of recovered revenue."
+4. **Your business model** - even if rough. "Subscription at $200/mo per clinic."
+
+Example input that produces good results:
+
+> *"I'm building a mobile app for solo chiropractors that reduces insurance-claim resubmission time from 14 days to one click. Subscription model at $200/mo."*
+
+Example input that produces useless results:
+
+> *"An app for small businesses to be more productive."*
+
+Every blank in the Mad Libs sentence is a blank in your VenturusAI input. Specific in = specific out.
+
+### How to read the report
+
+The report has 7-8 sections. You do not need to read all of them. Focus on three:
+
+**Porter's Five Forces - Competitive Rivalry section.** If it names a competitor you had not thought of, add that competitor to your Step 1 competition column in Ch 1.1. If it names one you already knew about but describes their advantage in a way you had not considered, rewrite your [differentiation] blank.
+
+**SWOT - Weaknesses.** This is the section that hurts. If the AI flags a weakness you already knew about (e.g., "founder has no engineering background"), that is expected. If it flags one you had not considered (e.g., "customer acquisition depends on insurance-industry partnerships that take 6-12 months to close"), pay attention. That is a structural blank in your hypothesis.
+
+**PESTEL - Legal/Regulatory.** Many founders skip this. If your product touches healthcare, finance, education, or anything involving personal data, read this section carefully. A regulatory blocker you discover now costs zero dollars. One you discover after building costs your runway.
+
+The Marketing Strategy and Financial Estimates sections are AI-generated first drafts. Skim them for ideas; do not treat the numbers as real.
+
+### Common mistakes
+
+- **Vague input.** "An app for food delivery" produces generic SWOT that is useless. Write the four-part paragraph above.
+- **Trusting it blindly.** The AI generates insights from general logic, not from your specific market. It cannot access your local competitors or proprietary market data.
+- **Stopping at one report.** If the first report is too generic, take the most interesting section, expand on it, and re-feed it as a new input. Iterate.
+
+### Pro tips
+
+- Use the export-to-Google-Docs feature. Keep the AI-generated framework and manually update it as you gather real interview data. By Module 2, you will have a side-by-side comparison of what the AI predicted vs. what real humans said.
+- Ask the tool explicitly about failure modes. Refine your input to include: "What could cause this to fail?" The Weaknesses and Threats sections will be sharper.
+- The free tier has a ~1,000 character limit. If your input exceeds it, cut adjectives before you cut specifics. "Very innovative" costs characters and adds zero signal.
+
+---
+
+## DimeADozen
+
+### What it does
+
+DimeADozen produces a multi-section validation report: Executive Summary, Market Sizing, Competitive Landscape, Customer Profiling, Risk Assessment (kill risks), Unit Economics, and Go-To-Market Strategy. The Starter report ($9) is 5-7 pages. The Entrepreneur report ($129) is 40+ pages with sourced data and full metrics.
+
+The tool was bootstrapped by a solo founder who sold it - it is designed for exactly the person reading this guide: someone who wants a brutal second opinion before committing time and money.
+
+### What to prepare before you open it
+
+Same 2-4 sentence paragraph as VenturusAI. Plus: name 1-2 competitors you are aware of. The tool uses competitor names to calibrate its market-sizing and competitive-landscape sections. If you name zero competitors, it assumes the market is empty - which makes the report less useful.
+
+### How to read the report
+
+The Starter report is 5-7 pages. You only need to read two sections on the first pass:
+
+**Kill Risks.** This is the section that justifies the $9. It flags existential threats: market saturation (too many entrenched players), low barriers to entry (competitors can clone you in a weekend), CAC-to-LTV problems (acquiring a customer costs more than they will ever pay you), and regulatory hurdles. If any kill risk is specific - names a competitor, a regulation, or a cost number - take it seriously. If it is generic ("the market is competitive"), treat it as a yellow flag, not a red one.
+
+**Retention-Curve / Unit Economics.** This section estimates whether the numbers work. If it says your target market is too small at your price point, revisit the [customer] blank in Ch 1.1 Step 1. If it says your CAC is too high relative to LTV, revisit your channel assumption.
+
+Skip the Executive Summary and Go-To-Market sections on first read. They are AI-generated strategy and rarely say anything you could not have guessed. Come back to them after you have real interview data.
+
+### Starter ($9) vs. Entrepreneur ($129)
+
+| | Starter | Entrepreneur |
+|---|---|---|
+| Length | 5-7 pages | 40+ pages |
+| Data sourcing | AI-generated estimates | Sourced data with citations |
+| Kill risks | High-level flags | Specific, with competitor names and cost numbers |
+| Unit economics | Rough ranges | Detailed modeling |
+| When to use | Pre-interview sanity check | Due diligence before committing capital |
+
+At the pre-interview stage, the $9 Starter is enough. You are looking for red flags, not investment-grade due diligence. If the Starter report flags a kill risk, you decide whether to investigate further or pivot. If it comes back clean, you proceed to interviews.
+
+### Common mistakes
+
+- **Paying $129 before you know what a $9 report looks like.** Run the Starter first. If it flags something specific that needs deeper investigation, upgrade.
+- **Treating it as a go/no-go decision.** The tool validates the *logic* of a business model, not the *demand*. A clean report means your idea is not obviously broken. It does not mean customers will pay. That requires Ch 1.2 (a + b)'s smoke test and Ch 2.1's interviews.
+- **Ignoring the competitors it names.** The tool often surfaces competitors you did not know existed. Use these as starting points for your own manual research.
+
+### Pro tips
+
+- Run the report, read the kill risks, adjust your hypothesis, and run it again. Two $9 reports on different versions of your hypothesis are cheaper than one week of building the wrong thing.
+- If the report flags a competitor you have never heard of, spend 20 minutes on their website before you dismiss them. Read their pricing page, their testimonials, and their most recent blog post. You will learn more from a live competitor's marketing than from a generic competitive-landscape summary.
+
+---
+
+## Preuve AI
+
+### What it does
+
+Preuve AI scans 50+ live data sources - Crunchbase, Google Trends, Reddit, G2, Capterra, Product Hunt, news aggregators, and industry publications - and produces an evidence-based viability score (0-100). Every claim in the report links to its underlying source. Unlike general-purpose LLMs that hallucinate market facts, Preuve shows you where the data came from.
+
+The key product is the **Founder Report** ($29 one-time): a 13-section analysis with competitor mapping (up to 15 competitors with pricing and weak spots), TAM/SAM/SOM estimates, customer persona identification, and AI Coach pivot suggestions.
+
+### What to prepare before you open it
+
+One sentence, as specific as possible. The narrower your niche segment, the more relevant the market signals Preuve finds.
+
+Bad: "Helping small businesses."
+
+Good: "Accounts-payable teams at 50-200 person companies."
+
+Better: "Solo-practice chiropractors who file their own insurance claims and spend Mondays on resubmissions."
+
+The tool matches your description against live data sources. A broad description matches everything and tells you nothing. A narrow description matches specific signals.
+
+### How to read the report
+
+**Start with the Viability Score (0-100).** A score above 70 means the tool found positive market signals. A score below 40 means it found more problems than opportunities. A score between 40-70 means the data is mixed - drill into the specific sections that pulled the score down.
+
+**Competitor Mapping.** Preuve identifies up to 15 competitors with pricing and "weak spots." The weak spots are the most actionable part of the report - they tell you where existing solutions fall short. If three competitors share the same weak spot, your [differentiation] blank should target it.
+
+**Source links.** Every claim is linked to its source. If a score looks off - too high or too low - drill into the cited source before dismissing it. Sometimes the AI misinterprets a data point (e.g., a Reddit post from 2018 gets weighted too heavily). You are the human in the loop.
+
+### The AI Coach
+
+After your first report, the AI Coach suggests pivots based on what the data actually shows. It compares your idea against competitor weaknesses and market demand signals and identifies blind spots. Common pivot suggestions:
+
+- Target a micro-niche where existing solutions are too broad
+- Change the business model (e.g., B2C → B2B)
+- Add a feature that competitors are missing
+
+Treat the pivot suggestions as hypotheses to test in Ch 2.1 interviews, not as instructions. The AI Coach can tell you what the data suggests; it cannot tell you whether a real customer agrees.
+
+### Pricing
+
+| Tier | Price | What you get |
+|---|---|---|
+| Free Scan | $0 | High-level viability verdict |
+| Founder Report | $29 one-time | Full 13-section analysis with competitor mapping and source links |
+| Radar | $9/mo | Ongoing market monitoring |
+| Investor-Ready | $499 | Manual review, custom pitch deck, 18-month financial model, 4-page investment memo |
+
+For pre-interview validation, the Free Scan + Founder Report is the sweet spot. Skip the Investor-Ready package until you have a signed paid pilot and a deck to raise on.
+
+### Common mistakes
+
+- **Vague input.** As with VenturusAI, "an app for fitness" produces a generic report. Use the specific-niche format above.
+- **Treating the viability score as binary.** A score of 55 does not mean "kill the idea." It means "the data is mixed - investigate the low-scoring sections before proceeding."
+- **Ignoring the pivot suggestions.** Run the report, read the pivots, adjust your description, and scan again. Watch how the score changes. The delta between scans tells you which blank in your hypothesis is weakest.
+
+### Pro tips
+
+- Run the free scan first. If the viability score is above 50 and the competitor mapping names companies you recognize, the $29 Founder Report is worth it. If the free scan comes back below 30 with vague competitors, save your $29 and revisit your hypothesis first.
+- Preuve scans Reddit and niche forums. If real people are discussing the problem you want to solve, Preuve will find those discussions and link to them. Read the threads. The verbatim language from real users is worth more than any AI-generated summary.
+
+---
+
+## Recommended workflow
+
+The three tools work best in sequence, not all at once. Here is the order that produces the most signal for the least time:
+
+### 1. VenturusAI (first - free)
+
+Run your hypothesis paragraph through VenturusAI. Read the Porter's Five Forces Competitive Rivalry section and the SWOT Weaknesses section. If it flags a competitor you missed or a structural weakness you had not considered, fix those blanks in your hypothesis before moving to the next tool.
+
+**Time:** 10 minutes (5 to write input, 5 to read key sections).
+
+### 2. Preuve AI free scan (second - free)
+
+Run your refined hypothesis through Preuve's free scan. Check if the viability score is above 50 and whether the competitor mapping names companies in your space. If the score is low, revisit your [customer] or [problem] blank. If the score is solid, you have a data-backed signal that the market exists.
+
+**Time:** 5 minutes.
+
+### 3. DimeADozen Starter (third - $9, optional)
+
+If VenturusAI and Preuve both gave green or yellow signals, spend $9 on a DimeADozen Starter report. Read only the Kill Risks and Retention-Curve sections. If the report flags specific kill risks, address them before booking interviews. If it comes back clean, you have three independent tools saying your hypothesis is structurally sound.
+
+**Time:** 10 minutes + $9.
+
+### After the tools: Ch 2.1 interviews
+
+No tool validates your hypothesis. Only ten strangers describing the problem in their own words can do that. The tools tell you whether the sentence is well-constructed. The interviews tell you whether the sentence describes something real.
+
+---
+
+## What none of these tools can do
+
+These tools sharpen your hypothesis. They do not validate it. Specifically:
+
+**They cannot prove a real customer will pay.** A clean DimeADozen report and a Preuve score of 80 do not equal a signed Stripe checkout. That signal comes from Ch 1.2 (a + b)'s smoke-test landing page and Ch 5.4's Design Partner Agreement with a real deposit.
+
+**They cannot tell you whether the problem is real.** AI tools summarize what people have already said online. They cannot surface a problem that nobody has articulated publicly. The Mom Test interviews in Ch 2.1 surface what specific named humans actually did last Friday - a signal no AI tool can produce.
+
+**They cannot substitute for the Pragmatic-lens gut-check.** VenturusAI can flag that you have no engineering background, but only you know whether you can ship the thing with Lovable on evenings and weekends. The Pragmatic lens in Ch 1.1 Step 4 is still yours to score.
+
+**They do not replace talking to humans.** If you spend three hours across these tools and zero hours on interviews, you have three AI reports and zero validation. The tools exist to sharpen the sentence you test in interviews. Skip the interviews and you have sharpened a sentence that might describe nothing.
+
+---
+
+## Further reading
+
+- [Ch 1.1: Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) - write the Mad Libs sentence these tools stress-test.
+- [Ch 2.1: The Mom Test - Ask About the Past, Not the Future](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) - validate the sharpened hypothesis with ten real interviews.
+- [Ch 1.2 (a + b): Smoke-Test the Hypothesis: The Demand Test](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) - the next step after these tools confirm your sentence is well-constructed.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum. Tool research: June 2026, based on official websites (venturusai.com, dimeadozen.ai, preuve.ai), user reviews on Product Hunt and Indie Hackers, and hands-on testing with free tiers.*
diff --git a/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/cover.png b/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/cover.png
new file mode 100644
index 000000000..9217715b0
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/index.md b/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/index.md
new file mode 100644
index 000000000..a698f7ae2
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/index.md
@@ -0,0 +1,261 @@
+---
+title: "4.4 · Vibe Coding Done Right: 5 Ceiling Signals"
+aliases: ["/blog/vibe-coding-ceiling-signals/"]
+description: "The 5 architectural ceiling signals that tell you the Lovable + Supabase + Stripe shed stopped holding. Two firing = graduate. Chapter 4.4 of the course."
+date: 2026-05-13
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: vibe-coding-ceiling-signals
+keywords:
+  - vibe coding architectural ceiling
+  - lovable supabase scale limits
+  - when to hire engineer founder
+  - ai code quality limits
+  - non technical founder rebuild signals
+tags:
+  - founders
+  - non-technical-founder
+  - course-companion
+  - vibe-coding
+  - scale
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "4.4 · Vibe Coding Done Right: 5 Ceiling Signals"
+  og_description: "The 5 architectural ceiling signals that tell you the Lovable + Supabase + Stripe shed stopped holding. Two firing = graduate. Chapter 4.4 of the course."
+cover_image_alt: "JetThoughts cover with three hand-drawn buildings - a small shed, a two-story house, and a tall skyscraper - and a sticky note reading Two ceiling signals = graduate."
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/"
+related_posts: false
+---
+
+> **Module 4 · Step 4 of 4** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a live MVP on the self-serve stack (from [Chapter 4.3a · Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) + [4.3b · Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/))
+>
+> **Output:** a yes/no decision on whether to graduate to Module 5 (First Paying Customer) or hire or stay self-serve
+
+> **TL;DR:** Five architectural signals that mean the self-serve stack is maxed out. Two firing for 4+ weeks = graduate to a fractional CTO or hire. Run this check monthly once your MVP is live.
+
+A working morning. Your [Lovable](https://lovable.dev) app is live (Lovable is an AI app builder that generates a working web app from a prompt - free trial, paid plans from $25/month, no coding required). 47 paying coaches on the platform.
+
+The dashboard takes 11 seconds to load for your largest account, a coach managing 80 clients. The Stripe webhook fired twice on three of yesterday's payments and you spent the morning refunding duplicates.
+
+Two of your users keep landing on each other's data because the [Supabase](https://supabase.com) row-level security drifted last week when a contractor patched the check-in form (Supabase is a database + auth service that Lovable connects to automatically - free tier covers early-stage usage, paid plans from $25/month).
+
+The ceiling is visible now, but it was visible two months earlier too. That's when this check should have caught it.
+
+**Vibe Coding** is shipping a real product with AI-generated code from tools like Lovable, Cursor, or Bolt - no engineer, no dev shop, no months of build. The term comes from indie founder Pieter Levels and describes the 2026 default for solo non-technical founders. This chapter is about the moment the shed stops holding.
+
+Once your build goes live, run this 5-signal check monthly. Each signal that fires earlier saves rebuilds later. This is a proactive monitoring habit, not a post-mortem - the goal is to catch the ceiling before you slam into it.
+
+> **This chapter is a monthly review reference, not an action-today chapter.** Your only action today: open your calendar and add a recurring monthly block titled "Vibe-coding 5-signal check." The first run is once the live MVP is up (Ch 4.3 (a + b)); until then, the chapter sits on the shelf. If you haven't shipped a live MVP yet, bookmark this and come back the moment you have real users clicking around. The morning scene above is what the ceiling looks like when it actually arrives.
+
+![A hand-drawn scoreboard showing the 5 architectural ceiling signals: data model, real-time, auth complexity, AI cost, compliance. Each row has the visible symptom and the recommended action.](signals-scoreboard.svg)
+
+## Who this 5-signal check is for
+
+The Lovable + Supabase + Stripe shed from [The Self-Serve MVP Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) holds 80% of pre-seed B2B SaaS workloads. The other 20% is what this post is about.
+
+Run this check monthly once your MVP is live and the ceiling shows up while it is still a tuning problem. Wait until something breaks - slow dashboard, duplicate webhooks, support tickets climbing - and you are paying late-fix prices on what was an early-fix problem.
+
+The 5 signals below are the early-warning system. Run them before you need them.
+
+## The 5 architectural ceiling signals
+
+Each signal has the same shape: a visible symptom you can see in your dashboard tonight, the thing that is actually happening underneath, the cost of leaving it alone for another month, the cost of addressing it now. Score each one green / yellow / red. Two reds means you graduate. Signals are ordered by when they typically become detectable - run Signal 1 from Week 2, Signal 5 at Week 8+.
+
+Skim this table to spot which signals might fire for you now; deep-read the ones below it.
+
+| # | Signal | Detectable | Routes to |
+|---|---|---|---|
+| 1 | AI inference cost or rate limits | Week 2-4 | Fractional CTO (unit economics) |
+| 2 | Data model passes 5 entities | Week 4-6 | Fractional CTO schema review |
+| 3 | Real-time becomes non-negotiable | Week 4-8 | Hire engineering team |
+| 4 | Auth complexity beyond email + OAuth | Week 6-10 | Fractional CTO scope → hire |
+| 5 | Compliance audit on the calendar | Week 8-12+ | Hire engineering team |
+
+### Signal 1: AI inference cost or rate limits eating your margin (detectable: Week 2-4)
+
+**What you see**: your OpenAI bill for last month was $1,400. You have 200 paying users at $29/month. Your gross margin per user just went negative on the Pro plan.
+
+Or: the OpenAI rate limit on your tier hits at 11am on weekdays and your "AI summary" feature returns errors for 90 minutes until usage drops.
+
+**What is happening underneath**: a Lovable app that calls an LLM on every screen load (or every form submit) racks up per-request cost no founder modeled. The naive integration sends the full context every call, no caching, no model routing, no queue back-pressure when rate limits hit. Anthropic and OpenAI both publish per-token pricing; founders rarely run the per-user math until the credit-card statement arrives.
+
+**Cost of leaving it alone**: a coach-facing AI features startup we spoke with in Q4 2025 was burning $2,200/month on OpenAI for 180 paying users at $19/month. They were $2,000 underwater before they paid for hosting, before the founder paid herself.
+
+Eight months of runway went to AI cost they never modeled early enough to change course.
+
+**Cost of addressing now**: a Fractional CTO models the unit economics in a spreadsheet (~$800 of work). The conversation that follows is about caching, model routing (cheap-model for the first pass, expensive-model only when needed), token budgets per plan tier, and queue back-pressure that fails gracefully when the rate limit hits.
+
+If the math says the unit economics are unfixable at the current price, the conversation is about pricing, not engineering. Better to have it at week four of noticing the problem than at month six.
+
+### Signal 2: Data model complexity passing 5 entities with deep relations (detectable: Week 4-6)
+
+**What you see**: you ask Lovable to add a "tags" feature to your client list. Lovable rewrites the client detail screen and now the check-in form, the export-to-CSV, and the weekly email digest are all subtly off. You fix the same join error three times in one week.
+
+New features take twice as long as they did in month two.
+
+**What is happening underneath**: Lovable's generated schema treats every prompt as a fresh design. When your data model crosses roughly 5 core entities (`coaches`, `clients`, `check_ins`, `programs`, `tags`, plus their joins), the implicit foreign-key reasoning the LLM holds in its head per-prompt no longer covers the full graph.
+
+It writes a query that ignores a join, or it adds a column to one screen but not the migration. The schema decays from edits.
+
+**Cost of leaving it alone**: a fitness-coaching SaaS we picked up in Q1 2026 had 11,000 lines of Lovable-generated code, no foreign keys, every model named in the singular, and three customer accounts with corrupted data because a webhook had retried a Stripe charge update four times.
+
+The founder shipped six features in month four and zero in months five and six because every change surfaced something else.
+
+**Cost of addressing now**: a 2-hour [Fractional CTO](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge) schema review (~$400 at $200/hour). They sketch the proper entity-relationship diagram, identify the joins your current schema is missing, and tell you whether the next 10 features fit on the current schema or need a redesign. If the verdict is "rebuild on a real ORM," route to [Reading the SOW](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#reading-the-sow).
+
+### Signal 3: Real-time features becoming non-negotiable (detectable: Week 4-8)
+
+**What you see**: two coaches open the same client record. One adds a note. The other adds a note. Whoever saves second wins - the first note is gone. Your Slack fills with "the app is acting weird again." A wellness platform we talked to in late 2025 was getting 4-5 of these support tickets per week. The founder had patched the same save-collision bug three times. Each patch changed the behavior without fixing the architecture underneath.
+
+**What is happening underneath**: the Lovable + Supabase REST loop is request-response: every screen reads on load and writes on submit. Real-time presence, collaborative editing, and live-updating feeds are not what auto-generated REST endpoints serve. Supabase does have a Realtime product, but wiring it into a Lovable-generated frontend that was never designed around subscriptions means rebuilding every screen the feature touches.
+
+**Cost of leaving it alone**: the save-collision bug becomes a churn driver inside three months. Customers who collaborate (coaches sharing clients, teams sharing accounts) lose work weekly. Each ticket costs you an hour of founder time and erodes the trust that brought the user in. By the time real-time becomes a deal-breaker for a $30K customer, the rebuild estimate is the same - you just spent six months patching first.
+
+**Cost of addressing now**: this signal routes directly to a hire-a-team decision, not a Fractional CTO bridge. Real-time done right needs an engineer who has shipped Action Cable on Rails or Channels on Django and knows the queue, broadcast, and reconnection edge cases. The [SOW reading guide](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#reading-the-sow) walks the contract. Estimated rebuild on Rails: 6 to 10 weeks for one senior + one mid engineer.
+
+### Signal 4: Auth complexity passing the email + OAuth ceiling (detectable: Week 6-10)
+
+**What you see**: an enterprise prospect asks: "do you support SAML SSO (Security Assertion Markup Language Single Sign-On - corporate login standards) with our Okta (the enterprise login vendor) tenant, with role-based access where managers see their direct reports' data but not the whole organization, and an audit log of every read?" You answer yes because the deal is $50K ARR (Annual Recurring Revenue - what one customer pays per year).
+
+You then realize Supabase RLS does not model that role hierarchy without writing your own policy DSL on top. The recurring shape: a founder says yes, spends 6 weeks building a workaround in Supabase, ships it, and the customer's security team finds a read-through gap in the policy by week 2.
+
+The contract has a data-handling clause. The workaround was not reviewed by anyone with security experience. That is a breach disclosure conversation, not a feature fix.
+
+**What is happening underneath**: Supabase's row-level security is excellent for "user X can only read rows where user_id = X." It strains under role matrices (manager-reads-team, admin-reads-org, super-admin-reads-everything), multi-tenant isolation across an organization, SAML federation, and audit trails. Each of those needs first-class engineering, not a configurable policy.
+
+**Cost of leaving it alone**: you write the SOC2 (a security-audit standard B2B buyers ask for) letter and the SAML promise into the contract and ship a workaround. Six months later, the workaround becomes the breach incident. The [vibe-coded auth shape](/blog/vibe-coding-disposable-by-design/) - 47 startups with public URL-based access controls, BOLA-class vulnerabilities (Broken Object Level Authorization - a URL where changing the ID in the address bar lets you read someone else's data), no audit log to diagnose what got read - is what deferred auth complexity produces.
+
+**Cost of addressing now**: a Fractional CTO scopes the role matrix on paper (1-2 weeks of part-time work, ~$8-15K), then hands the spec to a hired engineering team for the production build on Devise + Pundit (Rails) or django-allauth + django-guardian. Total auth-shaped rebuild: 4 to 8 weeks.
+
+### Signal 5: Compliance or security audit landing on the calendar (detectable: Week 8-12+)
+
+**What you see**: a customer's procurement team emails you the SOC2 (security-audit standard) questionnaire. Or HIPAA: they need a Business Associate Agreement (BAA - the contract US health-data law requires between you and any vendor that touches Protected Health Information / PHI) before they can send a single PHI record. Or PCI (Payment Card Industry rules): you wanted to handle card data directly instead of using Stripe Checkout and now you need to pass a quarterly scan.
+
+The self-serve stack cannot pass any of these, not because it is insecure in every way, but because it has no audit log, no documented data handling, no formally reviewed access control.
+
+**What is happening underneath**: compliance is mostly process plus a small amount of code. The process is documented data flow, access logs, encryption at rest and in transit, vulnerability disclosure, vendor reviews. The code is the implementation underneath.
+
+A Lovable + Supabase stack passes some checks (Supabase encrypts at rest, Stripe handles PCI-sensitive paths) and misses others (no audit log, no documented data lifecycle, no senior engineer to sign the security policy).
+
+The auditor needs a person to ask "show me how you decommission a leaver's access" and a non-technical founder cannot answer that question alone.
+
+**Cost of leaving it alone**: you either pass on the deal or sign it with a workaround, which becomes the breach narrative when the customer's auditor finds it 11 months in.
+
+**Cost of addressing now**: this is a hire-a-team decision from day one, not a bridge. A senior engineer architects the audit surface (audit logs, access controls, vendor inventory, data flow diagrams) before you take the deal.
+
+Vanta, [Drata](https://drata.com), and [Secureframe](https://secureframe.com) automate the SOC2 paperwork; the engineering work underneath them needs a real architect, not a Lovable rebuild. Budget: 8 to 16 weeks to first-time SOC2 readiness, plus ongoing process work.
+
+> **What to bring to Vanta / Drata / Secureframe onboarding from your existing artifacts.** Your [Ch 4.2 ownership audit](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/) third-party-API-keys section is your starting vendor inventory (Lovable, Supabase, Stripe, Resend, OpenAI, etc.). Your one-page brief Section 1 (problem, named persona, data flow) feeds the data-flow diagram. Without these two inputs ready, the first onboarding call burns on collecting basics the audit could have surfaced in 15 minutes.
+
+**What to say to the customer this week** (when they ask for SOC2 / HIPAA BAA / PCI before you can deliver it): respond within 48 hours with a 3-sentence email - do not ghost. Use this template:
+
+> *"Thank you for the SOC2 / [BAA / PCI] questionnaire. We are pre-SOC2 [or pre-BAA] today and are starting the readiness work in Q3. In the meantime, I can share our security one-pager (encryption at rest via Supabase, payments via Stripe Checkout, data deletion on request) and offer a 90-day pilot with the data-handling restrictions of your choice - including hosting in a sandboxed instance if that helps your security team approve. Would that bridge work while we complete the formal certification?"*
+
+This buys you 60-90 days to start the engineering work. About 30-40% of enterprise security teams will accept a documented bridge for a small pilot; the rest will say "come back when SOC2 is done" - which is the same answer you would get from ghosting them, plus you have preserved the relationship for the rebid 6 months later.
+
+Keep the security one-pager as a shared Google Doc with: data flow diagram, encryption-at-rest summary, vendor list (Supabase, Stripe, Lovable, Loom, etc.), and a one-line incident-response contact. 30 minutes to draft; reusable across every enterprise sales conversation.
+
+## Shed → House → Skyscraper
+
+![A hand-drawn progression of three buildings: a small shed labeled Lovable + Supabase + Stripe, a two-story house labeled Fractional CTO + 1-2 engineers on Rails / Django / Laravel, and a tall skyscraper labeled Hired team with SOC2 and HIPAA. Arrows between them mark the ceiling-signal moments.](shed-house-skyscraper.svg)
+
+[Rob Walling's shed analogy](https://podcast.creatorscience.com/rob-walling/) from [Should You Hire?](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/) is the right map.
+
+A shed holds one workflow with one persona moving down a single happy path. Add a second story (a second workflow, a second persona, a real data model) and you have a house that needs a structural engineer to plan the load.
+
+A skyscraper - compliance-bound, multi-tenant, real-time, AI-heavy - needs a hired engineering team and an architect from day one. You can't add ten more floors to a shed. When the load requires a skyscraper, you start a new building.
+
+## The decision: stay self-serve or graduate
+
+The 2-question test runs in 90 seconds. Print it. Tape it inside the laptop case.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#1a1a1a', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart TD
+    Start(["Open the 5-signal scoreboard"])
+    Q1{"Q1: Has any signal been
firing for 4+ weeks?"}
+    Q2{"Q2: Is your runway
> 6 months from today?"}
+    Stay["STAY SELF-SERVE
Keep shipping on the shed.
Re-score every 2 weeks."]
+    Bridge["GRADUATE: BRIDGE
Fractional CTO
(5 hours / week, ~$8-15K / mo)"]
+    Hire["GRADUATE: HIRE A TEAM
1-2 engineers on Rails /
Django / Laravel. SOW signed
before kickoff."]
+
+    Start --> Q1
+    Q1 -- "No" --> Stay
+    Q1 -- "Yes" --> Q2
+    Q2 -- "No" --> Bridge
+    Q2 -- "Yes" --> Hire
+
+    classDef q fill:#fffbe6,stroke:#bf8a00,stroke-width:2.5px,color:#1a1a1a
+    classDef stay fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a
+    classDef bridge fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a
+    classDef hire fill:#f5e9ff,stroke:#7c3aed,stroke-width:2.5px,color:#1a1a1a
+    classDef start fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a
+    class Start start
+    class Q1,Q2 q
+    class Stay stay
+    class Bridge bridge
+    class Hire hire
+```
+
+Q1 No: stay self-serve. The shed is holding. Re-score every two weeks. The cost of being wrong is two weeks of lost lead time, which is recoverable.
+
+Q1 Yes + Q2 Yes: graduate to the hire-a-team path. You have the runway to scope, hire, and onboard a 1-2 engineer team on Rails, Django, or Laravel. The [SOW reading guide](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#reading-the-sow) is your starting page.
+
+Q1 Yes + Q2 No: graduate to the [Fractional CTO bridge](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge). Five hours a week of senior eyes for the next two to three months while you raise or grow into the runway needed for a hire. The [Salvage vs Rebuild decision tree](/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/) tells you which signal-firing pieces salvage and which the Fractional CTO triages first.
+
+> Two ceiling signals firing for 4+ weeks means the shed is no longer holding. Either hire a team if you have runway, or bridge with a Fractional CTO until you do. Both beat watching the codebase get worse.
+
+## What to do tomorrow
+
+Three actions. The first is tonight.
+
+- **Open your Lovable + Supabase admin dashboard tonight.** Pull up: the 30-day request error rate, the 30-day Stripe webhook retry log, the active user count, and last month's OpenAI / Anthropic invoice if you use one. Five minutes of dashboard time is the input to the scoreboard.
+- **Score each of the 5 signals: green / yellow / red, AND log Date first observed + Date last observed per signal.** Use the scoreboard above. Green = no symptom yet. Yellow = symptom showing in the last 30 days but recoverable. Red = symptom firing 4+ weeks AND you've patched it more than once. Without dated observation windows you cannot tell the "fired once this week" from the "fired every week for two months" signal, and the 4-week graduation rule below collapses. Keep the scoreboard as a Notion table or a sheet with columns: Signal | Status | Date first observed | Date last observed | Notes. Score green when the symptoms are firing and you arrive at the [salvage-or-rebuild thread](/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/) at month nine - by then the rebuild estimate is months of work you could have caught in days.
+- **If 2 or more signals are red AND have been red for ≥4 consecutive weeks (per the flowchart Q1 above), start the [Fractional CTO bridge](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge) THIS WEEK.** The 4-week window is the load-bearing qualifier; two reds in one week is a tuning problem, not a graduation signal. Not next month, not after the next sprint - once the 4-week mark hits, the Fractional CTO conversation is one Calendly invite away and the first call is usually free. The bridge holds until you have the runway clarity for a full hire.
+
+## Artifacts you carry out of Module 4
+
+After finishing Ch 4.1-4.4, Sam has five artifacts. Each one feeds a specific downstream destination - this table is the map:
+
+| Artifact | Where it goes next |
+|---|---|
+| **Build-path decision** (validate / self-serve / fractional CTO / hire - chosen and dated, from Ch 4.1) | Module 5 outbound posture. The build path determines whether you sell a live MVP (self-serve, hire) or a Carrd + Stripe pre-sale (validate path), which decides the Ch 5.2-5.5 scripts you use. |
+| **Ownership audit results** (12-item checklist - GitHub, AWS root, billing, IAM, DB credentials, secrets store, backups, domain, DNS, third-party keys, monitoring, status page - all on your company email, from Ch 4.2) | Module 5 contract foundations. The Ch 5.4 Design Partner Agreement assumes you own the production environment. If ownership is split, fix that before sending any DPA. |
+| **Shipped MVP** (live URL + first 4-6 user accounts if self-serve, OR live URL + contractor weekly demo cadence if hired, from Ch 4.3 (a + b)) | Ch 5.1 must-have test denominator. The 40% test needs 10-30 users who actually touched the MVP; the first 4-6 are the starting cohort. |
+| **Monthly ceiling-signal scorecard** (the 5 signals from Ch 4.4, first run once the live MVP is up) | Recurring monthly check from live launch onward. The scorecard is the early-warning system that decides whether you stay self-serve or graduate while you sell. |
+| **Output for Module 5: 4-6 active users as the starting cohort + a path to 10+ via Ch 2.3 (a + b) outreach** (from Ch 4.3 (a + b) onboarding) | Ch 5.1 Sean Ellis 40% test input. 4-6 is the directional starting cohort - Ch 5.1's "Under-10 respondents" sidebar reads that as MAYBE, not a verdict. Re-engage your Ch 2.3 (a + b) interview leads as Ch 5.1 invites to get above 10 for a confident reading. Their Q2-Q3 verbatims become the persona language for Ch 5.2-5.5 outbound. |
+
+Two ceiling signals firing for 4+ weeks means the shed is no longer holding. Both beat watching the codebase get worse.
+
+## Further reading
+
+- Rob Walling, [Vibe Coding interview on Creator Science](https://podcast.creatorscience.com/rob-walling/) - the shed-vs-skyscraper analogy that frames every architectural ceiling decision. 35-minute listen.
+- DHH, [The One-Person Framework](https://world.hey.com/dhh/the-one-person-framework-711e6318) - the Rails case for keeping the production rebuild small enough that one engineer can operate end-to-end.
+- Veracode, [GenAI Code Security Report 2025](https://www.veracode.com/blog/genai-code-security-report/) - 45% of LLM-generated code shipped at least one exploitable security flaw. The data behind why the compliance signal fires.
+- Supabase, [Realtime documentation](https://supabase.com/docs/guides/realtime) and [Row-Level Security guide](https://supabase.com/docs/guides/database/postgres/row-level-security) - the official boundary between what Supabase serves well and where the data-model and real-time signals begin.
+- OpenAI, [Rate limits documentation](https://platform.openai.com/docs/guides/rate-limits) - the per-tier request and token caps that drive the AI-inference signal once your traffic crosses a threshold.
+- Vanta, [SOC2 readiness for early-stage SaaS](https://www.vanta.com/resources/soc-2-compliance-checklist) - the audit-surface checklist most founders see for the first time when their first enterprise customer asks for a SOC2 letter.
+- Y Combinator, [Startup School Library + 2026 Founder Resources](https://www.ycombinator.com/library/) - the YC stance on validating without code and the changing role of the technical co-founder. Read before any framework decision.
+
+> **Done when:** You have scored all 5 signals (green/yellow/red) with dated observation windows and set a recurring monthly calendar block titled "Vibe-coding 5-signal check."
+>
+> **Next click:** [5.1 · Your First Customer Is Not a Marketing Problem](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/)
+>
+> **If blocked:** If 2+ signals are red but you are not sure whether to hire, book one free Fractional CTO call. The first call is usually free and the diagnosis alone is worth the hour.
+
+> **Module 4 closes here.** Before opening Module 5, you should have: (1) a build-path decision from the Ch 4.1 tree (self-serve / fractional CTO / hire), (2) a Day-1 ownership audit passed (Ch 4.2 - GitHub + AWS + domain all in your name), (3) a live MVP at a real URL with 5 ICP users tested + 5 green lights lit (Ch 4.3b), and (4) a monthly 5-signal ceiling check on the calendar (this chapter). All four in your `Founder OS` folder. Missing one? Go back - Module 5 invites your Module 2 interviewees + smoke-test email list to your URL; if there's no URL, there's no Module 5.
+
+> **Case Study: Tomas & Mia**
+>
+> **Tomas**: At ~50 firms, 2 ceiling signals fire: reconciliation matching has race conditions, n8n QuickBooks connector breaks on API changes. Graduates from self-serve → fractional CTO → hired team. CTO already in place, transition is smooth.
+>
+> **Mia**: At ~200 parents, 2 ceiling signals fire: search takes 4 seconds, booking confirmation emails show wrong timezone. Graduates to fractional CTO at 5 hrs/week to fix the search query and timezone logic.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/shed-house-skyscraper.svg b/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/shed-house-skyscraper.svg
new file mode 100644
index 000000000..727fd8945
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/shed-house-skyscraper.svg
@@ -0,0 +1,74 @@
+
+
+  
+    
+      
+      
+    
+    
+      
+    
+  
+  
+
+  
+  Shed - House - Skyscraper
+  Different buildings, different talent, different cost ceilings. Pick the one your real load needs.
+
+  
+  
+
+  
+  
+    
+    
+    
+  
+  The shed
+  Lovable + Supabase + Stripe
+  1 founder - ~$87 / mo - 4 weeks
+
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  The house
+  Fractional CTO + 1-2 engineers
+  Rails / Django / Laravel - ~$10-25K / mo
+
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+  The skyscraper
+  Hired engineering team
+  SOC2 / HIPAA - audit-ready - ~$50K+ / mo
+
+  
+  
+  2 ceiling signals fire
+
+  
+  audit + scale
+
+  
+  Most pre-seed B2B SaaS lives in the shed. The 20% that outgrows it is what this post is about.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/signals-scoreboard.svg b/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/signals-scoreboard.svg
new file mode 100644
index 000000000..df4d3e13d
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/signals-scoreboard.svg
@@ -0,0 +1,80 @@
+
+
+  
+    
+      
+      
+    
+  
+  
+
+  
+  The 5 Architectural Ceiling Signals
+  Score each signal: green / yellow / red. Two reds = graduate from self-serve.
+
+  
+  
+  Signal
+  What you see
+  What to do
+
+  
+  
+  1. AI inference
+  rate limits, cost
+  per request >$0.05
+  OpenAI bill hit $1,400 last
+  month. Margin per user is
+  now negative on the Pro plan.
+  Fractional CTO models the
+  unit economics. Caching, model
+  routing, queue back-pressure.
+
+  
+  
+  2. Data model
+  >5 entities, deep
+  relations, joins
+  Lovable rewrites a screen and
+  three other screens break.
+  Same fix three times a week.
+  Fractional CTO for a schema
+  review (2 hours, $400). Then
+  route to the hire-a-team path.
+
+  
+  
+  3. Real-time
+  live presence,
+  collab, websockets
+  Two users edit the same row.
+  One overwrites the other.
+  Refresh = different state.
+  Hire a team. Real-time needs
+  an engineer who has shipped
+  Action Cable / Channels.
+
+  
+  
+  4. Auth complexity
+  RBAC matrix,
+  multi-tenant, SAML
+  Enterprise prospect asks
+  for SSO and a role matrix.
+  Supabase RLS no longer fits.
+  Fractional CTO scopes the
+  RBAC model. Then hire a team
+  to ship it on Rails / Devise.
+
+  
+  
+  5. Compliance
+  SOC2, HIPAA, PCI
+  audit on calendar
+  Customer's procurement asks
+  for a SOC2 letter or HIPAA BAA.
+  Vibe-coded stack cannot pass.
+  Hire a team day one. Senior
+  engineer architects the audit
+  surface before you take the deal.
+
diff --git a/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/cover.png b/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/cover.png
new file mode 100644
index 000000000..3b9ce53f0
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/index.md b/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/index.md
new file mode 100644
index 000000000..6174a2f62
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/index.md
@@ -0,0 +1,245 @@
+---
+title: "Vibe PRD Template - One-Page Product Brief"
+aliases: ["/blog/vibe-prd-template/"]
+description: "One-page Product Brief template. Hand to Lovable, Cursor, or a hired junior. Free."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: vibe-prd-template
+keywords:
+  - vibe prd template
+  - one page product brief template
+  - founder product spec template
+  - lovable cursor brief template
+  - non technical founder prd template
+tags:
+  - founders
+  - non-technical-founder
+  - template
+  - course-companion
+  - product
+categories: ["Templates"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/vibe-prd-template/"
+related_posts: false
+---
+
+📋 Template companion to the [Chapter 3.1 post](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/). Print after running the synthesis from [Chapter 2.1](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/#synthesis-write-down-what-you-heard-decide-whats-next). Fill in 45 minutes. Hand to your AI agent or contractor tomorrow.
+
+# Vibe PRD Template - One Page, Five Sections
+
+*The brief that turns a validated problem into something Lovable, Cursor, or a hired junior can ship from on Tuesday morning.*
+
+> **The one-page brief, 5 sections:**
+> 1. The problem (copied from your validated problem statement)
+> 2. The user and their context
+> 3. What you're building (one paragraph, plain English)
+> 4. Success metric (one number)
+> 5. What you're not building (the no-go list)
+
+## Why this exists
+
+A solo founder I spoke with last quarter had a validated problem statement and a Lovable subscription. She typed her problem statement into the Lovable prompt and asked it to "build the simplest version of this." Twelve hours later she had a working web app with a settings page, a billing dashboard, three integrations, and 17 toggles she didn't ask for. She spent the next three weeks deciding which parts to delete. When she opened a second project with a one-page one-page brief - the same problem, but now with a no-go list - Lovable shipped the smallest end-to-end thing in 90 minutes. The page she filled in between the two attempts was the difference. The agent fills blanks with reasonable defaults; the brief is your only way to forbid the defaults.
+
+## How to use this
+
+Block 90 minutes on a single morning. Print the template (or copy the markdown block below into a Notion doc). Bring your filled-in [validated problem statement](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/). Open Lovable, Cursor, or your contractor's kickoff doc in a second tab. You will not type into the second tab yet. The page first.
+
+Section 1 copies directly from your validated problem statement, word for word. Sections 2 through 5 you write from scratch. Hard cap at 45 minutes per section, 90 minutes total. If you spill, the persona is too broad or you are designing too much.
+
+After the page is filled, read it aloud to one peer over a 20-minute call. Ask them: "If you built this in a week using Lovable, what would you build that isn't on my no-go list?" Their first answer is your missing no-go item.
+
+Total time budget: 90 minutes to write, 1 hour to read aloud + revise, 0 minutes to convert for the audience. The same page goes to Lovable, Cursor, or the hired junior. The brief is the brief.
+
+## The template - copy and paste
+
+Use the markdown block below directly in Notion, Lovable's prompt window, or a Word doc. The [SVG of the page](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) is embedded in the Chapter 3.1 post for printing.
+
+```
+======================= VIBE PRD =======================
+
+Product name (working): _________________________________
+
+Founder: _________________  Date: _______________________
+
+Source: validated problem statement signed ____/____/____
+        by ____________________ (advisor 1) and
+           ____________________ (advisor 2)
+
+---------------------------------------------------------
+1. THE PROBLEM (copy from validated problem statement)
+---------------------------------------------------------
+
+Persona + industry + dated 10-call sample:
+_________________________________________________________
+
+Quantified cost (time per week + money per month):
+_________________________________________________________
+
+Verbatim quote from a strong-signal interview:
+"_______________________________________________________"
+
+Why now (trigger / market shift, one sentence):
+_________________________________________________________
+
+Inherited from validated problem statement - DO NOT
+paraphrase. If you find yourself softening the wording,
+stop and reread the original page.
+
+---------------------------------------------------------
+2. THE USER AND THEIR CONTEXT
+---------------------------------------------------------
+
+Who they are while using your product (job + situation):
+_________________________________________________________
+
+The 60 seconds before they reach for your product:
+_________________________________________________________
+
+The 60 seconds after they close it:
+_________________________________________________________
+
+Device + environment (laptop / phone / desk / commute):
+_________________________________________________________
+
+Emotional state at the moment of use:
+_________________________________________________________
+
+The agent or junior needs the context, not the TAM.
+"Tired, two tabs open, wants to be done" beats
+"SMB SaaS company, 11-50 employees, Series A."
+
+---------------------------------------------------------
+3. WHAT YOU'RE BUILDING (one paragraph, plain English)
+---------------------------------------------------------
+
+The smallest end-to-end thing the user can do:
+_________________________________________________________
+_________________________________________________________
+
+Inputs the user provides:
+_________________________________________________________
+
+Output the user gets back:
+_________________________________________________________
+
+Authentication method (magic link / OAuth / none):
+_________________________________________________________
+
+What v1 explicitly supports (scope of "done"):
+_________________________________________________________
+
+Write this as one paragraph, verb-led. If it reads like
+a feature list (Stripe integration + dashboard + settings)
+the agent will build a settings page nobody asked for.
+Rewrite until it reads like a sentence about what the
+user does.
+
+---------------------------------------------------------
+4. SUCCESS METRIC (one number)
+---------------------------------------------------------
+
+Number + unit + timeframe:
+_________________________________________________________
+
+How it's measured (analytics event, not gut feel):
+_________________________________________________________
+
+Pass threshold (build is validated above this):
+_________________________________________________________
+
+Fail threshold (kill or rewrite below this):
+_________________________________________________________
+
+One metric, not three. Three metrics let you cherry-pick.
+One metric forces a build/no-build call in 30 days.
+
+---------------------------------------------------------
+5. WHAT YOU'RE NOT BUILDING (the no-go list)
+---------------------------------------------------------
+
+5 to 8 lines naming what a competent agent or junior
+might add unprompted that you explicitly do not want in v1.
+
+[ ] _____________________________________________________
+[ ] _____________________________________________________
+[ ] _____________________________________________________
+[ ] _____________________________________________________
+[ ] _____________________________________________________
+[ ] _____________________________________________________
+[ ] _____________________________________________________
+[ ] _____________________________________________________
+
+If this section is shorter than 5 lines, you have not
+finished. The agent fills blanks. The longer your list,
+the cheaper your build.
+
+---------------------------------------------------------
+HAND-OFF
+---------------------------------------------------------
+
+Audience for this brief:
+ [ ] Lovable / Bolt / v0 (paste as prompt)
+ [ ] Cursor / Claude Code (paste as context file)
+ [ ] Hired junior contractor (page + 30-min kickoff call)
+ [ ] Hired senior engineer  → switch to traditional PRD
+ [ ] Product committee      → switch to traditional PRD
+
+Date handed off: ___________________________________
+Build start target: ________________________________
+Metric check-in: 30 days from build start: __________
+
+========================================================
+```
+
+### Audience decision: who is this brief going to?
+
+The same one page works for the first three audiences below. Senior engineers and product committees expect a longer document - the one-page brief is too thin for either.
+
+| Audience | Spec depth | Style | Length |
+|---|---|---|---|
+| Lovable / Bolt / v0 | one-page brief as-is | Paste as prompt; agent fills defaults | 1 page |
+| Cursor / Claude Code | one-page brief + a `context.md` with stack | Paste as context file at repo root | 1 page + stack note |
+| Hired junior contractor | one-page brief + 30-min kickoff call | Page + verbal walkthrough | 1 page + recording |
+| Hired senior engineer | Traditional PRD | User stories, acceptance criteria, edge cases | 5-10 pages |
+| Product committee | Traditional PRD | Goals, KPIs, risks, dependencies, milestones | 10+ pages |
+
+## What good looks like vs what bad looks like
+
+**Section 1 - The problem**
+
+> Bad: *"Founders need a better way to handle their finances."*
+
+> Good: *"Pre-seed B2B SaaS founders running their own Stripe-to-QuickBooks reconciliation lose 6 hours per week and £800 per month in CFO contractor time. 8 of 10 interviewees confirmed (May 2026 sample). Quote: 'Tuesday at 9pm I spent 40 minutes copying Stripe payouts into QuickBooks. I called my CFO. She did it in 90 seconds.' Why now: AI inference cost for the classification step fell to $0.001 per call - the unit economics flip at $9/month per seat."*
+
+The good version is inherited from the validated problem statement. It names the persona by stage, industry, and specific workflow. It puts the cost in time and money. It includes a verbatim quote with a specific moment. It names the why-now with a specific number. A peer can argue with it. The bad version is too broad to argue with, which is why the agent or the junior fills it in for you.
+
+**Section 3 - What you're building**
+
+> Bad: *"A modern reconciliation platform with AI-powered automation, Stripe integration, QuickBooks integration, custom reporting, user roles, and a mobile app."*
+
+> Good: *"A web app where the founder pastes a Stripe payout CSV and the app returns a QuickBooks-compatible journal entry CSV they can import in one click. The first version supports USD only, one Stripe account per user, and no multi-currency. The user authenticates with email plus magic link. We never store the CSV after the conversion completes."*
+
+The good version is one paragraph, verb-led. It names the input (paste CSV), the output (journal entry CSV), the scope of v1 (USD only, one account), the auth choice (magic link), and one storage rule. The bad version is a feature list. Feature lists produce settings pages.
+
+**Section 5 - What you're NOT building**
+
+> Bad: *(blank)*
+
+> Good: *"Not in v1: multi-currency support. Multi-Stripe-account support. Automatic recurring sync. A settings page. A billing dashboard. User roles and permissions. A marketing site beyond the signup page. Mobile responsive design beyond 'works on a 1024px screen.' We will revisit each of these after the Section 4 metric is hit."*
+
+The good no-go list names eight things a competent agent or junior might add. Each is concrete. The bad version is blank, which is how an EdTech founder I spoke with ended up with 17 settings toggles in version one. Twelve had no backend. Two crashed the app. The team had read her brief as a wish list and added everything she didn't forbid.
+
+## What to do after
+
+- **Read the brief aloud to one peer in a 20-minute call.** Ask them: "If you had to build this in a week using Lovable, what would you build that isn't in my no-go list?" Their first answer is your missing no-go item. Add it. The peer is doing the work of an external red-team.
+- **Paste the brief into Lovable, Cursor, or your contractor's first kickoff doc - unchanged.** Do not edit it for the audience. The same one page goes to all three. If the agent or the contractor asks a question whose answer is in the brief, your brief failed; rewrite the section that confused them before you take a second pass at the build.
+- **Set a 30-day calendar reminder for the Section 4 metric.** The reminder fires whether or not you remember it. On day 30, open your analytics tool and read the conversion-completed count. Above the pass threshold = the brief was right and you build the next layer. Below = the brief was wrong somewhere, and you reread the page before adding anything.
+
+Skip the no-go list and you ship a working demo of a product nobody asked for. Six weeks later you're posting a [salvage or rebuild question](/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/) about an MVP you can't extend. The page is cheap. The build round you save by writing it is the expensive thing you avoid.
+
+If you want the doctrine in long form, the [Chapter 3.1 post](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) walks through the five sections with the worked example, the decision between one-page brief and traditional PRD, and the case for paying $1,000 vs writing the page yourself for free.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/cover.png b/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/cover.png
new file mode 100644
index 000000000..8e143d6ae
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/five-sections.svg b/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/five-sections.svg
new file mode 100644
index 000000000..0a1f04cbc
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/five-sections.svg
@@ -0,0 +1,61 @@
+
+
+  The five sections of the weekly dev report on one page
+  Five labelled boxes stacked vertically representing the one-page weekly report. Box 1 (green) Shipped: staging URL plus test login. Box 2 (yellow) In review: PR number plus reviewer name. Box 3 (red) Blocked: named person plus deadline. Box 4 (blue) Cut: what got descoped and why. Box 5 (purple) Concern: one sentence on next week's risk.
+
+  
+
+  
+  
+  One page. Five sections. Plain text.
+
+  
+  
+    
+    1. Shipped
+    staging URL + test login + one sentence per feature
+    "staging.acme.app/co/v2 - login: founder@test.com / demo1234"
+    PROOF
+  
+
+  
+  
+    
+    2. In review
+    PR number + author + named reviewer + what is holding it up
+    "PR #847 - Marcos opened Tue, Priya reviewing, two changes requested"
+    PIPELINE
+  
+
+  
+  
+    
+    3. Blocked, on whom
+    name the person + the answer they need + the deadline
+    "Stripe live keys - waiting on you - need them by Wed end-of-day"
+    YOUR INPUT
+  
+
+  
+  
+    
+    4. Cut to ship that
+    what we descoped, postponed, or simplified + the reason
+    "Admin override - users do not need it for v1; Postgres console for now"
+    TRADE-OFFS
+  
+
+  
+  
+    
+    5. One concern next week
+    one sentence; the actual thing keeping the team awake
+    "Migration locks orders table ~30s; want a 6am UK window"
+    PREDICT
+  
+
+  
+  
+    No screenshots. No burndown chart. No executive summary. The five sections are the report.
+  
+
diff --git a/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/index.md b/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/index.md
new file mode 100644
index 000000000..4555b3d63
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/index.md
@@ -0,0 +1,151 @@
+---
+title: "6.5 · The Plain-English Weekly Dev Report"
+aliases: ["/blog/weekly-dev-report-template-founders/"]
+description: "A one-page weekly dev report you demand from your team every Monday. Five sections, copy-paste, with pass/fail examples for each. No jargon."
+date: 2026-05-18
+course_chapter: true
+author: "JetThoughts Team"
+slug: weekly-dev-report-template-founders
+keywords:
+  - weekly dev report template
+  - non-technical founder weekly report
+  - dev team weekly status email
+  - founder Monday review template
+  - what to ask for weekly from dev team
+tags:
+  - founders
+  - non-technical-founder
+  - course-companion
+  - oversight
+  - template
+categories: ["Founders"]
+related_posts: false
+course_nav: false
+cover_image: cover.png
+metatags:
+  og_title: "6.5 · The Plain-English Weekly Dev Report"
+  og_description: "A one-page weekly dev report you demand from your team every Monday. Five sections, copy-paste, with pass/fail examples for each. No jargon."
+cover_image_alt: "JetThoughts blog cover for The Plain-English Weekly Dev Report showing two side-by-side email screenshots - a wall of jargon on the left and a one-page five-section report on the right"
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/"
+---
+
+> **Chapter 5.5 · Step 4 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/)
+>
+> **Input:** a team in place + Friday demos running
+>
+> **Output:** a one-page weekly report template you demand from your team every Monday
+
+**Supplementary content.** This chapter assumes you have a hired team. If you're still on the [self-serve path](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/), bookmark this and return when you graduate to a hired team.
+
+Open your inbox on a Monday morning. Two reports landed over the weekend from two different teams.
+
+The first is 1,840 words long. It opens with "We made significant progress on the v2 architecture refactor and dependency hardening this sprint, prioritising long-term maintainability." There are seven Jira screenshots, a burndown chart, and a paragraph titled "Tech debt remediation." Nowhere in the report can you find a URL you can click. You read it twice. You still cannot say what shipped.
+
+The second is one page. The first line is a staging URL. The second line says "co flow is live; here is a $1 test charge that hit your Stripe dashboard at 14:02 UTC." The third line names two things the team cut to ship that. The fourth line names one person blocking one decision and the answer she needs from you by Wednesday. The fifth line says "next week we are worried about the migration; it locks the orders table and we want a 6am window."
+
+Both teams worked the same five days, and the second report gave you everything you needed to run your Monday while the first burned half an hour of it.
+
+## Why weekly reports usually fail
+
+The weekly report habit gets inherited from whichever PM the agency assigned in week one. The PM was trained to write status reports for an enterprise customer who wanted comfort: lots of words, a velocity chart, a RAG indicator that has been amber for six months. The format survived because nobody on the agency side had to read it. You did.
+
+The vibe-coding wave made the prose worse, not better. The same PM now pastes the standup transcripts into a long-context model and asks for "an executive summary suitable for the founder." What you get back is a wall of soft language - "exploring," "optimising," "iterating on" - assembled out of whatever the team said in standup, with no signal about whether anything reached a place you can click. [Atlassian's writeup of weekly status reporting](https://www.atlassian.com/work-management/project-management/status-reports) makes the point flat: a status report that does not link to working software is theatre, regardless of how cleanly it is formatted.
+
+The fix is not a new tool. The fix is a one-page format with five non-negotiable sections, each producing a fact you can verify in under a minute. The five sections below are it.
+
+![Side-by-side comparison: jargon-wall report vs. five-section one-page report. Left panel is a 1,840-word document with corporate-speak phrases like 'leveraging best practices' redacted. Right panel is a clean one-page report with five labelled rows: Shipped, In review, Blocked, Cut, Concern. Both report on the same five working days.](report-comparison.svg)
+
+## The five-section template (copy this into your Monday email)
+
+Send this to your tech lead Sunday night or first-thing Monday. Frame it as the format you need - not a request for "more detail."
+
+> Starting next Monday, please send your weekly report in this format. One page, five sections, in this order. Send by 9am UK time on Monday so I can read it before our 11am call.
+>
+> **1. What shipped this week.** One line per shipped feature. Each line must include the staging or production URL I can click, the test login if it is gated, and one sentence on what the user can now do. Example: `staging.acme.app/co/v2 - login: founder@test.com / demo1234 - users can now apply a discount code at checkout.` If nothing shipped, write "Nothing shipped this week" and skip to section 2. Do not pad.
+>
+> **2. What is in review but not shipped.** One line per open pull request. Include the PR number, the author, the named reviewer, the date the review was requested, and what is holding it up. Example: `PR #847 - Marcos opened Tue, Priya reviewing, two changes requested Wed evening - waiting on author.` If nobody reviewed it, name that.
+>
+> **3. What is blocked, and on whom.** One line per blocked item. Name the person, the answer they need, and the deadline they need it by. If I am the blocker, list me first. Example: `Stripe live keys - waiting on you - need them by Wed end-of-day or the launch slips to next week.`
+>
+> **4. What we cut to ship that.** One line per item we descoped, postponed, or simplified. Include the reason. Example: `Cut the admin override screen - users do not need it for v1; will handle plan changes via Postgres console for the first month.` If nothing was cut, write "Nothing was cut" and we will talk about that on the call.
+>
+> **5. One concern for next week.** One sentence. Not a status update; the actual thing keeping you awake. Example: `Next week we deploy the migration that locks the orders table - we want a 6am window so no live customer hits a 30-second timeout.`
+>
+> Hard rules: one page, no Jira screenshots, no burndown charts, no executive summary paragraph at the top. The five sections are the report. Plain text in the email body, not a PDF attachment.
+
+Do not soften the wording when you send it. "Would be nice to have" gets you the old format with two new bullets. "This is the format I need each week" gets you the format.
+
+### The weekly oversight loop
+
+The weekly oversight loop in one glance:
+
+1. **Mon 9am** - Report lands in your inbox. Read in 90 sec, click one staging URL, note one blocker on you.
+2. **Mon 11am** - Call with the team. Discuss the cuts, unblock yourself fast.
+3. **Tue-Thu** - Team ships. You stay out.
+4. **Fri 4pm** - 15-min demo. Click what shipped (see the [Friday Demo Template](/course/tech-for-non-technical-founders-2026/friday-demo-template/)).
+5. **Weekend** - Team writes next week's report.
+6. **Mon 9am (next week)** - Loop closes; the next report lands.
+
+The cadence is closed-loop on purpose. Monday's report tells you what happened last week and what to unblock this week. Friday's demo (covered in [the Friday Demo Template](/course/tech-for-non-technical-founders-2026/friday-demo-template/)) shows you the working software. Without Monday's report you walk into the demo blind. Without the demo, Monday's report is a prose exercise. The two pieces fit together.
+
+![The five sections of the weekly report visualised as five labelled boxes stacked top-to-bottom on a single page. Box 1 (green): Shipped - staging URL + test login. Box 2 (yellow): In review - PR number + reviewer name. Box 3 (red): Blocked - named person + deadline. Box 4 (blue): Cut - what got descoped + why. Box 5 (purple): Concern - one sentence on next week's risk. Each box is sized to fit one or two lines of text, total fits on one A4 page.](five-sections.svg)
+
+## What good looks like vs. what bad looks like
+
+Two reports on the same week of work. Same team. Same backlog. Different formats.
+
+### Bad report (1,840 words, no clickable URL)
+
+> *Subject: Weekly Status Report - Sprint 12*
+>
+> Team made significant progress this sprint on architectural improvements and tech debt reduction. We continued to iterate on the v2 checkout flow, exploring options for the discount-code feature and aligning on best practices for the underlying data model. Velocity remained steady at 34 points (vs. 32 last sprint). The team participated in three architecture workshops to ensure long-term maintainability. RAG status: Amber. We are tracking three risks around third-party dependencies and will provide a deeper writeup in next week's report. PR throughput remained healthy.
+>
+> *(eight more paragraphs in the same register; three Jira screenshots; one burndown chart; no URL anywhere in the email; one mention of "the team" with no names)*
+
+You finish reading at 9:18am. You cannot tell what shipped, who reviewed what, or what you need to decide before Wednesday. The report orients nobody.
+
+### Good report (one page, five sections)
+
+> *Subject: Weekly report - week of 5 Oct*
+>
+> **1. Shipped:**
+> - `staging.acme.app/co/v2` - discount-code field is live; test code `LAUNCH10` gives 10% off; webhook to Stripe fires correctly. Login: `founder@test.com / demo1234`.
+> - `staging.acme.app/account/email` - email change flow now sends confirmation and reverts on link expiry.
+>
+> **2. In review:**
+> - PR #847 (admin search) - Marcos, Priya reviewing since Tue; two changes requested Wed evening; waiting on author.
+> - PR #851 (rate limiting on signup) - Marcos, no reviewer yet because Priya is on PTO Thu-Fri; will assign Mon.
+>
+> **3. Blocked:**
+> - Stripe live keys - waiting on you - need them by Wed end-of-day or the launch slips a week.
+> - Decision on whether the discount-code field accepts free-text or dropdown only - waiting on you - need it by Tue afternoon.
+>
+> **4. Cut:**
+> - Admin override for plan changes - users do not need it for v1; we will handle plan edits in the Postgres console for the first month.
+> - Date-range picker on the dashboard - v1 spec only needs last-30-days; saved roughly two days.
+>
+> **5. Concern for next week:**
+> - We deploy the orders-table migration on Wed; it locks the table for ~30 seconds. We want a 6am UK window so no live customer hits a timeout.
+
+Same five days of work. You finish reading at 9:02am. You know what shipped, what is in review, what you owe the team by Wednesday, what was traded off, and what to flag on Wednesday's call. You can spend the rest of Monday on the work that needs you - not on parsing a status doc.
+
+The bad report leans on soft verbs, passive voice, and unnamed actors because it has no clickable URL to anchor anything specific. If yours would not survive being read out loud at a board meeting, the team is sending you the wrong format.
+
+## What to do tomorrow
+
+**1. Forward this post to your tech lead with one line in the body.** "Starting next Monday I need the weekly report in this format. Five sections, one page, plain text in the email." Do not edit the template. Do not add a sixth section. The five sections are the report.
+
+**2. Block 9:00 to 9:15 on Monday morning to read it.** If the report does not arrive by 9am, send one line: "Where is the weekly report?" Hold the slot. The first two Mondays will feel awkward; by week three the team will have it ready Friday afternoon and you will read it over coffee.
+
+**3. Save the first four reports in a folder.** After four weeks, scroll through them. Three things should be true: every Shipped section names a URL you actually clicked; the Blocked section lists you by name at least once; the Concern section flagged something that came true at least once. If none of those three things happen, the format is being filled in but not used. Read [the three standup questions](/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/) and [the eight red flags checklist](/blog/dev-shop-red-flags-checklist/) - the problem is upstream of the report.
+
+## Further reading
+
+- Atlassian, [How to Write an Effective Project Status Report](https://www.atlassian.com/work-management/project-management/status-reports) - the canonical reference on what status reports are for and where they fail.
+- DHH, [The One Person Framework](https://world.hey.com/dhh/the-one-person-framework-711e6318) - the Rails case for one full-stack developer shipping a feature end-to-end, which is why the five-section report fits on one page.
+- Marty Cagan, [Product Status Reports](https://www.svpg.com/product-status-reports/) - on why traditional status reports tell you nothing about whether the product is moving and what to ask for instead.
+- Will Larson via First Round Review, [Engineering leadership anti-patterns from Stripe, Uber, Carta](https://review.firstround.com/unexpected-anti-patterns-for-engineering-leaders-lessons-from-stripe-uber-carta/) - on the pull request funnel as the load-bearing signal in any status format.
+- Wes Kao, [How to Write a Great Status Update](https://newsletter.weskao.com/p/great-status-update) - a practitioner reference on the discipline of writing one short, useful update a week.
+- Eric Ries via Lean Startup Co., [What Is an MVP?](https://leanstartup.co/resources/articles/what-is-an-mvp/) - the validated-learning framing that makes "what did we cut?" a real product question, not a comfort question.
+
+Built by JetThoughts as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum. Authorship credit only - no service pitch.
diff --git a/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/report-comparison.svg b/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/report-comparison.svg
new file mode 100644
index 000000000..41d557cbd
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/report-comparison.svg
@@ -0,0 +1,105 @@
+
+
+  Weekly report comparison: jargon wall vs. one-page five-section format
+  Two side-by-side mock email screenshots covering the same five working days. The left panel is a 1,840-word jargon wall with no clickable URL. The right panel is a one-page report with five labelled sections — Shipped, In review, Blocked, Cut, Concern.
+
+  
+
+  
+  Same five days. Two reports.
+  Open both on Monday at 9am. Which one orients you?
+
+  
+  
+    
+    
+    Sprint 12 - Status Report
+    1,840 words
+
+    
+    
+      Team made significant progress on the v2 architectural
+      refactor and dependency hardening this sprint, prioritising
+      long-term maintainability across the platform...
+
+      
+      
+      
+
+      Velocity remained steady at 34 points (vs. 32 last sprint).
+      RAG status: Amber. Three risks tracked. Iterating on...
+
+      
+      
+      
+      
+
+      
+      
+      
+      [burndown chart]
+
+      
+      
+      
+      
+      
+      
+      [Jira screenshot]
+    
+
+    
+    
+      
+      No URL. No names. No decision needed by you.
+    
+  
+
+  
+  
+    
+    
+    Weekly report - week of 5 Oct
+    1 page
+
+    
+    
+      
+      1. Shipped
+      staging.acme.app/co/v2 - login below
+      discount-code field live; webhook fires
+
+      
+      2. In review
+      PR #847 - Marcos, Priya reviewing Tue
+      PR #851 - Marcos, no reviewer (PTO)
+
+      
+      3. Blocked
+      Stripe live keys - waiting on YOU
+      Need by Wed end-of-day or slip 1 wk
+
+      
+      4. Cut to ship
+      Admin override - Postgres console v1
+      Date-range picker - last-30-days only
+
+      
+      5. Concern next week
+      Orders-table migration locks ~30s
+      Want a 6am UK window to deploy
+    
+
+    
+    
+      
+      URL + named humans + 1 decision you owe
+    
+  
+
+  
+  
+    read time: 9:00 → 9:18
+    read time: 9:00 → 9:02
+  
+
diff --git a/content/course/tech-for-non-technical-founders-2026/where-to-hire-developer-2026-map/cover.png b/content/course/tech-for-non-technical-founders-2026/where-to-hire-developer-2026-map/cover.png
new file mode 100644
index 000000000..017b4de55
Binary files /dev/null and b/content/course/tech-for-non-technical-founders-2026/where-to-hire-developer-2026-map/cover.png differ
diff --git a/content/course/tech-for-non-technical-founders-2026/where-to-hire-developer-2026-map/index.md b/content/course/tech-for-non-technical-founders-2026/where-to-hire-developer-2026-map/index.md
new file mode 100644
index 000000000..58f8d740e
--- /dev/null
+++ b/content/course/tech-for-non-technical-founders-2026/where-to-hire-developer-2026-map/index.md
@@ -0,0 +1,193 @@
+---
+title: "Where to Hire Developer 2026 Map"
+aliases: ["/blog/where-to-hire-developer-2026-map/"]
+description: "Side-by-side comparison of onshore / nearshore / Tier-2 offshore hiring options for 2026. Pricing, time-to-hire, when to use each."
+date: 2026-05-18
+draft: false
+course_chapter: true
+author: "JetThoughts Team"
+slug: where-to-hire-developer-2026-map
+keywords:
+  - where hire developer 2026 map
+  - onshore nearshore offshore comparison
+  - tier 2 india engineering hub
+  - founder developer hiring template
+  - AI augmented developer job description
+tags:
+  - founders
+  - non-technical-founder
+  - template
+  - course-companion
+  - hiring
+categories: ["Templates"]
+canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/where-to-hire-developer-2026-map/"
+related_posts: false
+---
+
+📋 Template companion to the [Hire Track Supplementary Reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/). Print Monday morning. Pick your geography, pick your platform, post your role.
+
+# Where to Hire Developer 2026 - The Geography & Platform Map
+
+*One side of paper. Pick the region row. Pick two platforms. Write the job description from the template at the bottom. Post by Monday afternoon.*
+
+> **Geography quick-pick** (cost x timezone fit):
+> - **Onshore** (US / UK): high cost, timezone-aligned, fast ramp
+> - **LATAM** (Mexico, Colombia, Argentina): mid cost, timezone-aligned
+> - **Tier-2 India** (Coimbatore, Pune): low cost, async-only
+> - **Upwork / freelance**: variable, task-based, no commitment
+
+## Why this exists
+
+A B2B SaaS founder we picked up in Q2 2026 had been paying $185K base for a San Francisco Senior pitched as "AI-native." The Senior wrote good code but had never opened Cursor for a real ship and treated every contractor PR like he was reviewing a junior. After four months she was shipping one feature every three weeks. Her fractional CTO walked her through this map on a Tuesday. By Friday she had a Coimbatore Rails engineer at $42 an hour on a 3-day take-home test, and by the following sprint she had two features shipped and a hallucinated Stripe webhook caught in PR review. Replacement cost: 22% of the original burn. The map was not on her desk in February. It is on yours now.
+
+## How to use this
+
+Monday morning, alone, 30 minutes. Bring your filled-in [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) so you know the backend complexity. Bring your bank statement so you know the budget. Walk the four-row region table, circle the row your scope and budget land in, write the verdict at the top. Then pick two platforms from the seven-row list, one primary and one backup. Then copy the job description template, fill in the four fields in square brackets, and post both before lunch.
+
+If you find yourself comparing all four regions for an hour, you are negotiating with yourself. The decision is in your scope (regulated yes/no, async-acceptable yes/no) and your hourly budget. Both are factual.
+
+Total time budget: 30 minutes alone, 30 minutes posting, 0 minutes second-guessing.
+
+## The 4 regions
+
+Walk these four blocks in order. Circle the one your scope and budget land in, then move to the platform list.
+
+### Onshore (US / EU)
+
+Salaried, $130K - $210K+/year, 30-60 days to hire. Pick when: regulated industry (HIPAA, SOC 2 with US data residency, fintech license), security clearance, or board-mandated US team. Watch out for: 51% offer-acceptance rate and the worst cost-to-output ratio on the map.
+
+### Nearshore (LATAM)
+
+$45-$100/hr, $90K-$200K annualized, 2-5 days to hire. Pick when: you need real-time timezone overlap for pair programming, customer calls, or daily standups. US founder default in 2026. Watch out for: rates compressed in the top metros; English fluency varies by candidate - screen for it.
+
+### Tier-2 India
+
+$15-$70/hr, $30K-$140K annualized, 1-5 days to hire. Pick when: backend-heavy work where async is acceptable. Cities: Jaipur, Kochi, Indore, Coimbatore. NOT Bangalore. Watch out for: no 9am Pacific standups; async PR culture; build CLAUDE.md / coding-standards docs before the first PR lands.
+
+### Mass-market (Upwork)
+
+$35-$120/hr, project-based, 1-3 days to hire. Pick when: single landing page, logo, or one-off scraper. Anything you would ship and never touch again. Watch out for: you become the technical interviewer; no platform vetting. NOT for backend, payments, or auth.
+
+## The 7 platforms ranked
+
+Pick two: one primary based on your geography row above, one backup. Do not post on all seven.
+
+| Platform | Best for | Pricing |
+|---|---|---|
+| [**Toptal Fractional Executives**](https://toptal.com/fractional/cto) | Senior fractional roles, screened top 3% (3-5 days to slate) | $90 - $200/hr |
+| [**Bolster**](https://bolster.com/marketplace) | Largest curated fractional executive marketplace (3-7 days to slate) | Marketplace, transparent |
+| [**GoCoFound**](https://gocofound.com) | Fractional CTO and fractional product specifically (3-7 days to slate) | Project + retainer |
+| [**LatHire**](https://lathire.com) | LATAM nearshore developers, full-time and contract (2-5 days to slate) | $45 - $100/hr |
+| [**AI People Agency**](https://aipeople.agency) | AI-native engineer screening, AI Integration Engineer roles (<48 hr to slate) | $90 - $250/hr |
+| [**Seedium**](https://seedium.io) | AI-first software agency, project work via SOW (1-2 weeks to slate) | Project-based estimate |
+| [**Upwork**](https://upwork.com) | Mass-market freelance for point tasks ONLY (1-3 days to slate) | $35 - $120/hr |
+
+## The job description template - copy and paste
+
+Replace the four fields in square brackets and post on your two chosen platforms. The post screens against the AI-Augmented Developer profile, not the 2018 Senior profile.
+
+```
+=========================================================
+ROLE: Senior Engineer (AI-Augmented) - [your framework]
+=========================================================
+
+We are hiring a Senior Engineer to ship the [your product
+type, e.g. multi-tenant Rails SaaS for [your industry]]
+backend that our one-page brief calls for. The role is
+fractional or full-time, [your geography preference: LATAM
+nearshore / Tier-2 India / US onshore].
+
+WHAT WE NEED YOU TO DO
+
+- Ship features end-to-end in [Rails / Django / Laravel],
+  one PR at a time, against the acceptance criteria in
+  our SOW.
+- Direct an AI tool (Cursor, Claude Code, Aider, or
+  Copilot) for the heavy lifting and review the output
+  before it merges.
+- Catch the things the model is wrong about: hallucinated
+  packages, hallucinated column names, CSRF holes in
+  AI-generated auth code, and the rest.
+- Pair with our fractional CTO on the architecture-review
+  Monday call.
+
+PROFILE WE ARE HIRING
+
+- 5 to 10 years of shipped engineering experience.
+- Daily user of at least one of: Cursor, Claude Code,
+  Aider, GitHub Copilot. (We will ask to see your
+  CLAUDE.md or .cursorrules file.)
+- Has shipped AI-generated code to production AND
+  reviewed AI-generated code in pull request.
+- Can articulate where the model is wrong in your
+  framework. (If your answer is "the model is great,
+  no issues," this role is not for you.)
+- Multiple production ships in [Rails / Django /
+  Laravel].
+
+COMPENSATION
+
+[Pick the band that matches your geography row above.
+Examples:
+- Tier-2 India: $30 - $50 USD per hour, 30-40 hrs/wk.
+- LATAM nearshore: $60 - $90 USD per hour, 30-40 hrs/wk.
+- US onshore Senior: $130K - $180K base + equity.]
+
+OUR STACK
+
+- [Your framework + version, e.g. Rails 7]
+- Postgres, Heroku or Kamal-on-Hetzner, Stripe, [your
+  third-party APIs]
+- GitHub for source control, [your test framework] for
+  testing, [Sentry / Honeybadger] for errors
+
+TO APPLY
+
+Send: (1) GitHub profile or 3 PR links from production
+ships, (2) one-paragraph CLAUDE.md or .cursorrules
+philosophy, (3) the bug you would expect Cursor to
+introduce in our stack and how you would catch it.
+
+We reply to every application in 5 business days.
+Take-home test (3 hours, paid at your hourly rate)
+for short-list candidates.
+=========================================================
+```
+
+## What good looks like vs what bad looks like
+
+### Application response - the AI-direction question
+
+> Bad: *"I love Cursor. It is amazing. I use it every day for everything. The model writes 90% of my code now and I rarely have to step in."*
+
+> Good: *"My CLAUDE.md is 40 lines, mostly conventions for our Rails app: never name a model in the singular, always foreign-key migrations with index, fail fast on bad input. The model invents Stripe webhook handler signatures about every fourth time, so I run a contract test against the Stripe library docs before any payment-handler PR. The model also hallucinates npm packages, which is the slopsquatting attack vector, so I pin every dependency with `npm ci` instead of `npm install` in CI."*
+
+The good answer names the framework conventions, the specific failure mode (hallucinated Stripe signatures, hallucinated packages), and the concrete defense (contract tests, `npm ci` over `npm install`). The bad answer is a vibe metric ("amazing"), a percentage estimate that nobody can verify ("90%"), and zero acknowledgement that the model gets things wrong. The bad answer is the 2018 Senior with an AI sticker. The good answer is the 2026 hire.
+
+### First intro call - the framework question
+
+> Bad: *"I have done a lot of full-stack work. Some Rails, some Node, some Python. I am a polyglot."*
+
+> Good: *"Rails since 2019. Six production apps shipped, four still in production. The biggest is a [type] app at [scale], the smallest is a [type] app at [scale]. My most recent Rails ship was [last quarter] for [client / employer]. I prefer Postgres over MySQL because [specific reason about your scope]. Happy to walk you through the GitHub history of the most recent app on a screenshare."*
+
+The good answer is countable: years, ships, scale, recent quarter, screenshare offer. The bad answer is a list of frameworks the candidate has touched. Polyglot reads as "no deep ship in any one framework." For a pre-seed Rails app, you want six Rails ships, not three Rails + three Node + three Python.
+
+### Take-home test review - the slopsquatting catch
+
+> Bad: *"The candidate's code passes all tests. Looks clean. I would hire."*
+
+> Good: *"The candidate's code passes all tests. The package manifest pulls in `react-toolkit` (4 chars off from the real `redux-toolkit`). I asked. They had not noticed. The model invented the package, npm has a placeholder, and a malicious actor will register it within the week. The candidate did the work without the AI-direction discipline we hired for. Pass."*
+
+The good review reads the dependency manifest as carefully as the application code. The bad review checks the test green and stops there. The slopsquatting attack vector is in the [Bleeping Computer report on AI code supply chain attacks](https://www.bleepingcomputer.com/news/security/ai-code-suggestions-sabotage-software-supply-chain/); your candidate must spot this in PR review or you have hired the wrong profile.
+
+## What to do tomorrow
+
+1. **Write your geography choice and your two platforms at the top of a fresh Notion doc.** One line: *"Region: [Tier-2 India / LATAM nearshore / US onshore]. Platforms: [primary] + [backup]. Posted on [date]. First slate by [date + 5 days]."*
+2. **Schedule 5 intro calls in the same week.** Not three. Not ten. Five gives you a comparison and a rolling shortlist. Each call is 30 minutes. Use the four-question script from the [Hire Track Supplementary Reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#where-to-find-developers-in-2026).
+3. **Take the shortlist of 3-5 candidates to the [hiring interview](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#interviews-that-catch-ai-theater).** That section covers the deep-dive interview that catches AI theater. This map gets you to the shortlist; that post gets you to the hire.
+
+If you find yourself ten days in with no shortlist, the bottleneck is the job description, not the platforms. Re-read the AI-Augmented Developer profile in the post and tighten the five profile lines. Generic posts attract generic applicants.
+
+---
+
+*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.*
diff --git a/data/course_sequence.yaml b/data/course_sequence.yaml
new file mode 100644
index 000000000..0d6404236
--- /dev/null
+++ b/data/course_sequence.yaml
@@ -0,0 +1,135 @@
+# From Idea to First Paying Customer - chapter sequence (5-module spine)
+# Each entry: slug, title (short for nav), module label, goal (one-sentence outcome)
+# Order = reading sequence on the landing page (Module 1 -> end of Module 5).
+# Used by the prev/next partial on chapter pages.
+#
+# Note: Chapter 0 (how-this-course-works) is the overview/map chapter — read once before Module 1,
+# not in the linear prev/next reading order. Like the glossary, it's reference content
+# accessible from the landing page.
+#
+# Current count: 23 entries (1 overview + 21 chapters + 1 glossary)
+#
+# Note: floating glossary - "Five Tech Words to Stop Nodding At" (slug five-tech-words-stop-nodding-at)
+# is reference content, accessible from every chapter, not in the linear reading order.
+#
+# Continuation chapters (customers-leaving-churn-triage-not-acquisition,
+# pivot-or-persevere-decision-framework) and supplementary references
+# (hire-track-supplementary-reference, demoted management chapters,
+# demoted AI-era chapters) are linked from Module 5 "Going further" callout
+# but NOT in the linear sequence.
+
+sequence:
+  - slug: how-this-course-works
+    title: "How This Course Works"
+    module: "Chapter 0"
+    goal: "The map: 5 modules, 20 chapters, 6 artifacts, and the AI tools that accelerate each stage. Read once before starting."
+
+  - slug: form-your-founding-hypothesis-90-minute-sprint
+    title: "1.1 · Form Your Founding Hypothesis"
+    module: "Chapter 1.1"
+    goal: "Write a Founding Hypothesis scored ≥14/20 across four lenses — one sentence, five specific blanks, falsifiable in five interviews."
+
+  - slug: smoke-test-build-page
+    title: "1.2a · Smoke Test: Build the Page"
+    module: "Chapter 1.2a"
+    goal: "Publish a smoke-test page from your hypothesis in under an hour, then run a one-stranger clarity test."
+
+  - slug: smoke-test-wire-tracking
+    title: "1.2b · Wire Tracking Before You Spend a Dollar"
+    module: "Chapter 1.2b"
+    goal: "Install Microsoft Clarity and your ad-platform pixel before you spend a cent on traffic."
+
+  - slug: smoke-test-landing-page-7-day-demand-test
+    title: "1.2c · Smoke Test: Run It and Read the Signal"
+    module: "Chapter 1.2c"
+    goal: "Run 300 cold visitors against your page and make a go/iterate/kill decision from the conversion rate."
+
+  - slug: price-hypothesis-on-smoke-test-page
+    title: "1.3 · Price Your Hypothesis on the Smoke-Test Page"
+    module: "Chapter 1.3"
+    goal: "Add a Stripe Payment Link and measure whether strangers will pay — not just leave an email."
+
+  - slug: mom-test-ask-about-past-not-future
+    title: "2.1 · The Mom Test: Ask About the Past, Not the Future"
+    module: "Chapter 2.1"
+    goal: "Learn the 5-question Mom Test technique and build your draft interview question list."
+
+  - slug: ai-persona-pre-validation-mom-test-prep
+    title: "2.2 · Sharpen Your Question List with AI Personas"
+    module: "Chapter 2.2"
+    goal: "Polish the Ch 2.1 question list with a Claude persona companion pass before booking real slots."
+
+  - slug: find-10-people-where-to-look
+    title: "2.3a · Find 10 People: Where to Look"
+    module: "Chapter 2.3a"
+    goal: "AI ICP map + read threads + build a 30-name list of people you can name because you read what they posted."
+
+  - slug: find-10-people-with-problem-outreach-2026
+    title: "2.3b · Find 10 People: What to Say"
+    module: "Chapter 2.3b"
+    goal: "The 3-message sequence, volume targets, and research-panel fallback that books 10 interviews from the 30-name list."
+
+  - slug: clickable-prototype-validation-2-hour-lovable
+    title: "2.4 · Build a Clickable Prototype"
+    module: "Chapter 2.4"
+    goal: "Test the SHAPE of your solution with 5 interview subjects via a focused Lovable build."
+
+  - slug: one-page-product-brief-vibe-prd
+    title: "3.1 · The One-Page Product Brief (Vibe PRD)"
+    module: "Chapter 3.1"
+    goal: "Hand a single page to Lovable or a hired team that prevents over-engineering."
+
+  - slug: stop-specifying-features-start-outcomes
+    title: "3.2 · Quality-check your brief: features to outcomes"
+    module: "Chapter 3.2"
+    goal: "Stress-test Section 3 of your one-page brief by rewriting feature nouns as outcome-shaped job stories before handing off to Lovable or a contractor."
+
+  - slug: should-you-hire-2026-decision-tree
+    title: "4.1 · Should You Hire? The 2026 Decision Tree"
+    module: "Chapter 4.1"
+    goal: "Decide between self-serve, fractional CTO, or hired team via a 5-question matrix."
+
+  - slug: github-aws-database-ownership-checklist
+    title: "4.2 · Who Owns Your GitHub, AWS, and Database?"
+    module: "Chapter 4.2"
+    goal: "Confirm you own your code, cloud, domain, and database before any build starts."
+
+  - slug: self-serve-mvp-stack-lovable-supabase-stripe-2026
+    title: "4.3a · The Self-Serve MVP Stack: Tools & Setup"
+    module: "Chapter 4.3a"
+    goal: "Understand why Lovable + Supabase + Stripe is the dominant self-serve path and lock in the 3 pre-flight rules."
+
+  - slug: self-serve-mvp-stack-build-phases
+    title: "4.3b · The Self-Serve MVP Stack: Build Phases"
+    module: "Chapter 4.3b"
+    goal: "Execute the 4 build phases (Lovable UI → Supabase auth → Stripe checkout → live deploy) and pass the 5 green lights."
+
+  - slug: vibe-coding-ceiling-signals
+    title: "4.4 · Vibe Coding Done Right: 5 Ceiling Signals"
+    module: "Chapter 4.4"
+    goal: "Spot the 5 architectural signals that mean it's time to graduate beyond no-code."
+
+  - slug: must-have-segment-pmf-test
+    title: "5.1 · Your First Customer Is Not a Marketing Problem"
+    module: "Chapter 5.1"
+    goal: "Pass the Sean Ellis 40% test against your earliest users before any paid ads."
+
+  - slug: channel-selection-before-outbound
+    title: "5.2 · Choose Your Channel Before You Send One Message"
+    module: "Chapter 5.2"
+    goal: "Pick one outreach channel you'll commit to before scaling."
+
+  - slug: first-ten-customers-personal-network
+    title: "5.3 · The First Ten Come From People Who Already Know You"
+    module: "Chapter 5.3"
+    goal: "Convert 50 personalized warm DMs into your first 10 paid pilots."
+
+  - slug: paid-pilot-charge-before-ship
+    title: "5.4 · Charge Before You Ship: The Paid Pilot Contract"
+    module: "Chapter 5.4"
+    goal: "Sign a Design Partner Agreement with a refundable Stripe deposit before writing new code."
+
+  - slug: outbound-without-sales-team
+    title: "5.5 · Going Outbound Without a Sales Team"
+    module: "Chapter 5.5"
+    goal: "Send 30 filtered cold messages and book 1-2 paid pilots after the warm-network pass."
diff --git a/docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md b/docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md
index ab418af5d..11f816550 100644
--- a/docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md
+++ b/docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md
@@ -111,6 +111,20 @@ AI writes clean parallel lists. Humans don't. Mix formats:
 > ❌ "We understand how frustrating this must be for you."
 > ✅ "I know how this feels. You hired a team, wrote them a check, waited three months — and now the demo sort of works."
 
+**Never mention price/budget except in direct comparison.** (Added 2026-06-11.)
+A scattered `(free)` tag or "before you spend a dollar" prose reads as defensive cost-anxiety — and signals "we're a cheap brand for cheap customers." Use price/cost only when it's the actual choice axis ("Lovable Pro $20/mo vs. self-hosted free"). Rule of thumb: B2B tools >$100/mo deserve a cheaper alternative call-out; tools below that threshold should not mention price.
+> ❌ "Install [Microsoft Clarity](https://clarity.microsoft.com/) (free)..."
+> ✅ "Install [Microsoft Clarity](https://clarity.microsoft.com/)..."
+> ❌ "Build your smoke-test page before you spend a dollar on ads"
+> ✅ "Build your smoke-test page before traffic starts"
+> ❌ "Sign up at mixo.io (free, email only)"
+> ✅ "Sign up at mixo.io (email only)"
+
+**Never list 3+ interchangeable tools when one is the obvious lead.** (Added 2026-06-11.)
+If three AI page builders all do the same job, the reader picks one and ignores the others — listing all three just costs reading time and signals "we don't know which to recommend." Pick the most popular / most effective today as the example. Mention an alternative only when (a) it lives in a different category (e.g., AI generator vs manual no-code builder) or (b) the lead tool's price >$100/mo justifies naming a cheaper option.
+> ❌ "Three options: Mixo (fastest), Manus AI (layout control), Durable (templates). This lesson walks through Mixo."
+> ✅ "This lesson uses Mixo (fastest setup); most AI page builders are interchangeable for this workflow."
+
 ---
 
 ## 3. Banned Words & Phrases
@@ -185,6 +199,9 @@ These patterns are invisible at the word level but scream "AI wrote this" at the
 | Long paragraphs (cap break) | Paragraphs running over 3 sentences OR over 70 words. Voice-guide cap is 3 sentences; the cap is unenforced when topic is procedural. Empirically: 39-58% of paragraphs in the recent TDD/XP cluster break the cap. Reading flow drops sharply once a paragraph runs past 3 sentences for an online reader. | Treat 3 sentences and 70 words as the working cap. If the idea genuinely needs more, the paragraph wants to be two paragraphs. The split point is usually where a sentence transitions from "what" to "why" or from "rule" to "example". |
 | Architecture enumeration | Listing the post's structural pillars in order ("X, then Y, then Z" / "five layers feed into each other") inside the body. Reads as table-of-contents, not prose. The H2 headings already carry the structure; restating it inside the body is signposting. | Let the H2 headings do structural work. Inside the body, describe what happens at each step using verbs and named outcomes, not the architectural label. If you need to introduce the system once, use one short paragraph and move on - never a numbered list inside prose. |
 | Formulaic founder-anecdote hook | The recurring shape "A founder we'll call [NAME] [time-stamped contact]. The MVP had been live for [duration]. She'd opened it to her first cohort - [N] paying users on a [INDUSTRY] [product type] she'd been building for [period] - and [specific failure mechanic]. [N] of those [N] users hit the bug in the first [duration]. Her solo agent had built the entire app in [weekend/sprint], told her it had '[reassuring claim]', and not once mentioned [missing thing]." Reads as practitioner specificity but at this density the template is the tell. Empirically: appears in 5 of the last 5 founder-pain posts with the same beats (Priya, Marcus, Sarah). | Vary the opener shape across posts. The next 3 posts should use 3 different hook shapes - one might open on a Slack message verbatim, one on a code diff, one on a number from a CI dashboard. The "fictional founder + specific stats + 'told her X but not Y' reveal" formula is now the post's own tell. Use it once a quarter, not every post. |
+| Slogany reveal-twist flip | "X hadn't been Y - Z had been." / "It's not about X. It's about Y." / "X wasn't Y - it was Z." / "The original hypothesis hadn't been wrong - the questions had been." 2-sentence pivot from negation to assertion. Reads as a content-marketer punchline. Empirically: appeared 25+ times across M1-M3 (9 chapters) when the 4-persona panel ran 2026-05-28. | State the cause and effect in normal order; let the reader supply the contrast. "the hypothesis was probably right and the questions were probably broken; the real interviews confirmed both" beats "the original hypothesis hadn't been wrong - the questions had been." |
+| Cost-stacked tri-list opener | "A real customer interview costs you $25 to $100 in incentives, 40 minutes of calendar, and one of the 10 slots you have for this validation round." 3 parallel cost/time/count items presented as if from a workshop slide. Reads as didactic, not practitioner. | Embed the costs in prose, drop the symmetric serial-list shape, or reduce to the one or two costs that actually drive the reader's decision. "Real interview slots are scarce. You only get about 10 a round, every one took outreach to book, and a hypothetical question burns the slot." |
+| Cute aphoristic flourish closer | "...the whole slot produces polite noise." / "...the kind smile that costs you a year." / "...the helpful answer is the trap." / "Everything else is your mom being nice." Invented metaphor packaging a teaching point at paragraph end. Reads as marketing pull-quote, not practitioner observation. | State the concrete mechanic instead. "polite noise" → "the interviewee says 'sure, I'd use it' to be kind, you hang up thinking you got a signal, and you got nothing usable." If you cannot state the mechanic concretely, the teaching point isn't earned yet. |
 
 ### Punctuation
 
diff --git "a/docs/_research/\320\222\320\260\320\273\320\270\320\264\320\260\321\206\320\270\321\217 \320\221\320\270\320\267\320\275\320\265\321\201-\320\230\320\264\320\265\320\270_ \320\241\320\270\321\201\321\202\320\265\320\274\320\260 \320\270 \320\230\320\275\321\201\321\202\321\200\321\203\320\274\320\265\320\275\321\202\321\213.md" "b/docs/_research/\320\222\320\260\320\273\320\270\320\264\320\260\321\206\320\270\321\217 \320\221\320\270\320\267\320\275\320\265\321\201-\320\230\320\264\320\265\320\270_ \320\241\320\270\321\201\321\202\320\265\320\274\320\260 \320\270 \320\230\320\275\321\201\321\202\321\200\321\203\320\274\320\265\320\275\321\202\321\213.md"
new file mode 100644
index 000000000..48b8751d0
--- /dev/null
+++ "b/docs/_research/\320\222\320\260\320\273\320\270\320\264\320\260\321\206\320\270\321\217 \320\221\320\270\320\267\320\275\320\265\321\201-\320\230\320\264\320\265\320\270_ \320\241\320\270\321\201\321\202\320\265\320\274\320\260 \320\270 \320\230\320\275\321\201\321\202\321\200\321\203\320\274\320\265\320\275\321\202\321\213.md"	
@@ -0,0 +1,176 @@
+# **Комплексный анализ текущего рынка инструментов для валидации бизнеса и стандартизированная система запуска стартапов (Июнь 2026 года)**
+
+По состоянию на июнь 2026 года ландшафт создания коммерческих проектов претерпел фундаментальную трансформацию. Корпоративный рынок искусственного интеллекта перестал быть неизведанным рубежом: восемьдесят процентов компаний из списка Fortune 500 активно используют генеративный ИИ в своих рабочих процессах.1 Однако в среде малого бизнеса, независимых разработчиков (Indie Hackers) и начинающих предпринимателей наблюдается парадоксальная ситуация. Несмотря на доступность инструментов, позволяющих заменить целые отделы маркетинга и разработки, статистика успешности новых проектов остается низкой.1 Основная причина заключается в том, что основатели пропускают критический этап — валидацию (подтверждение) бизнес-идеи реальным рынком до начала разработки продукта.3  
+Многие начинающие предприниматели совершают классическую ошибку: они придумывают решение, основываясь на собственных догадках, и сразу переходят к созданию продукта, тратя месяцы на написание кода или сборку сложных систем. Когда продукт готов, выясняется, что целевая аудитория не готова за него платить. Анализ сотен обсуждений на профильных форумах подтверждает, что самая сильная и достоверная метрика жизнеспособности — это ситуация, когда нетехнические специалисты самостоятельно описывают проблему, за решение которой они готовы заплатить.4 Если идея имеет ценность без бизнес-модели и понимания того, кто является клиентом, она не способна генерировать прибыль.3  
+Данный отчет представляет собой исчерпывающий анализ рынка инструментов валидации по состоянию на июнь 2026 года. В документе разработана стандартизированная шестинедельная система, спроектированная специально для начинающих предпринимателей без опыта и без стартового капитала. Цель системы — провести абстрактную бизнес-идею через строгий процесс проверки, опираясь на современные бесплатные ИИ-инструменты, собрать доказательства реального спроса, найти первых платящих клиентов и определить оптимальные каналы сбыта.
+
+## **Эволюция рынка инструментов валидации в 2026 году**
+
+К 2026 году рынок инструментов для проверки гипотез фрагментировался, разделившись на три четкие категории, каждая из которых решает специфическую задачу. Понимание различий между ними критически важно для нулевого бюджета, так как правильная комбинация бесплатных тарифов позволяет получить аналитику, которая ранее стоила десятки тысяч долларов. Эти категории включают системы на базе генеративного ИИ, системы оценки реального спроса и гибридные платформы.5
+
+### **Системы валидации на базе генеративного ИИ**
+
+Инструменты данной категории используют большие языковые модели (LLM) для анализа вводных данных. Они оценивают логику бизнес-концепции, рассчитывают потенциальный объем рынка (TAM/SAM/SOM), анализируют конкурентную среду и выявляют риски. Их главный недостаток — риск «галлюцинаций» (когда ИИ выдает желаемое за действительное), поэтому их данные должны восприниматься как стратегический вектор, а не как безусловная истина.5  
+Лидером рынка в этой категории признана платформа IdeaProof. По результатам исследований, ее точность достигает 89%, что обусловлено применением ансамблевого подхода. Вместо использования одной модели, IdeaProof анализирует идею параллельно через Claude Sonnet 4, GPT-4.1, Gemini 3 и Grok 4.1. Этот метод перекрестной проверки значительно снижает риск ошибок.5 Платформа предлагает всеобъемлющие отчеты, включающие SWOT-анализ конкурентов и трехлетние финансовые прогнозы. Для начинающих предпринимателей платформа предоставляет 70 бесплатных кредитов (без необходимости привязки банковской карты), что делает ее оптимальным стартовым инструментом.5 Статистика платформы показывает, что стартапы, получившие оценку выше 80 баллов, имеют 73-процентный уровень выживаемости через два года.6  
+Платформа ValidatorAI предлагает альтернативный подход в формате диалога. Виртуальный советник "Val" анализирует идею и в реальном времени генерирует структурированный обзор целевой аудитории и рынка. Этот инструмент имеет рейтинг 4.85 на Product Hunt и базу из более чем 300 000 сессий валидации.6 Основатель Flickonic, Вассан Шуббар, отмечал, что ValidatorAI точно подсветил ключевые вопросы, которые впоследствии задавали инвесторы.6 Инструмент бесплатен для базовых проверок, однако опытные пользователи форумов предупреждают о его склонности к чрезмерному оптимизму — он редко критикует откровенно слабые идеи, что может создать у новичка ложное чувство уверенности.5  
+Для создания глубоких инвестиционных документов (VC-style reports) используется платформа DimeADozen. Она генерирует 40-страничные отчеты, извлекая данные из публичных финансовых документов (S-1 filings) для расчета юнит-экономики и кривых удержания клиентов (retention curves).5 Энди Дэй, генеральный директор Capital A, в своем обзоре отметил, что в этих отчетах содержится больше инноваций, чем в традиционном бизнес-плане.6 Однако стоимость полного отчета начинается от 129 долларов (или 59 долларов за использование), а подготовка занимает до 48 часов, что делает инструмент недоступным для стратегии без бюджета, за исключением использования его бесплатной функции базовой оценки (Solo score).5  
+Платформа VenturusAI выступает связующим звеном между проверкой идеи и планированием, предоставляя автоматизированный анализ по структурам PESTEL и пяти силам Портера. Пользовательская база превышает 154 000 предпринимателей, а бесплатный тариф, позволяющий генерировать два отчета в месяц, предоставляет новичкам возможность бесплатно составить первичную документацию для проекта.5 Пользователи, включая бизнес-аналитиков и студентов, высоко оценивают платформу за невероятную глубину автоматизированной аналитики, генерируемой всего из нескольких предложений описания.6  
+Венчает категорию исследовательский движок Perplexity. В отличие от традиционных поисковых систем, выдающих ссылки на сайты, Perplexity работает как система прямых ответов. В контексте бизнес-разведки он незаменим. Предприниматель может попросить систему проанализировать конкретный нишевый рынок, выявить трех главных конкурентов и собрать их негативные отзывы с платформы G2, касающиеся ценообразования.7 Perplexity предоставляет ссылки на источники и способен легально обходить платные преграды (paywalls) для сбора данных, что критически важно для нахождения наиболее острых проблем потребителей.7
+
+### **Системы на основе анализа реального спроса и доказательств**
+
+Вторая категория инструментов игнорирует логические размышления нейросетей, концентрируясь исключительно на цифровых следах реальных людей. Если потребители не обсуждают проблему в интернете, эти системы понизят оценку идеи.5  
+Инструмент Trend Seeker преобразует бизнес-идею в семантические векторы и ищет совпадения в базе из более чем 50 000 реальных запросов с Reddit и других сообществ.5 Система рассчитывает рейтинг от 0 до 100 на основе объема запросов и степени сходства идей. Высокий объем запросов при низком сходстве с существующими продуктами указывает на свободную нишу.6 Сервис имеет бесплатный лимитированный уровень, позволяющий увидеть, какими словами люди описывают свою боль.  
+Платформа Preuve AI (ранее Test Your Idea) применяет доказательный подход, сканируя более 40 живых источников данных (от Product Hunt до Indie Hackers). Особенность сервиса — гиперссылки на каждый вывод. Preuve AI известен своей жесткой, реалистичной критикой: 90% идей получают оценку ниже 70 баллов, поскольку алгоритм активно ищет блокирующие факторы, а не повод для похвалы.5 Для тестирования без бюджета доступна базовая оценка жизнеспособности.5  
+Для глубокой работы с аудиторией применяется Reddinbox. Этот AI-инструмент автоматизирует поиск в Reddit и Quora, выявляя обсуждения с высоким коммерческим намерением. Процесс ручного поиска, который занимал бы часы, сокращается до нескольких минут. В связке с бесплатным архивом Pushshift, который позволяет исследовать исторические данные, предприниматель может отследить эволюцию спроса в конкретной нише на протяжении нескольких лет.8
+
+### **Гибридные инструменты и платформы опросов**
+
+Третий подход объединяет ИИ-аналитику с привлечением реальных людей. Платформа WorthBuild, помимо анализа конкурентов, ежедневно сканирует Reddit, Hacker News и X (бывший Twitter) в поисках лидов — людей, прямо сейчас жалующихся на проблему. Система генерирует оценку вовлеченности каждого лида и предлагает персонализированное сообщение для начала диалога. Сервис предлагает одну бесплатную проверку в месяц.5  
+Когда необходимо ранжировать функции будущего продукта, используется платформа OpinionX. В отличие от стандартных опросов, OpinionX использует метод стекового ранжирования. Респонденты вынуждены делать сложный выбор, расставляя приоритеты, что предотвращает ситуацию, когда пользователи отмечают все функции как «очень важные». Основатель и генеральный директор Эван Киркхэм отметил, что инструмент создает ощущение присутствия «объективного голоса» в комнате во время принятия решений.6 Бесплатный тариф ограничен 10 респондентами, что достаточно для качественного проблемного интервью на ранней стадии.6
+
+### **Сравнительный анализ инструментов (Оптимизация для нулевого бюджета)**
+
+| Название инструмента | Категория | Ключевое функциональное преимущество | Доступность для нулевого бюджета | Точность / Оценка |
+| :---- | :---- | :---- | :---- | :---- |
+| **IdeaProof** | ИИ-Анализ | Перекрестная проверка гипотез четырьмя независимыми языковыми моделями. | 70 бесплатных кредитов (не требует кредитной карты).5 | 89% (доказано на 10 000+ проектах).5 |
+| **Trend Seeker** | Анализ спроса | Поиск доказательств потребности на основе семантического анализа форумов (Reddit). | Ежедневный бесплатный лимит на проверку идей.6 | 73% (зависит от представленности ниши в сети).5 |
+| **ValidatorAI** | ИИ-Анализ | Мгновенный диалоговый анализ и поиск "слепых зон" бизнес-модели. | Неограниченное количество базовых проверок бесплатно.6 | 75% (рейтинг 4.85 на Product Hunt).5 |
+| **Preuve AI** | Доказательный | Поиск блокирующих факторов по 40+ источникам с обязательным цитированием ссылок. | Бесплатный базовый балл жизнеспособности (полные отчеты платные).5 | 82%.5 |
+| **WorthBuild** | Гибридный | Автоматический парсинг социальных сетей для набора первых потенциальных клиентов. | 1 бесплатная проверка в месяц.5 | 78%.5 |
+| **Perplexity** | Поисковый ИИ | Агрегация данных о конкурентах и синтез негативных отзывов из закрытых источников. | Базовый доступ полностью бесплатен.7 | Высокая для исследовательских задач. |
+| **Reddinbox** | Анализ спроса | Детекция фраз с высоким коммерческим интентом на Reddit и Quora. | Требует настройки, но заменяет ручной поиск.8 | Высокая для органического поиска. |
+
+## **No-Code Инфраструктура: Инструменты для создания MVP (2026 год)**
+
+Получение аналитики от ИИ-платформ является лишь первым шагом. Чтобы доказать наличие спроса, необходимо предложить пользователям концепцию решения и измерить их готовность к взаимодействию. На форумах, таких как Reddit (раздел r/nocode и r/SaaS), предприниматели активно обсуждают лучшие стеки технологий для быстрого и бесплатного запуска минимально жизнеспособного продукта (MVP).9  
+Исторически создание MVP требовало найма разработчиков, что сразу отсекало людей без бюджета. В 2026 году No-Code (без кода) и ИИ-генераторы кода демократизировали этот процесс.13 Для сборки посадочной страницы (landing page), которая служит витриной бизнеса, сообщество настоятельно рекомендует инструменты вроде Carrd и Framer.13 Carrd позволяет за час создать адаптивный одностраничный сайт, что идеально подходит для предварительного сбора контактов (waitlists).13 Framer объединяет гибкость дизайна с ИИ, позволяя сгенерировать сайт по текстовому описанию.13 Оба инструмента имеют бесплатные тарифы, хотя они и оставляют свой брендинг на сайте (например, project.carrd.co).  
+Для более сложной логики, такой как создание базы данных, автоматизация рассылок или симуляция работы приложения ("faking the backend"), предприниматели используют связки бесплатных инструментов. Формы сбора данных конструируются в Tally, затем через Zapier или Make.com данные маршрутизируются в базы Notion или Airtable.12 Этот подход позволяет симулировать полноценный SaaS-продукт, обрабатывая запросы клиентов вручную за кулисами, что для самого клиента выглядит как автоматизированный процесс.12 Если же требуется полноценное веб\-приложение, на сцену выходят ИИ-кодеры (AI Coding tools), такие как Bolt.new, Lovable или Cursor, которые позволяют развернуть работающий интерфейс из текстовых подсказок.9
+
+| Компонент MVP | Инструмент | Роль в процессе валидации | Стратегия нулевого бюджета |
+| :---- | :---- | :---- | :---- |
+| **Фронтенд / Витрина** | Carrd / Framer | Создание посадочной страницы, описание боли клиента и ценностного предложения.13 | Использование бесплатного поддомена. Высокая эстетика не требуется на старте. |
+| **Сбор данных** | Tally / Typeform | Опросы, формы предзаказа, запись на глубинные интервью.14 | Tally предоставляет большинство критических функций бесплатно без ограничений на логику. |
+| **Бэкенд / База данных** | Airtable / Notion | Симуляция серверной части. Хранение лидов, статусов обработки заявок.12 | Бесплатные тарифы покрывают нужды первых сотен клиентов. |
+| **Связки и Автоматизация** | Zapier / Make | Маршрутизация данных между фронтендом и базами данных.12 | Использование бесплатных планов (до 1000 операций в месяц). |
+| **Генерация кода (Опционально)** | Bolt.new / Lovable / Cursor | Создание функциональных прототипов программного обеспечения с помощью ИИ.9 | Базовые сборки доступны бесплатно для тестирования интерфейса. |
+
+## **Психология валидации: Уроки из сообществ и методология "Mom Test"**
+
+Технические инструменты бесполезны, если основатель задает неправильные вопросы. Анализ дискуссий на Indie Hackers и Reddit раскрывает фундаментальную проблему: люди по своей природе вежливы. Когда предприниматель спрашивает друзей, семью или даже незнакомцев: «Как вам моя идея?», социальные нормы диктуют дать ободряющий ответ.15 В результате предприниматель получает ложное чувство подтверждения спроса, тратит месяцы на разработку и терпит крах при попытке продать продукт.  
+Решением этой проблемы является методология, известная как "Тест для мамы" (The Mom Test).16 Ее суть заключается в формулировании вопросов таким образом, чтобы даже собственная мать не смогла солгать из вежливости. Процесс коммуникации с потенциальными клиентами (Customer Development или CustDev) должен быть выстроен вокруг следующих жестких правил 16:
+
+1. **Запрет на упоминание идеи.** Предприниматель не должен говорить о своем продукте.16 Люди не заботятся о ваших идеях; их волнуют собственные проблемы. Беседа должна вращаться исключительно вокруг жизни, рутины и профессиональных задач клиента.16  
+2. **Фокус на прошлом опыте, а не на гипотетическом будущем.** Люди крайне плохо предсказывают свое поведение. Вопрос "Купили бы вы продукт, который делает Х?" бесполезен, так как люди склонны переоценивать свою готовность платить.16 Вместо этого необходимо спрашивать: "Расскажите мне о последнем разе, когда вы столкнулись с этой проблемой".16  
+3. **Оценка приложенных усилий.** Самый важный индикатор реальной боли — это попытки клиента решить проблему самостоятельно. Необходимо задать вопрос: "Что вы уже пытались сделать для решения этой проблемы? Сколько это вам стоило?".16 Если клиент отвечает, что он ничего не предпринимал и не тратил деньги на аналоги, это является категорическим красным флагом. Если проблема не заставляла их искать решение в прошлом, они не станут клиентами в будущем.16  
+4. **Выявление истинной мотивации.** Вместо вопроса "Использовали бы вы это?", следует спросить "Почему эта проблема вообще имеет для вас значение?" (Why does this matter to you?). Это позволяет докопаться до корня боли, который часто лежит в плоскости психологии (страх потери статуса, увольнения, потери времени).18  
+5. **Цепочка рекомендаций.** В конце разговора необходимо спросить: "С кем еще мне стоит поговорить об этом?".16 Готовность человека познакомить вас со своими коллегами — это показатель того, что тема действительно важна для него.
+
+Еще один важный психологический барьер, обсуждаемый на форумах — это страх запуска на бесплатном домене. Многие начинающие предприниматели считают, что бесплатный поддомен (например, .carrd.co) подорвет доверие к их MVP, и тратят последние средства на покупку доменов .com для каждой не проверенной идеи.21 Однако консенсус опытных практиков гласит: эстетика не должна становиться преградой. Если проблема действительно "горящая", клиент оставит свой контакт или заплатит даже на уродливом сайте. Использование субдоменов для валидации — это не саботаж, а разумный подход к бережливому тестированию.12  
+Кроме того, опытные венчурные строители предупреждают о ловушке валидации среди других фаундеров (founder-to-founder validation).4 Общение в предпринимательских сообществах создает эхо-камеру. Настоящий сигнал спроса поступает только тогда, когда человек без технических навыков и бизнес-интереса описывает проблему своими словами и заявляет о готовности платить за ее устранение.4
+
+## **SIPOC-Архитектура: Трансформация концепции в продукт**
+
+Для того чтобы структурировать процесс запуска, необходима четкая архитектурная схема. Методология SIPOC (Suppliers, Inputs, Process, Outputs, Customers) позволяет оцифровать и стандартизировать весь поток ценности: от абстрактной мысли в голове основателя до перевода средств на банковский счет от первого клиента.
+
+| Элемент SIPOC | Содержание и инструменты этапа |
+| :---- | :---- |
+| **S \- Suppliers (Поставщики ресурсов и данных)** | 1\. **Генераторы идей**: Рыночные неэффективности, личный опыт, тренды.15 2\. **Базы данных спроса**: Reddit, Quora, Hacker News, индустриальные форумы.5 3\. **AI-Провайдеры**: IdeaProof (оценка), Trend Seeker (поиск), Perplexity (аналитика).5 4\. **Провайдеры инфраструктуры**: Carrd, Framer, Tally, Notion, Zapier.12 |
+| **I \- Inputs (Входные параметры)** | 1\. Базовая неструктурированная гипотеза о существовании проблемы.22 2\. Набор ключевых слов и фраз для семантического поиска.8 3\. Нулевой бюджет и инвестиции времени основателя (2-4 часа в день). 4\. Заранее подготовленный скрипт для интервью по методологии "Mom Test".16 5\. Список из 20-30 профилей потенциальных клиентов для первого контакта.20 |
+| **P \- Process (Процесс \- 6 Недель)** | **Неделя 1:** Идентификация аудитории, семантический поиск, формулировка концепта.22 **Неделя 2:** Проведение глубинных интервью (CustDev).20 **Неделя 3:** Многомодельная перекрестная проверка ИИ и анализ конкурентов.5 **Неделя 4:** Визуализация решения, сборка MVP без написания кода.13 **Неделя 5:** Теневое тестирование, прямые видео-рассылки, партизанский маркетинг.15 **Неделя 6:** Расчет метрик удержания, попытка первой продажи, решение о масштабировании.22 |
+| **O \- Outputs (Выходные результаты)** | 1\. Оцифрованные профили задач (Jobs-to-be-Done) с точными цитатами аудитории.22 2\. Сводные отчеты об объемах поисковых запросов и выявленных конкурентах.15 3\. Функционирующая посадочная страница с интегрированной логикой сбора данных.13 4\. База теплых лидов (Waitlist) или предзаказов.10 5\. Письма о намерениях (LOI) или проведенные финансовые транзакции. |
+| **C \- Customers (Клиенты и выгодоприобретатели)** | 1\. **Внешний клиент:** Ранние последователи (Early Adopters) — люди с острой, нерешенной болью, готовые терпеть недостатки MVP ради получения результата. 2\. **Внутренний клиент:** Основатель бизнеса, получающий математическое подтверждение жизнеспособности (или нежизнеспособности) идеи перед вложением капитала в масштабную разработку.3 |
+
+## **Стандартизированная 6-недельная система валидации (с нулевым бюджетом)**
+
+Данный фреймворк синтезирует методы бережливого стартапа (Lean Startup), концепцию Customer Development и возможности нейросетей образца 2026 года.22 Ключевой принцип системы: на любом этапе предприниматель должен быть готов отказаться от идеи (инвалидировать ее), если данные не подтверждают первоначальную гипотезу. Быстрый провал — это успех, так как он экономит годы жизни и ресурсы.27
+
+### **Неделя 1: Картографирование рынка и семантический поиск**
+
+Процесс запуска начинается не с описания продукта, а с определения аудитории.22 Попытка создать продукт «для всех» обречена на провал.  
+В первые дни необходимо сузить целевую аудиторию до максимально специфической группы. Вместо "владельцы малого бизнеса" следует выбрать "владельцы кофеен в спальных районах, теряющие клиентов из\-за оттока бариста". Применяя концепцию Jobs-to-be-Done (JTBD), нужно сформулировать проблему, которую клиент пытается решить в заданном контексте.22  
+Далее в работу вступают ИИ-инструменты. Идея прогоняется через бесплатный тариф Trend Seeker, чтобы определить, ищут ли люди решение на форумах.6 Параллельно предприниматель использует Perplexity для глубокого анализа рынка. Запросы должны быть сложными: «Найди 5 существующих программных решений для \[ниша\]. Выпиши основные жалобы пользователей на ценообразование и отсутствие функций, ссылаясь на отзывы с G2 и Capterra».7 Кроме того, используется Reddinbox или Pushshift для автоматизированного поиска по архивам Reddit ключевых фраз коммерческого намерения (например, "как автоматизировать", "задолбался делать вручную").8  
+*Критерий перехода:* Если поисковые системы и социальные сети не показывают наличия жалоб, а конкурентов не существует вовсе (что обычно означает отсутствие рынка 15), концепцию необходимо пересмотреть. Если органические сигналы спроса обнаружены, начинается Неделя 2\.
+
+### **Неделя 2: Качественная эмпатия и Customer Development**
+
+Данные алгоритмов необходимо подтвердить разговорами с живыми людьми. Задача этой недели — провести от 10 до 20 бесед с представителями целевой аудитории.20  
+Процесс начинается с "холодного" поиска. Опираясь на данные первой недели, предприниматель отправляет личные сообщения (DM) пользователям на Reddit, X (Twitter) или LinkedIn, которые ранее обсуждали данную проблему.23 Сообщение должно быть предельно честным и не содержать попыток продажи: «Привет\! Видел ваш комментарий о проблеме X. Я провожу исследование в этой области и пытаюсь понять, почему существующие инструменты работают так плохо. Буду признателен за 10-минутный созвон. Я ничего не продаю».23  
+Во время интервью категорически применяется методология "Mom Test".16 Сценарий разговора строится вокруг изучения прошлого: как именно человек решает проблему сейчас, какие "костыли" он придумал, и сколько денег он тратит на существующие неэффективные альтернативы.16 Обязательно фиксируются точные слова и метафоры, которые клиент использует для описания своей боли. Эти цитаты станут самым конверсионным текстом для будущего сайта.26  
+*Критерий перехода:* Если большинство респондентов признают наличие проблемы, но не могут вспомнить, когда сталкивались с ней в последний раз, или не пытались тратить деньги на ее решение, идея отбрасывается.16 Если боль подтверждена реальными финансовыми или временными потерями — переход к Неделе 3\.
+
+### **Неделя 3: ИИ-Триангуляция и стратегическое позиционирование**
+
+Получив обратную связь от людей, предприниматель должен подвергнуть идею стресс-тесту с точки зрения бизнес-логики.  
+На этом этапе используется IdeaProof. Зарегистрировавшись для получения 70 бесплатных кредитов, предприниматель загружает в систему концепцию, описанную словами самих клиентов из интервью.5 Использование многомодельного ансамбля (Claude, GPT, Gemini) выявит скрытые юридические, экономические или конкурентные риски, о которых новички часто не задумываются.5  
+Параллельно проводится анализ существующих решений (выявленных на первой неделе). Цель — найти пробелы в продуктах конкурентов. На основе синтеза машинных отчетов и человеческих жалоб формулируется ценностное предложение (Value Proposition) — одно предложение, четко объясняющее, почему новый продукт будет лучше, быстрее или дешевле.25 На этом же этапе рассчитывается предварительная юнит-экономика: будет ли продукт приносить прибыль при текущей готовности клиентов платить.  
+*Критерий перехода:* Четкое понимание бизнес-модели, позиционирования и рисков. Формирование списка функций, которые абсолютно необходимы для минимальной жизнеспособности продукта (MVP).
+
+### **Неделя 4: Сборка фасада (No-Code MVP)**
+
+На четвертой неделе абстрактная идея обретает цифровую форму. Задача — создать иллюзию готового продукта без написания программного кода.12  
+Предприниматель регистрируется в конструкторах сайтов, таких как Carrd или Framer.13 На бесплатном поддомене собирается посадочная страница. Дизайн должен быть чистым, а заголовки — состоять из цитат клиентов, собранных на Неделе 2\.26 Главный элемент страницы — кнопка призыва к действию (Call to Action). Это может быть форма "Записаться в лист ожидания", "Запросить ранний доступ" или "Купить со скидкой 50% до запуска".  
+Логика работы собирается через Tally (для сбора данных), которая связывается через бесплатный тариф Make.com или Zapier с базой данных в Airtable или Notion.12 Если концепция подразумевает сложный анализ данных для клиента, на этапе MVP этот анализ может выполняться самим основателем вручную, тогда как для пользователя процесс будет выглядеть автоматизированным (метод "Консьерж" или "Wizard of Oz").12  
+*Критерий перехода:* Полностью функционирующая цифровая витрина, способная фиксировать интерес и собирать контакты потенциальных клиентов.
+
+### **Неделя 5: Теневое тестирование и органическая генерация трафика**
+
+Обладая готовой посадочной страницей, предприниматель приступает к теневому тестированию (Shadow testing).15 Исследования показывают, что слова одобрения на интервью часто расходятся с реальными действиями, когда нужно нажать кнопку или оставить email.15  
+Для привлечения первых посетителей без затрат на рекламу используются органические каналы:
+
+1. **Возврат к респондентам:** Основатель связывается с теми 20-30 людьми, с которыми общался на второй неделе, и сообщает: "Опираясь на наш разговор, я собрал черновую версию решения. Вот ссылка. Было бы интересно узнать ваше мнение".19  
+2. **Асинхронные видео-разборы (Loom):** Для B2B сектора основатель записывает короткие 10-минутные видео, в которых наглядно демонстрирует, как его MVP решает специфическую проблему конкретной компании. Эти видео отправляются напрямую лицам, принимающим решения.23 Отклик на персонализированные видео значительно выше, чем на холодные текстовые письма.23  
+3. **Партизанский маркетинг:** Публикация полезного контента на нишевых форумах, найденных на Неделе 1\. Важно не спамить ссылками, а предоставлять глубокую аналитику и экспертное мнение, оставляя ссылку на свой MVP только в контексте релевантного решения.
+
+*Критерий перехода:* Направление потока из 100–200 целевых посетителей на созданный сайт для оценки их поведения.
+
+### **Неделя 6: Анализ метрик и "Aha\!" момент**
+
+Финальный этап цикла — анализ собранных данных и принятие окончательного решения. Предприниматель оценивает воронку конверсии: какой процент посетителей сайта оставил свой контакт или попытался совершить оплату.  
+Ищется так называемый "Aha\!" момент — реакция аудитории, когда она мгновенно осознает ценность предложенного решения.22 Если конверсия посадочной страницы в целевое действие превышает 10-15%, а из базы лидов удается получить письма о намерениях (LOI) или прямые финансовые транзакции (если был подключен тестовый платежный шлюз), бизнес-идея считается успешно валидированной.  
+Если же, несмотря на целевой трафик, никто не подписывается, необходимо вернуться к клиентам и задать уточняющие вопросы по методологии "Mom Test" (узнать, почему они не совершили действие). Отсутствие интереса на этом этапе означает, что проблема не является критической, или решение не попало в цель. В этом случае концепция признается нежизнеспособной. Система требует безжалостно отбросить ее и вернуться к Неделе 1\.27 Потеря шести недель и нулевого бюджета — ничтожно малая цена по сравнению с годами жизни, потраченными на создание никому не нужного продукта.
+
+## **Идентификация каналов привлечения (Distribution Channels)**
+
+Важнейшей составляющей успешного стартапа является не только создание продукта, но и понимание того, как он будет доставляться клиентам (Product-Channel Fit и Channel-Model Fit).29 Отсутствие бюджета диктует необходимость концентрации на каналах, где стоимость привлечения клиента (CAC) стремится к нулю.  
+Исходя из опыта предпринимательских сообществ в 2026 году, наиболее эффективными бесплатными каналами приобретения первых платящих клиентов являются:
+
+1. **Нишевые интернет-сообщества (Reddit, Discord, Hacker News).** Присутствие в этих сообществах не должно носить рекламный характер. Стратегия заключается в мониторинге вопросов пользователей (с помощью автоматизации или ручного поиска) и предоставлении развернутых экспертных ответов. Продукт упоминается лишь как инструмент, упрощающий решение задачи.8  
+2. **Прямые персонализированные B2B-продажи (Loom Outreach).** Отправка записанных видеоаудитов конкретному бизнесу. Предприниматель наглядно показывает проблему потенциального клиента на его же сайте или в его процессах, а затем демонстрирует, как продукт решает эту боль.23 Метод требует значительных временных затрат на каждого лида, но обеспечивает беспрецедентно высокую конверсию.  
+3. **Реферальный нетворкинг.** Развитие сети контактов через теплые знакомства. Грамотное завершение проблемного интервью вопросом "К кому еще из вашей индустрии вы могли бы меня направить для обсуждения этой проблемы?".16 Рекомендация от коллеги кардинально снижает порог недоверия и укорачивает цикл продажи.  
+4. **Инструментальный маркетинг (Engineering as Marketing).** Создание бесплатных мини-инструментов, например, онлайн-калькуляторов или чеклистов (которые легко собираются на No-Code платформах за день), решающих одну микро-проблему. Такие инструменты привлекают целевой органический SEO-трафик и генерируют базу лояльных пользователей, которым впоследствии предлагается основной продукт.  
+5. **Создание контентных петель в социальных сетях.** Документирование процесса создания продукта в формате "Build in Public" на платформах X (Twitter) или LinkedIn. Рассказ об ошибках, метриках и успехах привлекает внимание не только других основателей, но и потенциальных клиентов, которым импонирует прозрачность компании. Важно, однако, фильтровать обратную связь от коллег по цеху, отдавая приоритет отзывам целевых покупателей.4
+
+В условиях 2026 года успех стартапа зависит не от объема венчурных инвестиций и не от способности написать сложный программный код. Ключевым конкурентным преимуществом становится скорость итерирования гипотез. Применение шестинедельного цикла бережливой валидации с использованием ансамблей искусственного интеллекта для аналитики, No-Code платформ для сборки прототипов и методологии "Mom Test" для извлечения правды из потребителей, позволяет любому энтузиасту найти свое место на рынке, не подвергая себя финансовым рискам. Строгая дисциплина процесса, умение слушать реальную боль клиента и готовность отказаться от собственных иллюзий — фундамент, на котором строятся прибыльные компании нового поколения.
+
+#### **Источники**
+
+1. Best AI Tools for Business in 2026: A Practical Evaluation Guide \- Helium42, дата последнего обращения: июня 4, 2026, [https://helium42.com/blog/best-ai-tools-for-business](https://helium42.com/blog/best-ai-tools-for-business)  
+2. Top 5 AI Tools Every Business Owner Should Be Using (2026 Edition) \- YouTube, дата последнего обращения: июня 4, 2026, [https://www.youtube.com/watch?v=uF9wm7BquKQ](https://www.youtube.com/watch?v=uF9wm7BquKQ)  
+3. How to validate a startup idea \- Indie Hackers, дата последнего обращения: июня 4, 2026, [https://www.indiehackers.com/post/how-to-validate-a-startup-idea-34f9df9d6b](https://www.indiehackers.com/post/how-to-validate-a-startup-idea-34f9df9d6b)  
+4. How to Validate Your AI Startup Idea FAST (Step-by-Step) \- YouTube, дата последнего обращения: июня 4, 2026, [https://www.youtube.com/watch?v=4Wyy1YiMWwo](https://www.youtube.com/watch?v=4Wyy1YiMWwo)  
+5. 8 Best AI Validation Tools 2026: Tested & Compared | IdeaProof, дата последнего обращения: июня 4, 2026, [https://ideaproof.io/best-ai-validation-tools-2026](https://ideaproof.io/best-ai-validation-tools-2026)  
+6. 7 Best AI Idea Validation Tools for 2026 (Tested Same Idea) | Trend ..., дата последнего обращения: июня 4, 2026, [https://trend-seeker.app/blog/idea-validation-tools](https://trend-seeker.app/blog/idea-validation-tools)  
+7. 7 Best AI Validation Tools for Startups (2026) | ValidateStrategy, дата последнего обращения: июня 4, 2026, [https://validatestrategy.com/ai-tools/best-ai-validation-tools](https://validatestrategy.com/ai-tools/best-ai-validation-tools)  
+8. How to Validate Startup Ideas on Reddit (2026 Guide) \- Reddinbox, дата последнего обращения: июня 4, 2026, [https://reddinbox.com/blog/how-to-validate-startup-ideas-on-reddit](https://reddinbox.com/blog/how-to-validate-startup-ideas-on-reddit)  
+9. What is the best No Code platform to create the MVP version of your SAAS? \- Reddit, дата последнего обращения: июня 4, 2026, [https://www.reddit.com/r/SaaS/comments/1j06ros/what\_is\_the\_best\_no\_code\_platform\_to\_create\_the/](https://www.reddit.com/r/SaaS/comments/1j06ros/what_is_the_best_no_code_platform_to_create_the/)  
+10. What are the best no-code tools to build an MVP for a web app? : r/SaaS \- Reddit, дата последнего обращения: июня 4, 2026, [https://www.reddit.com/r/SaaS/comments/1fqi03v/what\_are\_the\_best\_nocode\_tools\_to\_build\_an\_mvp/](https://www.reddit.com/r/SaaS/comments/1fqi03v/what_are_the_best_nocode_tools_to_build_an_mvp/)  
+11. Best no-code app builder for launching an MVP? : r/nocode \- Reddit, дата последнего обращения: июня 4, 2026, [https://www.reddit.com/r/nocode/comments/1lp36o2/best\_nocode\_app\_builder\_for\_launching\_an\_mvp/](https://www.reddit.com/r/nocode/comments/1lp36o2/best_nocode_app_builder_for_launching_an_mvp/)  
+12. How do you validate a startup idea quickly using no-code tools? \- Reddit, дата последнего обращения: июня 4, 2026, [https://www.reddit.com/r/nocode/comments/1rxukbz/how\_do\_you\_validate\_a\_startup\_idea\_quickly\_using/](https://www.reddit.com/r/nocode/comments/1rxukbz/how_do_you_validate_a_startup_idea_quickly_using/)  
+13. 30 No-Code Tools to Build a Startup in 2026 — The Complete Guide to Launching a Business Without Writing a Single Line of Code : r/Aivolut \- Reddit, дата последнего обращения: июня 4, 2026, [https://www.reddit.com/r/Aivolut/comments/1tu0bqo/30\_nocode\_tools\_to\_build\_a\_startup\_in\_2026\_the/](https://www.reddit.com/r/Aivolut/comments/1tu0bqo/30_nocode_tools_to_build_a_startup_in_2026_the/)  
+14. What are the best no-code tools to build MVPs fast? : r/GrowthHacking \- Reddit, дата последнего обращения: июня 4, 2026, [https://www.reddit.com/r/GrowthHacking/comments/1l8pt88/what\_are\_the\_best\_nocode\_tools\_to\_build\_mvps\_fast/](https://www.reddit.com/r/GrowthHacking/comments/1l8pt88/what_are_the_best_nocode_tools_to_build_mvps_fast/)  
+15. How To Validate a Business Idea \- Indie Hackers, дата последнего обращения: июня 4, 2026, [https://www.indiehackers.com/article/how-to-validate-a-business-idea-41245a143b](https://www.indiehackers.com/article/how-to-validate-a-business-idea-41245a143b)  
+16. Using the Mom Test for idea validation : r/Entrepreneur \- Reddit, дата последнего обращения: июня 4, 2026, [https://www.reddit.com/r/Entrepreneur/comments/1j5kk3z/using\_the\_mom\_test\_for\_idea\_validation/](https://www.reddit.com/r/Entrepreneur/comments/1j5kk3z/using_the_mom_test_for_idea_validation/)  
+17. The Mom Test : r/startups \- Reddit, дата последнего обращения: июня 4, 2026, [https://www.reddit.com/r/startups/comments/j1c92x/the\_mom\_test/](https://www.reddit.com/r/startups/comments/j1c92x/the_mom_test/)  
+18. The 5 questions from The Mom Test that actually validate SaaS ideas (learned the hard way \- Reddit, дата последнего обращения: июня 4, 2026, [https://www.reddit.com/r/SaaS/comments/1ohkre2/the\_5\_questions\_from\_the\_mom\_test\_that\_actually/](https://www.reddit.com/r/SaaS/comments/1ohkre2/the_5_questions_from_the_mom_test_that_actually/)  
+19. Mom test: How do you do it guys? : r/startups \- Reddit, дата последнего обращения: июня 4, 2026, [https://www.reddit.com/r/startups/comments/o0loc2/mom\_test\_how\_do\_you\_do\_it\_guys/](https://www.reddit.com/r/startups/comments/o0loc2/mom_test_how_do_you_do_it_guys/)  
+20. How do you validate a business idea before investing time and money? \- Reddit, дата последнего обращения: июня 4, 2026, [https://www.reddit.com/r/smallbusiness/comments/1qzzll3/how\_do\_you\_validate\_a\_business\_idea\_before/](https://www.reddit.com/r/smallbusiness/comments/1qzzll3/how_do_you_validate_a_business_idea_before/)  
+21. How do you validate startup ideas without wasting money on buying new domains every time? : r/indiehackers \- Reddit, дата последнего обращения: июня 4, 2026, [https://www.reddit.com/r/indiehackers/comments/1k8kzl3/how\_do\_you\_validate\_startup\_ideas\_without\_wasting/](https://www.reddit.com/r/indiehackers/comments/1k8kzl3/how_do_you_validate_startup_ideas_without_wasting/)  
+22. How To Validate Your Startup Idea In 6 Weeks: A Guide for 2025, дата последнего обращения: июня 4, 2026, [https://www.7-fit-framework.com/post/validate-your-startup-idea-in-6-weeks](https://www.7-fit-framework.com/post/validate-your-startup-idea-in-6-weeks)  
+23. Last day of 2025\. What tools did you use to find, validate and build your new business idea?, дата последнего обращения: июня 4, 2026, [https://www.reddit.com/r/SaaS/comments/1q09gyo/last\_day\_of\_2025\_what\_tools\_did\_you\_use\_to\_find/](https://www.reddit.com/r/SaaS/comments/1q09gyo/last_day_of_2025_what_tools_did_you_use_to_find/)  
+24. 3 верных способа проверить бизнес-идею — Офтоп на vc.ru, дата последнего обращения: июня 4, 2026, [https://vc.ru/flood/512419-3-vernyh-sposoba-proverit-biznes-ideyu](https://vc.ru/flood/512419-3-vernyh-sposoba-proverit-biznes-ideyu)  
+25. Lean Market Validation: 10 Ways to Rapidly Test Your Startup Idea | by Jim Semick, дата последнего обращения: июня 4, 2026, [https://jimsemick.medium.com/lean-market-validation-10-ways-to-rapidly-test-your-startup-idea-75602a37a471](https://jimsemick.medium.com/lean-market-validation-10-ways-to-rapidly-test-your-startup-idea-75602a37a471)  
+26. Customer Development или кастдев (custdev) в бизнесе | Инструкция с примерами, дата последнего обращения: июня 4, 2026, [https://vc.ru/marketing/575262-customer-development-ili-kastdev-custdev-v-biznese-instrukciya-s-primerami](https://vc.ru/marketing/575262-customer-development-ili-kastdev-custdev-v-biznese-instrukciya-s-primerami)  
+27. From idea to validation in 24 hours \- Indie Hackers, дата последнего обращения: июня 4, 2026, [https://www.indiehackers.com/post/from-idea-to-validation-in-24-hours-69dd90c310](https://www.indiehackers.com/post/from-idea-to-validation-in-24-hours-69dd90c310)  
+28. How to validate a startup idea before you waste months building the wrong thing, дата последнего обращения: июня 4, 2026, [https://www.indiehackers.com/post/how-to-validate-a-startup-idea-before-you-waste-months-building-the-wrong-thing-feb0bf4f9c](https://www.indiehackers.com/post/how-to-validate-a-startup-idea-before-you-waste-months-building-the-wrong-thing-feb0bf4f9c)  
+29. How To Validate Your Startup Idea In 6 Weeks? \- MentorCruise, дата последнего обращения: июня 4, 2026, [https://mentorcruise.com/blog/how-to-validate-your-startup-idea-in-6-weeks-9ae34/](https://mentorcruise.com/blog/how-to-validate-your-startup-idea-in-6-weeks-9ae34/)
\ No newline at end of file
diff --git a/docs/projects/2604-typography-ux/TASK-TRACKER.md b/docs/projects/2604-typography-ux/TASK-TRACKER.md
new file mode 100644
index 000000000..3a3590deb
--- /dev/null
+++ b/docs/projects/2604-typography-ux/TASK-TRACKER.md
@@ -0,0 +1,29 @@
+# Task Tracker — 2604 Typography & UX
+
+**Last Updated**: 2026-05-20
+**Status legend**: Planned | In progress | Done | Paused | Dropped
+
+---
+
+## Open Site-Level Typography/UX Backlog
+
+| Priority | Task | Status | Notes |
+|---|---|---|---|
+| P2 | Site-level: investigate blog article column max-width (684px → wider?) | Planned | The 684px article column constraint on blog/course pages forces Mermaid LR diagrams ≥5 nodes to fail, SVG-with-prose-text to clip, 5-col tables to overflow on 390px mobile. Investigation: is the 684px max-width a deliberate readability choice (Bringhurst-style 45-75 char line length) or a vestigial theme value? Compare with thoughtbot, Stripe Press, Indie Hackers content widths. Decide: keep 684px (and design content within budget) OR widen to 720-800px (and adapt visual breaks to use more horizontal space). Surfaced 2026-05-20 during course-polish marathon — multiple visual breaks had to be reshaped/dropped because of width constraints. Per memory `feedback_684px_column_visual_constraints.md`. |
+
+---
+
+## Closed (historical findings)
+
+Project produced rich findings docs (cross-page consistency, mobile UX, competitor benchmark, sprint 3-6 reports) but no canonical tracker before now. See `findings-*.md` files in this directory for prior work.
+
+---
+
+## Related references
+
+- `findings-cross-page-consistency.md` — cross-page typography audit
+- `findings-mobile-ux.md` — mobile UX issues
+- `findings-competitor-benchmark.md` — competitor comparison
+- `findings-2026-04-30.md` — typography findings snapshot
+- Memory: `feedback_684px_column_visual_constraints.md` — the constraint that surfaced this task
+- Memory: `feedback_course_work_scope_discipline.md` — why this task stayed deferred during course work
diff --git a/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.01-course-program-landscape.md b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.01-course-program-landscape.md
new file mode 100644
index 000000000..d6c01cd32
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.01-course-program-landscape.md
@@ -0,0 +1,224 @@
+# Course & Program Landscape - Tech for Non-Technical Founders (2026)
+
+**Created**: 2026-05-12
+**Project**: 2605-tech-for-non-technical-founders
+**Researcher**: Phase 1 agent run
+**Sources**: 27 unique URLs cited inline
+
+---
+
+## 1. Executive Summary
+
+The 2026 market sells founders two things: how to BUILD without engineers (no-code, vibe coding, AI bootcamps), and how to RUN a company (YC, Techstars, Founder Institute, Reforge). Almost nobody sells the in-between layer JT's ICP-E cares about: how to manage developers you have already hired, verify their work, and keep ownership of your code. Vibecode bootcamps assume the founder is solo. Accelerators assume you have a technical co-founder. Reforge assumes you are a PM who already speaks engineering. Section, Maven, and Coursera offer general AI-fluency content for managers, not founder-specific oversight playbooks. The closest match in the market - "Don't Hire a Software Developer Until You Read This Book" by K.N. Kukoyi - was last updated in 2017 and pre-dates the AI code era entirely. JT can own the gap by publishing a free, opinionated, founder-only curriculum on control before rescue: GitHub/AWS ownership audits, Friday demo protocols, plain-English code health reports, salvage-vs-rebuild decisions, and the AI-era topics (token bills, slopsquatting, agent safety) that no founder-targeted program teaches today.
+
+---
+
+## 2. Program Inventory
+
+15 programs catalogued. Stale or absent items left out rather than padded.
+
+| # | Name | Provider | Format | Duration | Price | Top curriculum modules | Stated audience | Latest update | URL |
+|---|------|----------|--------|----------|-------|------------------------|-----------------|---------------|-----|
+| 1 | Startup School | Y Combinator | Self-paced + weekly check-ins | 7 weeks | Free | Idea validation, MVP, talking to users, weekly metrics, fundraising | Aspiring + early founders | 2026 | [startupschool.org](https://www.startupschool.org/) [events.ycombinator.com](https://events.ycombinator.com/startup-school-2026) |
+| 2 | YC Startup Library | Y Combinator | Free essay + video library | Self-serve | Free | "How to Find a Technical Co-Founder," "Series A Diligence Checklist," co-founder matching guide | Founders | 2026 | [ycombinator.com/library](https://www.ycombinator.com/library) [ycombinator.com/library/3h-series-a-diligence-checklist](https://www.ycombinator.com/library/3h-series-a-diligence-checklist) |
+| 3 | Founder Catalyst Global | Techstars | Cohort, virtual | 10 weeks | Free, no equity | Masterclasses, fireside chats, weekly pitch coaching, partner sessions | Pre-accelerator early founders | Spring 2026 | [techstars.com](https://www.techstars.com/techstars-founder-catalyst-global-spring-2026-program) |
+| 4 | Founder Institute Core | Founder Institute | Cohort, hybrid | 14 weeks | Tuition + equity warrants | Team analysis, product roadmap, investor pitch, cap table, legal/IP, financials | Pre-seed founders | 2026 | [fi.co/program](https://fi.co/program) [fi.co/curriculum](https://fi.co/curriculum) |
+| 5 | Vibecode a Product Bootcamp | Founder Institute | Cohort + self-paced | 10 days | $449 | Scoping spec, AI-toolkit setup (Replit, n8n, OpenAI), prompt translation, customer launch | Solo non-technical founders | June 2026 | [fi.co/bootcamp/vibecoding](https://fi.co/bootcamp/vibecoding) |
+| 6 | Antler Residency | Antler | Cohort, in-person | 6-8 weeks | Equity, $250-500K offered at demo day | Self-directed; team formation, GTM, fundraising | Commercial / domain / technical founders | 2026 | [antler.co/residency](https://www.antler.co/residency) |
+| 7 | Reforge (membership) | Reforge | Self-paced + live courses | Annual | $2,000/yr individual; $9,995/yr team (10 seats) | Engineering Leadership, Mastering Product Delivery, AI Growth, product/growth catalog | PMs, growth, eng leaders | 2026 | [reforge.com/pricing](https://www.reforge.com/pricing) [reforge.com/courses](https://www.reforge.com/courses) |
+| 8 | Section (membership) | Section | Live cohort sprints | 2-3 weeks per course | $995/yr; $600 5-day crash course | Product positioning, brand, data & analytics, 50+ AI courses for leaders | Mid-career managers | 2024-2026 | [poetsandquantsforexecs.com](https://poetsandquantsforexecs.com/news/section4-rebrands-to-section-launches-new-certificates-for-business-professionals/) [businesswire.com](https://www.businesswire.com/news/home/20230919273825/en/Section-Launches-Industry-Leading-AI-Curriculum-to-Build-the-New-AI-Class-of-Knowledge-Workers) |
+| 9 | Cursor AI Bootcamp: Build Anything Instantly | Maven (Matt Schlicht) | Cohort, live | 3 weeks (2x/wk live) | $750 | Setup, basics, user accounts, database, API integration, debugging | Non-technical founders, PMs | Latest cohort Feb 2025 | [maven.com](https://maven.com/matt-schlicht/build-anything-with-ai) |
+| 10 | The Vibe Coding Bootcamp: Become an AI-Augmented Developer | Zero To Mastery | Self-paced | 18 hours, 158+ lessons | $299 lifetime / $25/mo | Vibe coding, choosing AI partner, Cursor/Copilot, MCP, agent mode, AI gauntlet evaluation, security/proxy | Beginners and devs | 2026 | [zerotomastery.io](https://zerotomastery.io/courses/learn-vibe-coding/) |
+| 11 | Tech for Non-Techies (membership + classes) | Tech For Non-Techies | Live + on-demand | Single-day to multi-week | $28 single class to membership | 5 tech concepts, product management, front-end vs back-end, UX, analytics | Non-technical founders, business leaders | 2026 | [techfornontechies.co](https://www.techfornontechies.co/) [techfornontechies.co/founders-class](https://www.techfornontechies.co/founders-class-september-22) |
+| 12 | How Non-Technical Founders Build Startups | Udemy (Sramana Mitra) | Self-paced video | Multi-section | Udemy listed price | Idea, business model, customers, fundraising | Non-technical founders | Listed 2024-2026 | [udemy.com](https://www.udemy.com/course/nontechnicalfounderstartups/) |
+| 13 | Tech Startup Management for CEOs | Udemy | Self-paced video | Free tutorial | Free | CTO-style management basics, scaling tech, leadership | CEO/founder | Listed | [udemy.com](https://www.udemy.com/course/tech-startup-management-for-ceos-from-zero-to-million-users/) |
+| 14 | 100 Days of No Code / 100 Days of AI | 100 School (Max Haining) | Self-paced + cohort | 100 daily lessons / 25-day bootcamp | Free daily lessons + paid bootcamps | No-code build, AI tools, GPT, MVP launch | Non-technical builders | 2026 | [100school.com](https://www.100school.com/) [100daysai.com](https://www.100daysai.com/) |
+| 15 | Don't Hire a Software Developer Until You Read This Book | K.N. Kukoyi (self-published) | Book + audiobook | ~250 pages | $9-25 | Market research, validating idea, app types, picking languages, finding/interviewing developers, prototyping, customer testing | Non-technical founders | 2017 | [amazon.com](https://www.amazon.com/Dont-Hire-Software-Developer-Until-ebook/dp/B01LY5C1IK) |
+| 16 | Tech Founder Essentials | techfounder.ceo | Self-paced + live | 40 hours | Listed on site | Apps, DevOps, cybersecurity, communication, leadership | MCA students, aspiring tech founders | 2026 | [techfounder.ceo](https://www.techfounder.ceo/) |
+| 17 | Coding for Entrepreneurs | YouTube (free) | YouTube videos | Self-paced | Free | Django, Python, APIs, payments, frameworks | Non-technical founders learning to code | Active 2026 | [youtube.com/@CodingEntrepreneurs](https://www.youtube.com/channel/UCWEHue8kksIaktO8KTTN_zg) |
+| 18 | WeAreNoCode | WeAreNoCode | Cohort + self-paced | 3 months | <$1,000 | Idea-to-MVP with Lovable + AI tools, validation, first paying customers | Non-technical founders | 2026 | [wearenocode.com](https://www.wearenocode.com/) |
+| 19 | 5-Day AI Agents Intensive (Vibe Coding) | Google + Kaggle | Free intensive | 5 days | Free | AI agents, vibe coding production patterns, capstone | Devs + builders | June 2026 | [blog.google](https://blog.google/innovation-and-ai/technology/developers-tools/kaggle-genai-intensive-course-vibe-coding-june-2026/) |
+
+Excluded: On Deck No-Code Fellowship (no live 2026 cohort surfaced), Akimbo / altMBA (sunsetted 2024 per [akimbo.com/about](https://www.akimbo.com/about)), 500 Global Flagship (no dedicated non-technical-founder oversight track in current public materials at [500.co/founders](https://500.co/founders)).
+
+---
+
+## 3. Curriculum Coverage Matrix
+
+Rows are the topics ICP-E founders need (drawn from `90.10-icp-primary-website-target.md` pains and the `proof-signal-portfolio.md` signal bank). Columns are program clusters. "Yes" = explicitly taught. "Light" = mentioned but not the focus. "No" = absent in public curriculum.
+
+| Topic | YC SS + Library | Techstars + FI Core | Reforge / Section | Vibecode bootcamps (FI, Maven, ZTM) | Tech for Non-Techies | "Don't Hire" book | No-code (WeAreNoCode, 100 Days) |
+|-------|-----------------|---------------------|-------------------|--------------------------------------|----------------------|--------------------|----------------------------------|
+| Reading a sprint board / Jira progress | No | Light | Light | No | No | Light | No |
+| Evaluating code quality without coding | No | No | No | Light (ZTM gauntlet only) | No | Yes | No |
+| GitHub/AWS access ownership audit | No | Light (cap table, IP) | No | No | No | No | No |
+| Salvage vs rebuild decision | No | No | No | No | No | No | No |
+| AI code review for non-coders | No | No | Light (Section AI mgr) | Light (ZTM only) | Light (AI training) | No | No |
+| Reading a SOW / dev contract | No | Light (legal module) | No | No | No | Yes | No |
+| Hiring fractional CTO | No | Light | No | No | No | Yes (interview) | No |
+| Demoing vs Jira ticket status (Friday demo rule) | No | No | No | No | No | No | No |
+| Technical due diligence (Series A) | Yes (one essay) | Light | No | No | No | No | No |
+| Contract clauses for code ownership | No | Light (IP) | No | No | No | Yes | No |
+| Spotting over-engineering | No | No | Light (Mastering Product Delivery) | No | No | No | No |
+| When to fire a devshop | No | No | No | No | No | Light | No |
+| Plain-English weekly progress reports | No | No | No | No | No | No | No |
+| Termination clause / exit strategy in contract | No | No | No | No | No | Light | No |
+| AI token bill cost management | No | No | Light | No | No | No | No |
+| Slopsquatting / supply chain in AI code | No | No | No | No | No | No | No |
+| AI agent safety guardrails | No | No | No | No | No | No | No |
+| Vibe-coding shop evaluation (specific 2026 risk) | No | No | No | Light (ZTM, ethical use) | No | No | No |
+| Job stories vs user stories for non-tech founders | No | Light (FI product roadmap) | Light (Reforge product mgmt) | No | No | Light | No |
+| Cap-table math turning slip into runway $ / days | Light (YC essays) | Yes (FI cap table module) | No | No | No | No | No |
+
+Topics covered by zero or one program (blue ocean for JT):
+- GitHub/AWS access ownership audit (zero)
+- Salvage vs rebuild decision (zero)
+- Demoing vs Jira / Friday demo rule (zero)
+- Plain-English weekly progress reports (zero)
+- Slopsquatting in vibe-coding shops (zero)
+- AI agent safety guardrails for founders who hired the agency, not built the agent (zero)
+- AI token bill pass-through cost (one - Reforge AI Growth, but framed as growth not cost-control)
+- Termination clause language (one - Kukoyi 2017 only)
+- Vibe-coding shop evaluation from the buyer side (zero - all current courses teach the founder how to vibe-code, not how to audit the shop that did)
+
+---
+
+## 4. Gaps & White Space
+
+### A. ICP-E pains uncovered by any current program
+From the 15 ICP-E pains in `90.10-icp-primary-website-target.md`:
+
+- Pain #2 "Cannot evaluate code quality": only Kukoyi 2017 attempts this, and it predates GitHub Copilot, Cursor, and Lovable. Every current bootcamp teaches founders to GENERATE AI code, none teach them to AUDIT code their hired team produced.
+- Pain #3 "Zero transparency / understandable reports": no program teaches founders how a weekly engineering report should read, how to demand one, or how to spot a fake one.
+- Pain #11 "Information asymmetry / Docker/refactoring jargon": Tech for Non-Techies covers tech literacy, but stops at definitions. Nobody publishes a "BS-detection question script" the founder runs in standup.
+- Pain #12 "Progress mirage / Jira full but no working product": zero coverage. The Friday Demo Rule is unowned in the market.
+- Pain #13 "No admin control / repo and AWS under vendor account": zero coverage. The closest item is Founder Institute's IP/legal module, which addresses ownership in writing, not ownership in cloud.
+- Pain #14 "Over-engineered MVP": Reforge "Mastering Product Delivery" addresses this for engineering leaders, never for the non-technical buyer hiring the agency.
+- Pain #15 "Cheap talent trap / freelancer hits ceiling": no program teaches the diagnostic for when to bring in a fractional CTO to guard the cheap talent.
+
+### B. JT white-space features no program teaches
+
+From `90.10` §8b - none of the 19 programs above teach any of:
+- Plain-English weekly reports
+- Code ownership guarantee in the contract (Kukoyi mentions briefly; nobody teaches the contract clause)
+- Termination clause for quality (Kukoyi mentions briefly)
+- Non-technical QA reports
+- Rescue specialization (zero coverage anywhere)
+- Dedicated non-technical contact protocol
+
+This is the strongest finding: the JT differentiators are not just unowned by competitor agencies. They are unowned by the entire educational market.
+
+### C. Control-before-rescue topics that are uniquely JT
+
+Friday demos, GitHub ownership audits, salvage/rebuild decisions, fractional CTO guardrails, job stories vs user stories, BS-detection question scripts. The closest neighbor is YC's "How to Find a Technical Co-Founder" essay, which is hiring-stage advice, not active-management advice. JT can build a 12-16 post curriculum on this layer alone.
+
+### D. AI-era topics absent from current curricula
+
+- AI token bills: Reforge's AI Growth course covers AI from a growth angle, not cost. No founder course teaches "your dev shop is passing through OpenAI / Claude API costs and you don't know it."
+- Slopsquatting / hallucinated package supply chain: an active 2025-2026 attack vector ([Infosecurity Magazine](https://www.infosecurity-magazine.com/news/ai-hallucinations-slopsquatting/), [SecurityWeek](https://www.securityweek.com/ai-coding-agents-could-fuel-next-supply-chain-crisis/), [CSO Online](https://www.csoonline.com/article/4167465/supply-chain-attacks-take-aim-at-your-ai-coding-agents.html)). Snyk's audit found 13.4% of agent skills had critical security issues. No founder-targeted program covers this.
+- AI agent safety from the BUYER side: courses like Proofpoint Certified AI Agent Security Specialist target SOC engineers. The founder who hired a vibe-coding agency has nowhere to learn "what should I ask about agent permissions before this gets shipped to production."
+- "We use AI" follow-up questions: when an agency claims AI proficiency, the founder has no script to verify it. This is already on the JT content plan (NEW-E) but absent from the broader market.
+
+---
+
+## 5. Voice & Format Intelligence
+
+### How programs talk to founders about tech
+
+Three voices dominate. None match JT's empathy-first founder-to-founder tone.
+
+Verbatim quotes:
+
+1. Tech For Non-Techies, on the founder's job: *"A non-technical founder's job is not to learn to code, but to successfully manage the technology production process, understanding technology workflows and learning how to collaborate with designers and developers."* ([techfornontechies.co](https://www.techfornontechies.co/)) - definitional and vague. No specific failure mechanic, no script.
+
+2. Lovable comparison content: *"If you're a non-technical founder validating an idea, Lovable is probably where you start, but don't ship to production without having someone review the code, and plan to graduate to Cursor once the idea is validated."* ([lovable.dev](https://lovable.dev/guides/cursor-vs-bolt-vs-lovable-comparison)) - tool-evangelist voice, hand-waves the actual review the founder needs to commission.
+
+3. HyperNest Labs technical due diligence guide: *"Technical issues discovered during due diligence can reduce your startup's valuation by up to 20%, and nearly 60% of investment deals fall through due to problems uncovered in the technical review."* ([hypernestlabs.com](https://hypernestlabs.com/guides/technical-due-diligence-checklist)) - investor-facing scare-stat voice, optimised to sell a paid TDD audit.
+
+JT's opportunity: write like a founder who has shipped this stuff and now translates it. Specific failure mechanics ("the AWS root account is in their Gmail"), exact scripts ("ask for a Loom of the staging URL every Friday at 4pm"), and named trade-offs ("Lovable to MVP is fine; do not let the same shop run the production refactor without a senior review gate").
+
+### Format intelligence
+
+- Cohort + Slack works for paid programs ($449-$2,000) but excludes self-serve readers searching Google.
+- Free + self-paced wins for top-of-funnel: YC Startup School and YC Library are the dominant brands precisely because they are free, indexable, and gated only by attention.
+- Books still convert: Kukoyi's 2017 book is the most-cited educational resource for "non-technical founder hire developer" searches, despite being eight years out of date. There is room for a free 2026 equivalent.
+- Video + worksheet beats video alone. The Vibecode FI bootcamp pairs every live session with self-paced sprints; ZTM courses ship downloadable scorecards. JT posts should ship downloadable artifacts (Friday demo template, GitHub ownership checklist, salvage-vs-rebuild decision tree, AI follow-up question script). Several of these are already named offers in `90.10` §9.
+
+### Pricing benchmarks
+
+- Free: YC Startup School, YC Library, Techstars Founder Catalyst, Coding for Entrepreneurs YouTube, 100 School daily lessons, Google + Kaggle Vibe Coding intensive.
+- Low ($28-$449): Tech for Non-Techies single class ($28), Vibecode FI bootcamp ($449), ZTM Vibe Coding Bootcamp ($299).
+- Mid ($600-$995): Section 5-day crash ($600), Section annual ($995), Maven Cursor bootcamp ($750), WeAreNoCode 3-month (<$1,000).
+- High ($1,000-$10,000+): Reforge individual ($2,000/yr), Reforge teams ($9,995/yr for 10 seats), Founder Institute (tuition + equity warrants).
+- Equity: Antler ($250-500K invested for equity), Founder Institute (warrants).
+
+### Average length of a "complete" program
+
+Cohort programs cluster at 6-14 weeks (Antler 6-8, YC Startup School 7, Founder Catalyst 10, Vibecode 10 days but most others 8-14 weeks). Self-paced video courses cluster at 18-40 hours. A free competing JT curriculum needs roughly 12-16 posts at 1,000-1,500 words each to land in the same time-investment range as YC Startup School (~10-15 hours of reading).
+
+---
+
+## 6. Proposed JT Content Series Spine
+
+A 14-post free curriculum, sequenced foundation -> control -> rescue -> AI era. Each post slots a distinct proof signal from `proof-signal-portfolio.md`. Where the signal is already owned by an existing JT post, the new post extends the signal into a deeper sub-topic (noted).
+
+| # | Working title | Section | Gap it fills | JT white-space feature | Proof-signal anchor (distinct) |
+|---|---------------|---------|--------------|------------------------|--------------------------------|
+| 1 | Five tech words to stop nodding at | Foundation | Tech literacy without bootcamp time-sink | Plain-English translation | Plain-English jargon test (extends scipab post; this one tests 5 specific words: "refactoring," "Docker," "tech debt," "MVP," "architecture") |
+| 2 | The org chart your dev shop won't draw for you | Foundation | None of the 19 programs explain who-does-what in a typical 5-person engineering team | Dedicated non-technical contact | On-call rotation visibility (unused; from portfolio bank) |
+| 3 | Reading the SOW your agency just sent (clause by clause) | Foundation | Kukoyi 2017 covers contract briefly; no current program walks the SOW | Code ownership guarantee | Dev shop red flags checklist contract section (extends `dev-shop-red-flags-checklist`) |
+| 4 | The one Friday ritual that catches fake progress | Control | Zero coverage anywhere | Plain-English weekly reports | Staging URL / clickable demo (already owned; reaffirm + new sub-angle: time-of-day script) |
+| 5 | Who owns your GitHub, AWS, and database (and how to take them back) | Control | Zero coverage anywhere | Code ownership guarantee | Documentation freshness (unused; check who edited `README.md` last) |
+| 6 | Three questions that turn a 30-minute standup into proof | Control | Zero coverage anywhere | Non-technical QA reports | Pull-request size + reviewer distribution (unused; from portfolio bank) |
+| 7 | The plain-English code health report you should be getting weekly | Control | Plain-English reports unowned | Plain-English weekly reports | Weekly report from team (already owned; extend with template) |
+| 8 | When the freelancer hits the ceiling: spotting the moment to bring in fractional CTO oversight | Control | Cheap talent trap unowned | Termination clause | Cloud bill week-over-week (unused; from portfolio bank) |
+| 9 | You asked for an admin panel; you got a spaceship. How to specify in Job Stories instead of features | Control | Over-engineered MVP unowned | Non-technical QA reports | File-touch count for small change (already owned; reuse to show over-engineering) |
+| 10 | Salvage or rebuild: a 6-question decision tree | Rescue | Zero coverage anywhere | Rescue specialization | Test coverage % + commit size (already owned; reuse for salvage triage) |
+| 11 | How to fire your dev shop without losing the codebase | Rescue | Kukoyi mentions; no current program | Termination clause | Customer support tickets tagged to build (unused; from portfolio bank) |
+| 12 | "We use AI" - five follow-up questions that catch theatre | AI era | Zero coverage anywhere | Plain-English QA reports | Generate-validate-kill workflow cost math (already owned in `vibe-coding-disposable-by-design`; extend to agency interview) |
+| 13 | The AI token bill your agency forgot to mention | AI era | One competitor; founder-cost angle unowned | Plain-English weekly reports | Cap-table math (already owned; extend to OpenAI/Claude pass-through cost) |
+| 14 | Slopsquatting and the hallucinated package: what your shop must do before merge | AI era | Zero coverage in founder-targeted curricula | Code ownership guarantee | Dependency upgrade cadence (unused; from portfolio bank - perfect fit for slopsquatting) |
+
+Sequencing rationale: 1-3 anchor in vocabulary and contract literacy. 4-9 are the "control before rescue" wedge nobody owns. 10-11 sharpen existing rescue territory into decision-tree formats. 12-14 cover 2026 AI urgency in three distinct angles (audit, cost, security) so the cluster does not collapse into one repeated AI argument.
+
+Posts 4, 5, 8, 9, 10 overlap NEW-J/K/L/I/M slugs already in `20.07` content plan. Integrate, do not duplicate.
+
+---
+
+## 7. Citations
+
+1. [Y Combinator Startup School](https://www.startupschool.org/)
+2. [Startup School 2026 event page](https://events.ycombinator.com/startup-school-2026)
+3. [YC Startup Library](https://www.ycombinator.com/library)
+4. [YC Series A diligence checklist](https://www.ycombinator.com/library/3h-series-a-diligence-checklist)
+5. [YC How to Find a Technical Co-Founder](https://www.ycombinator.com/library/3i-how-to-find-a-technical-co-founder)
+6. [Techstars Founder Catalyst Spring 2026](https://www.techstars.com/techstars-founder-catalyst-global-spring-2026-program)
+7. [Techstars Spring 2026 cohort announcement](https://www.techstars.com/blog/program-news/techstars-spring-2026-founder-catalyst-global-cohort)
+8. [Founder Institute Core Program](https://fi.co/program)
+9. [Founder Institute curriculum](https://fi.co/curriculum)
+10. [Founder Institute Vibecode Bootcamp](https://fi.co/bootcamp/vibecoding)
+11. [Antler Residency](https://www.antler.co/residency)
+12. [Reforge pricing](https://www.reforge.com/pricing)
+13. [Reforge courses catalog](https://www.reforge.com/courses)
+14. [Section / Section4 rebrand and pricing](https://poetsandquantsforexecs.com/news/section4-rebrands-to-section-launches-new-certificates-for-business-professionals/)
+15. [Section AI curriculum launch](https://www.businesswire.com/news/home/20230919273825/en/Section-Launches-Industry-Leading-AI-Curriculum-to-Build-the-New-AI-Class-of-Knowledge-Workers)
+16. [Maven - Cursor AI Bootcamp by Matt Schlicht](https://maven.com/matt-schlicht/build-anything-with-ai)
+17. [Zero To Mastery - Vibe Coding Bootcamp](https://zerotomastery.io/courses/learn-vibe-coding/)
+18. [Tech For Non-Techies homepage](https://www.techfornontechies.co/)
+19. [Tech For Non-Techies founders class](https://www.techfornontechies.co/founders-class-september-22)
+20. [Udemy - How Non-Technical Founders Build Startups](https://www.udemy.com/course/nontechnicalfounderstartups/)
+21. [Udemy - Tech Startup Management for CEOs](https://www.udemy.com/course/tech-startup-management-for-ceos-from-zero-to-million-users/)
+22. [100 School](https://www.100school.com/)
+23. [100 Days of AI](https://www.100daysai.com/)
+24. [Don't Hire a Software Developer Until You Read This Book - Amazon](https://www.amazon.com/Dont-Hire-Software-Developer-Until-ebook/dp/B01LY5C1IK)
+25. [WeAreNoCode](https://www.wearenocode.com/)
+26. [Coding for Entrepreneurs YouTube channel](https://www.youtube.com/channel/UCWEHue8kksIaktO8KTTN_zg)
+27. [Google + Kaggle 5-Day AI Agents Vibe Coding course](https://blog.google/innovation-and-ai/technology/developers-tools/kaggle-genai-intensive-course-vibe-coding-june-2026/)
+28. [Lovable - Cursor vs Bolt vs Lovable comparison](https://lovable.dev/guides/cursor-vs-bolt-vs-lovable-comparison)
+29. [HyperNest Labs - Technical Due Diligence Checklist](https://hypernestlabs.com/guides/technical-due-diligence-checklist)
+30. [Infosecurity Magazine - AI Hallucinations Slopsquatting](https://www.infosecurity-magazine.com/news/ai-hallucinations-slopsquatting/)
+31. [SecurityWeek - AI Coding Agents Supply Chain Crisis](https://www.securityweek.com/ai-coding-agents-could-fuel-next-supply-chain-crisis/)
+32. [CSO Online - Supply chain attacks on AI coding agents](https://www.csoonline.com/article/4167465/supply-chain-attacks-take-aim-at-your-ai-coding-agents.html)
+33. [Snyk ToxicSkills audit](https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/)
+34. [Akimbo / altMBA sunset note](https://www.akimbo.com/about)
+35. [500 Global founder programs](https://500.co/founders)
diff --git a/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.02-curriculum-sequence-synthesis.md b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.02-curriculum-sequence-synthesis.md
new file mode 100644
index 000000000..4c664d70e
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.02-curriculum-sequence-synthesis.md
@@ -0,0 +1,257 @@
+# Curriculum Sequence Synthesis - The 2026 Non-Tech Founder's Decision Tree
+
+**Project**: 2605-tech-for-non-technical-founders
+**Created**: 2026-05-12
+**Status**: 🟡 Proposal awaiting confirmation - do not change existing artifacts until reviewed
+**Author**: re-review pass after user re-framed the project goal mid-session
+
+---
+
+## What changed
+
+The user re-framed the project on 2026-05-12 (mid-session):
+
+> Help non-tech founders deliver MVP in a **self-serve way**. **Definitely avoid hiring as much as possible.** If hiring becomes required, then help them understand whom to hire and how to manage.
+
+That is a different center of gravity than the original 2605 brief, which assumed the founder had already hired and needed help managing the team they had. The original brief built a 14-post curriculum mostly about post-hire oversight (Friday demos, GitHub ownership, SOW reading, salvage decisions). The re-frame puts the **pre-hire decision** at the start of the journey and treats hiring as a fallback, not the default.
+
+User also dropped a third research document: `10.03-2026-ecosystem-research-ru-source.md` (the "2026 ecosystem" report; Russian-language source, originally titled `Курс для нетехнических основателей 2026.md`). This synthesis combines that with the two prior inputs we already had.
+
+---
+
+## The three research inputs side by side
+
+| Input | Center of gravity | What it teaches | Key voices |
+|---|---|---|---|
+| **My original landscape (`10.01`)** | Post-hire oversight | 19 paid/free programs mapped; JT's white space identified as "control before rescue" (Friday demos, ownership audits, salvage decisions) | Y Combinator essays, Founder Institute, Reforge, Kukoyi 2017 book |
+| **Older client research (`Управление разработкой...`)** | Diagnosing and reversing control loss | 5 control-loss patterns (Hire-and-Forget, Black Box, Hostage Situation, Progress Mirage, Tech Debt); Job Stories vs User Stories; Shape Up "Appetite" instead of estimates; Fractional CTO as the antidote to the co-founder paralysis | Anonymized rescue cases, Basecamp Shape Up, Christensen JTBD |
+| **NEW 2026 ecosystem (`10.03-2026-ecosystem-research-ru-source.md`, RU)** | **Self-serve MVP is now viable**; hiring is the fallback, not the default | The "Vibe Coding" inflection point (Lovable + Supabase + Stripe + GitHub); two dominant philosophies: Strategic (Sophia Matveeva) vs Independent AI Prototyping (Drew Falkman, Founder Institute Vibecode); the AI-Augmented Developer job profile ($85-120K Junior with Senior productivity); offshore arbitrage to Tier-2 cities ($15-70/hr); High-Signal communities (Lovable Discord 160K, Indie Hackers, NCF) | Rob Walling (the "shed not skyscraper" warning), Y Combinator's 2026 manifestos, Sophia Matveeva, Drew Falkman |
+
+**Convergence point**: all three research inputs agree the **non-tech founder of 2026 has more options than the founder of 2017**. The Kukoyi 2017 book is stale precisely because it assumed the founder had to hire to ship. Today that assumption is wrong on the first lap of the decision tree.
+
+**Divergence point**: my original `10.01` landscape under-weighted the self-serve path because it anchored on ICP-E (the burned-by-devshop founder). That ICP is real and JT's existing client base reflects it, but the curriculum's audience is **broader**: it should catch founders BEFORE they make the mistake that lands them in ICP-E, not only after.
+
+---
+
+## The 2026 founder's decision tree (the synthesis)
+
+A founder reading the JT curriculum should be able to find their current stage and read forward from there. Five stages, in order:
+
+```
+                    ┌──────────────────────────────────────┐
+                    │  STAGE 1: Should I hire at all?      │
+                    │  - The Airbnb test (validate w/o code)│
+                    │  - The Vibe Coding stack (Lovable +   │
+                    │    Supabase + Stripe) for solo MVP    │
+                    │  - When self-serve hits the ceiling   │
+                    └──────────┬───────────────────────────┘
+                               │
+                  ┌────────────┴────────────┐
+                  │ YES, I need real        │
+                  │ engineering capacity    │
+                  ▼                         │ NO, I can ship self-serve
+   ┌──────────────────────────────┐         │ → READER LEAVES CURRICULUM
+   │ STAGE 2: Hire smart          │         │   (and we don't try to sell them
+   │ - The AI-Augmented Dev       │         │    engineering services)
+   │   profile (NOT generalist)   │         │
+   │ - Where (onshore / nearshore │
+   │   / Tier-2 offshore)         │
+   │ - The 7-question interview   │
+   │   that catches AI theater    │
+   │ - The Fractional CTO bridge  │
+   └──────────┬───────────────────┘
+              │
+              ▼
+   ┌──────────────────────────────┐
+   │ STAGE 3: Manage what you     │
+   │ hired (CURRENT CURRICULUM)   │
+   │ - Vocabulary literacy        │
+   │ - The real org chart         │
+   │ - SOW clause by clause       │
+   │ - Friday demo + standup Qs   │
+   │ - GitHub/AWS ownership audit │
+   │ - Weekly plain-English report│
+   │ - Spotting over-engineering  │
+   └──────────┬───────────────────┘
+              │
+              ▼
+   ┌──────────────────────────────┐
+   │ STAGE 4: When it breaks      │
+   │ - Salvage vs rebuild         │
+   │ - Switch dev shops safely    │
+   └──────────┬───────────────────┘
+              │
+              ▼
+   ┌──────────────────────────────┐
+   │ STAGE 5: AI-era specifics    │
+   │ - "We use AI" follow-ups     │
+   │ - The AI token bill          │
+   │ - Slopsquatting              │
+   └──────────────────────────────┘
+```
+
+Stage 1 is **the new starting point.** Most curricula competing with us (YC Startup School, Founder Institute, Sophia Matveeva, Drew Falkman, Kukoyi 2017) start somewhere on this tree but none of them frame the full decision sequence. JT's wedge: **the full sequence in one free curriculum, with the courage to tell readers "don't hire" when that's the right answer.**
+
+---
+
+## Proposed curriculum re-sequence
+
+Old structure (14 posts, 4 pillars):
+- Foundation (3) + Control (6) + Rescue (2) + AI Era (3) = 14
+- All assume hiring has happened
+
+New structure (~20 posts, 5 pillars):
+
+### Pillar 1 - Self-Serve First (new, 3-5 posts)
+
+Founder asks: do I need to hire anyone at all?
+
+| Post | Topic | Anchor |
+|---|---|---|
+| 1.1 | The 2026 build/buy/wait decision tree | YC "validate without code" + Airbnb analogy; Rob Walling's "shed vs skyscraper" warning |
+| 1.2 | The self-serve stack that ships in 2026 | Lovable + Supabase + Stripe + GitHub walkthrough; what each one does in plain English |
+| 1.3 | Vibe Coding done right (and the architectural ceiling that breaks it) | Drew Falkman's "Vibe PRD" + Rob Walling's "shed" metaphor; signals you've hit the ceiling |
+| 1.4 (optional) | The communities that punch above their weight | Lovable Discord (160K), Indie Hackers, No Code Founders - free knowledge, no agency tax |
+| 1.5 (optional) | The Fractional CTO bridge - 5 hours a week beats a co-founder | From the Russian client research; the "$0 equity, $400/week" alternative |
+
+### Pillar 2 - If you must hire, hire smart (new, 3-4 posts)
+
+Founder asks: I've hit self-serve ceiling. Who do I hire? Where?
+
+| Post | Topic | Anchor |
+|---|---|---|
+| 2.1 | The AI-Augmented Developer profile (NOT generalist junior, NOT Toptal Senior) | New research salary data; the "directs AI, owns systems" job description |
+| 2.2 | Where in the world to hire in 2026 (onshore vs nearshore vs Tier-2 offshore) | $15-70/hr Tier-2 Indian cities, LATAM nearshore, etc. |
+| 2.3 | The 7-question hiring interview (catches AI theater + system-thinking failures) | Existing "We Use AI" 5-question lead magnet + 2 more from new research; rebrand as a hiring tool |
+| 2.4 | The 3 hiring mistakes that still kill MVPs (and why students are the wrong cheap option) | Russian client research; hourly-rate trap, working-student 20-hour cap, no Fractional CTO |
+
+### Pillar 3 - Once you've hired, manage well (CURRENT CURRICULUM, ~7 posts)
+
+Founder asks: team is in place; how do I make sure they ship?
+
+This pillar is **mostly the existing 4 net-new posts + 5 wraps from 2510**:
+
+| Post | Status | Notes |
+|---|---|---|
+| 3.1 Five Tech Words to Stop Nodding At | ✅ shipped | Existing - no rewrite needed, just re-frame as Pillar 3 opener |
+| 3.2 The Org Chart Your Dev Shop Won't Draw | ✅ shipped | Existing - no rewrite |
+| 3.3 Reading the SOW Clause by Clause | ✅ shipped | Existing - no rewrite |
+| 3.4 The Friday Demo Rule | wrap (2510 NEW-J) | Already in 2510 plan |
+| 3.5 Who Owns Your GitHub, AWS, and Database | wrap (2510 NEW-K) | Already in 2510 plan |
+| 3.6 Three Questions That Turn Standup Into Proof | ✅ shipped | Existing - no rewrite |
+| 3.7 The Plain-English Weekly Dev Report | wrap (2510 NEW-A) | Already in 2510 plan |
+| 3.8 You Asked for a Simple Admin Panel; You Got a Spaceship (Job Stories) | wrap (2510 NEW-I) | Already in 2510 plan |
+
+### Pillar 4 - When it breaks (CURRENT, 2 posts)
+
+| Post | Status |
+|---|---|
+| 4.1 Salvage or Rebuild | wrap (2510 NEW-M) - keep |
+| 4.2 How to Switch Dev Shops Safely | wrap (2510 NEW-C) - keep |
+
+### Pillar 5 - AI-era specifics (CURRENT, 3 posts)
+
+| Post | Status |
+|---|---|
+| 5.1 "We Use AI" - Five Follow-Up Questions | wrap (2510 NEW-E) - **dual purpose: hiring interview + agency interview** |
+| 5.2 The AI Token Bill | wrap (2510 NEW-D2) |
+| 5.3 Slopsquatting | wrap (2510 #20) |
+
+### Posts considered for removal or consolidation
+
+The existing curriculum had 9 wraps + 4 net-new + 1 in Control ("When Cheap Developers Get Expensive" / NEW-L). Under the new structure:
+
+- **"When Cheap Developers Get Expensive" (NEW-L)** - belongs in Pillar 2 (hiring mistakes), not Pillar 3 (managing). It's a hiring decision warning, not a managing tactic.
+
+Net effect: the existing 14 posts mostly survive, mostly in Pillar 3. The new structure ADDS 6-9 posts at the front (Pillars 1 and 2) rather than removing existing work.
+
+---
+
+## Mapping existing artifacts to the new structure
+
+| Existing artifact | Current placement | New placement |
+|---|---|---|
+| `friday-demo-template.md` (lead magnet) | Companion to post #4 | Pillar 3 companion - unchanged |
+| `ownership-checklist.md` (lead magnet) | Companion to post #5 | Pillar 3 companion - unchanged |
+| `salvage-vs-rebuild-decision-tree.md` (lead magnet) | Companion to post #10 | Pillar 4 companion - unchanged |
+| `agency-ai-five-questions.md` (lead magnet) | Companion to post #12 (agency interview) | **Repurposed**: companion to BOTH Pillar 2 (hiring interview) and Pillar 5 (agency interview) |
+| `sow-reading-guide.md` (lead magnet) | Companion to post #3 | Pillar 3 companion - unchanged |
+| `five-tech-words-stop-nodding-at` (post 1) | Foundation post 1 | Pillar 3.1 - unchanged content, re-framed in callout |
+| `engineering-org-chart-non-technical-founder` (post 2) | Foundation post 2 | Pillar 3.2 - unchanged content, re-framed |
+| `reading-sow-clause-by-clause` (post 3) | Foundation post 3 | Pillar 3.3 - unchanged content, re-framed |
+| `three-questions-turn-standup-into-proof` (post 6) | Control post 1 | Pillar 3.6 - unchanged content, re-framed |
+
+Net-new posts to draft for the new structure (Pillars 1 and 2): **6 posts total**.
+
+Net-new lead magnets to ship alongside (under the new self-serve framing): **2-3 artifacts**:
+- "Should you hire?" decision-tree artifact
+- "The self-serve stack walkthrough" PDF (Lovable + Supabase + Stripe step-by-step)
+- "Where to hire in 2026" map (onshore / nearshore / Tier-2 offshore comparison)
+
+---
+
+## JT positioning implications (worth your call)
+
+The new framing puts JT in a counter-intuitive position: a Rails dev shop publishing free content that says "try not to hire, including not hiring us." Three honest framings exist; pick one:
+
+| Framing | Says | Trade-off |
+|---|---|---|
+| **A. Trusted advisor first** | "Self-serve when you can. Hire when you must. We'll teach you both, and we hope you call us when you finally need real engineering." | Builds long-term trust. Filters out founders who'd never have been JT clients anyway. Reduces short-term lead volume. |
+| **B. Quality filter** | "Most non-tech founders who hire engineering fail because they hired too early. Read this first; if you still need us, we're the team you call." | Pre-qualifies inbound. Founders who arrive at JT after reading have already self-sorted as "genuinely need engineering." Higher close rate, lower volume. |
+| **C. Stay silent on JT** | "Here's the truth about 2026 non-tech founding. We don't pitch our services in this curriculum at all." | Maximum credibility. Lowest short-term commercial yield. Long-term, builds a content brand independent of JT's sales motion. |
+
+My recommendation: **B (Quality filter)**. It honors the new framing without abandoning JT's business reality. The CTAs stay soft, but the "we exist when you need us" line remains in every Pillar 3-5 post.
+
+---
+
+## The Russian client research adds detail we should not lose
+
+The older client research (`Управление разработкой для нетехнических фаундеров`) supplies specific structural artifacts that should land in the new curriculum:
+
+1. **JTBD Table 1** (5 control-loss situations) - already echoed in the existing curriculum's pain list, but the Job Story format is the better delivery vehicle for Pillar 3 posts.
+2. **Job Stories vs User Stories** (Table 2 in the Russian doc) - this maps to Pillar 3.8 ("Simple Admin Panel" / NEW-I) and deserves more explicit treatment.
+3. **Shape Up's "Appetite" instead of "Estimate"** - belongs in Pillar 3 somewhere (maybe a small new post or absorbed into the Standup Questions post). Currently absent from the curriculum.
+4. **Technical Audit Domains** (Table 3) - 4 domains (Architecture, Security, Testing, DevOps) with specific red flags. Belongs in Pillar 4 (Salvage or Rebuild) as the decision-tree input.
+5. **The "Investor legend" trick for repo transfer** - a tactical move belonging in Pillar 4.2 (Switch Dev Shops Safely). Diplomatic phrasing to extract IP without triggering conflict.
+6. **The "$15K admin panel = spaceship" anecdote** - already echoed in our `asked-simple-admin-panel-built-spaceship` slug (NEW-I). Good alignment.
+
+None of these require new posts; they enrich existing post content.
+
+---
+
+## Recommended next moves (awaiting your confirmation)
+
+1. **Confirm direction**: do we adopt the 5-pillar re-sequence (Self-Serve First → Hire Smart → Manage Well → When It Breaks → AI Era)? If yes, I'll update the curriculum docs in the next pass.
+2. **Confirm positioning**: A, B, or C from the table above?
+3. **Confirm scope**: 6 net-new posts for Pillars 1-2 (total curriculum ~20 posts), or tighter at 3-4 net-new (total ~17-18 posts)?
+4. **Confirm existing posts stay**: I am not proposing to rewrite the 4 net-new posts or the 5 lead magnets already drafted. Their content fits Pillar 3-4-5 naturally; the only change is the curriculum frame (top callout + nav table) updates to show the 5-pillar structure with current post marked `← you are here`.
+5. **Confirm we update the landing page table-of-contents** to reflect the new 5-pillar / ~20-post structure, not the old 4-pillar / 14-post structure.
+
+---
+
+## What I will NOT change before you confirm
+
+- The 4 drafted blog posts (their content is sound; only the curriculum-frame nav table needs updating to the new structure once it's locked).
+- The 5 drafted lead magnets (their content is sound; the `agency-ai-five-questions` magnet gets repurposed for dual use but the content stays).
+- The 2510 parent plan (the LinkedIn validation sprint posts continue as-is; the new structure only changes how 2605 groups them).
+- The `GOAL-AT-A-GLANCE.md` (will be rewritten once you confirm the 5-pillar structure).
+- The `20.01-content-pillars.md` (will be rewritten with 5 pillars instead of 4).
+- The `20.07-content-plan-tnt-founders-2026.md` (will be rewritten with the ~20-post sequence).
+- The `PROJECT-INDEX.md` (the integration rule about "no parallel slugs" stays; the curriculum-frame rule needs the new 20-row nav table).
+
+---
+
+## Source citations from the new 2026 research that justify the re-sequence
+
+| Source | Key claim |
+|---|---|
+| Y Combinator 2026 manifesto (cited in new research) | Tools and business models today let founders turn idea into production-quality product in weeks without equity to a technical co-founder |
+| Rob Walling (Drip / MicroConf / TinySeed founder, cited in new research) | "Vibe coding builds you a shed. Building a multi-story commercial building this way leads to total rewrite from architectural debt" |
+| Drew Falkman (Maven course "Vibe Coding Data-Enabled AI Apps", 4.8/5 rating, cited in new research) | The "Vibe PRD" + Lovable + Supabase + Stripe stack lets non-tech founders ship production MVP solo |
+| Sophia Matveeva ("Tech for Non-Technical Founders" program, HBR + Oxford + LBS, cited in new research) | The founder's job is to define what to build (from customer data); AI or hired engineers define how to build. Validate hypotheses on a spreadsheet first |
+| Founder Institute Vibecode Bootcamp (10-day, $399-$499, launched 2026) | Solo founders run idea → MVP → first customers in 10 days using n8n + OpenAI + Replit + PostgreSQL |
+| Lovable Community (Discord, 160K+ members, cited in new research) | Free community runs offline hackathons globally; replaces the need for early-stage technical co-founder networking |
+| 2026 AI-Augmented Developer salary data (cited in new research) | Junior + AI = Senior productivity at $85-120K. Algorithmic interview questions are obsolete; the new questions are about system thinking and AI direction |
+| Tier-2 offshore arbitrage (cited in new research) | Jaipur, Kochi, Indore, Coimbatore at $15-70/hr. India became the world's 2nd-largest AI talent pool after the US |
+
+These are claims my original `10.01` landscape underweighted. The re-sequence corrects that.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.03-2026-ecosystem-research-ru-source.md b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.03-2026-ecosystem-research-ru-source.md
new file mode 100644
index 000000000..7eff9097a
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.03-2026-ecosystem-research-ru-source.md
@@ -0,0 +1,220 @@
+
+
+# **Комплексное исследование экосистемы "Tech for Non-Technical Founders": Стратегии, ресурсы и определение самого эффективного образовательного курса на 2026 год**
+
+Исторически сложившаяся парадигма технологического предпринимательства, в которой нетехнический основатель находился в критической и зачастую фатальной зависимости от наличия технического кофаундера или дорогостоящего агентства по разработке программного обеспечения, претерпела фундаментальную трансформацию к 2026 году. Около сорока процентов рабочих мест в мире подвергаются трансформации под влиянием искусственного интеллекта, что делает традиционное изучение синтаксиса языков программирования менее релевантным по сравнению с освоением новых когнитивных навыков: инжиниринга промптов (prompt engineering), ИИ-ассистируемого программирования (AI-assisted coding) и проектирования систем автономных агентов.1 В этом новом ландшафте нетехнические основатели больше не ограничены ролью генераторов идей, ожидающих реализации со стороны инженеров. Доступность передовых инструментов генеративного ИИ, специализированных образовательных когорт и закрытых высокосигнальных сообществ создала экосистему, в которой основатель с нулевым опытом программирования способен самостоятельно пройти путь от гипотезы до функционального продукта, генерирующего выручку.
+
+Данный отчет представляет собой исчерпывающий анализ актуальных на 2026 год образовательных ресурсов, акселерационных программ, закрытых форумов и стратегий найма, специально спроектированных для нетехнических фаундеров. На основе синтеза данных выявляются наиболее эффективные образовательные траектории, а также формулируется окончательная рекомендация относительно самого результативного курса, способного обеспечить максимальный возврат инвестиций и минимизацию архитектурных рисков при создании технологического стартапа.
+
+## **Макроэкономический и технологический сдвиг 2026 года: Феномен Vibe Coding**
+
+Понимание актуальных образовательных потребностей нетехнических основателей невозможно без глубокого анализа технологического феномена, определяющего 2026 год — концепции «Vibe Coding» (эмоционально-интуитивного программирования). Этот термин, первоначально возникший в нишевых сообществах разработчиков, эволюционировал в полноценную методологию создания программного обеспечения, где базовая логика формулируется на естественном языке, а искусственный интеллект берет на себя рутину написания синтаксически корректного кода.1
+
+Психологические и нейробиологические механизмы, лежащие в основе популярности Vibe Coding, заслуживают особого внимания. Развитие этой практики глубоко укоренено в поколенческих сдвигах, в частности, в отказе поколения Z и поздних миллениалов от культуры непрерывного изнурительного труда (grind culture) в пользу творческой автономии.3 Vibe Coding функционирует как среда, целенаправленно провоцирующая состояние психологического потока. Использование ИИ-ассистентов, таких как Copilot, ChatGPT или Cursor, радикально снижает когнитивное трение, связанное с отладкой ошибок, в то время как интуитивный подход снижает эмоциональное сопротивление.3 В результате формируется новый, высокоскоростной цикл разработки: возникновение идеи мгновенно переходит в предложение от ИИ, за которым следует реализация и немедленная итеративная настройка.3 Разработка программного обеспечения превращается из процесса преодоления синтаксических барьеров в процесс исследовательской настройки систем.
+
+Однако интеграция этой методологии в бизнес-процессы несет в себе скрытые системные риски, которые часто игнорируются начинающими фаундерами. Эксперты индустрии, такие как Роб Уоллинг, основатель Drip и платформы MicroConf (инвестировавшей в сотни SaaS-стартапов через TinySeed), формулируют критическое предостережение, используя метафору строительства. Создание базового утилитарного приложения с помощью ИИ без знания архитектуры сопоставимо со строительством небольшого сарая: два человека без плотницкого опыта способны возвести конструкцию, которая будет функционировать.2 Тем не менее, по мере масштабирования бизнеса и попыток внедрения сложной бизнес-логики, этот процесс становится эквивалентным попытке построить многоэтажное коммерческое здание без фундаментальных инженерных знаний. Привлечение профессионального разработчика на более поздних этапах для исправления архитектуры такого продукта, созданного исключительно с помощью Vibe Coding, часто приводит к необходимости полного переписывания кодовой базы из\-за катастрофического архитектурного долга.2 Здоровая парадигма, по мнению аналитиков, заключается в том, что "вайб" должен способствовать кодингу, а не заменять базовое понимание структур данных и системной логики.3 Именно этот баланс между скоростью генеративного прототипирования и фундаментальной жизнеспособностью продукта определяет качество передовых образовательных программ 2026 года.
+
+## **Исследование образовательного ландшафта для нетехнических фаундеров**
+
+Рынок образования для начинающих предпринимателей фрагментирован и предлагает спектр решений от краткосрочных воркшопов до многомесячных акселерационных программ. Анализ выявляет две доминирующие философии обучения: первая ориентирована на формирование стратегического управленца, способного дирижировать техническими процессами без погружения в написание кода, вторая — на превращение основателя в независимого соло-разработчика, вооруженного стеком ИИ-инструментов.
+
+### **Философия стратегического управления: Методология Sophia Matveeva**
+
+В категории программ, ориентированных на стратегический продакт-менеджмент и минимизацию рисков, абсолютным лидером выступает флагманская программа «Tech for Non-Technical Founders», созданная Софией Матвеевой.4 Эта программа, методология которой была представлена в Harvard Business Review и преподавалась в Оксфордском университете, London Business School и Chicago Booth, предназначена для бизнес-лидеров, традиционных предпринимателей и нетехнических визионеров.5
+
+Ключевая проблема, которую решает данный курс, заключается в предотвращении классического сценария, при котором нетехнический основатель инвестирует огромные средства (часто превышающие 100 000 долларов) в наемных разработчиков, получая на выходе нежизнеспособный продукт.4 Программа деконструирует этот процесс, обучая основателей думать о разработке технологического продукта до того, как будет выписан первый чек.4 Формат программы представляет собой когортное обучение на основе членства стоимостью 530 долларов США в месяц при минимальном цикле в 6 месяцев.6
+
+Учебный план охватывает фундаментальные аспекты создания бизнеса: валидация рыночного спроса и формирование выигрышного брифа продукта (product brief), бюджетирование, управление временными рамками и де\-рискинг процессов сборки.5 Особое внимание уделяется тому, как корпорации уровня Meta валидируют гипотезы продуктов с потенциалом в миллиарды долларов, используя простые электронные таблицы, прежде чем написать хотя бы одну строку кода.8 Это смещает фокус студента с инструментария на выявление истинной потребности клиента. Программа четко разделяет ответственность: задача основателя — определить, «что строить» (опираясь на данные от клиентов), в то время как задача искусственного интеллекта или наемной команды инженеров — определить, «как это строить».8
+
+Дополнительная ценность курса формируется за счет интеграции гостевых экспертов высочайшего калибра. Например, в 2026 году к программе присоединились инструкторы из Meta и Google, помогающие студентам в формате индивидуальных коучинговых сессий прототипировать, тестировать и принимать стратегические решения о пивоте или привлечении инвестиций.9 Также программа включает бонусные мастер-классы по фандрейзингу, где разбираются реальные стратегии привлечения капитала нетехническими фаундерами, и модули по найму разработчиков.6 Выпускники программы демонстрируют выдающиеся результаты: от создания мобильных приложений для управления активами традиционных финансовых фирм (кейс Муси Скосаны из Южной Африки, трансформировавшего свой бизнес с инвестицией всего в 2000 долларов) до достижения стабильной выручки всего за семь месяцев после трансформации из владельца традиционного бизнеса в технологического фаундера.10
+
+### **Философия независимого ИИ-прототипирования: Экосистема Maven**
+
+Для основателей, чья стратегия заключается в самостоятельном создании минимально жизнеспособного продукта (MVP) с нулевым бюджетом на внешнюю разработку, платформа когортного обучения Maven предлагает наиболее актуальные решения на 2026 год. Данная экосистема агрегирует практические интенсивы от действующих практиков индустрии.
+
+Наиболее глубоким курсом в этой категории является четырехнедельная программа Дрю Фалкмана «Vibe Coding Data-Enabled AI Apps for Product Managers, Designers, and Founders», стоимость которой составляет 1000 долларов США.12 Программа, получившая рейтинг 4.8 из 5 звезд на основе отзывов выпускников из таких компаний, как Treatwell, призвана избавить нетехнических специалистов от зависимости перед массивными бэклогами инженерных отделов.12
+
+Учебный план курса Фалкмана представляет собой исчерпывающее руководство по современному стеку ИИ-разработки. Первая неделя посвящена формированию продуктовой стратегии и созданию специализированного документа требований — «Vibe PRD», который структурирует инструкции для ИИ (ChatGPT), предотвращая галлюцинации и отклонения от бизнес-логики.12 Вторая неделя сфокусирована на генерации пользовательского интерфейса с использованием платформы Lovable, где студенты изучают нюансы оптимизации промптов и контекстного управления.12 Настоящим прорывом курса является переход от визуальных компонентов к полноценной серверной архитектуре на третьей и четвертой неделях: студенты осваивают настройку баз данных в Supabase, базовый синтаксис SQL, интеграцию больших языковых моделей (Claude, OpenAI) через пограничные функции (edge functions) и внедрение платежных шлюзов Stripe.12 Этот переход является критическим, так как создание масштабируемой базы данных традиционно было непреодолимым барьером для пользователей без технического образования.12 Завершается курс развертыванием кода через GitHub, что обеспечивает стандартизированную передачу продукта инженерам в будущем.14
+
+Параллельно с курсом по созданию приложений, Maven хостит программы, сфокусированные на автоматизации операционной деятельности. Интенсив Андреа Маркиотто «Build an AI-Powered Startup OS in One Day» переносит фокус с написания кода на проектирование многоагентных рабочих процессов (agentic workflows).15 В рамках этого воркшопа основатели изучают фундаментальные отличия между простыми промптами и надежными архитектурами автоматизации, включающими логику ввода/вывода, проектирование триггеров и маршрутизацию решений.15 Используя платформы интеграции, такие как Make.com, студенты создают сети ИИ-агентов, способных автономно обрабатывать лиды, проводить глубокие исследования и превращать хаотичные операционные знания в структурированные стандартные операционные процедуры (SOP).15 Подобные системы позволяют нетехническим основателям масштабировать операционную пропускную способность стартапа без пропорционального увеличения штата сотрудников. Тема практического использования моделей вроде Claude Code для развертывания локальных агентных систем также глубоко раскрывается в курсах Микаэлы Рейес и Николаса Рейеса, предоставляя фаундерам навыки создания «цифровых сотрудников», работающих в формате 24/7.16
+
+### **Акселерационные программы и позиция Y Combinator**
+
+Институциональный подход к обучению нетехнических фаундеров также претерпел изменения. Founder Institute (FI), признанный крупнейшим в мире pre-seed акселератором с портфелем более 9000 компаний, интегрировал концепцию Vibe Coding в свои базовые программы. Запущенный в 2026 году «Vibecode a Product Bootcamp» представляет собой 10-дневный интенсив стоимостью от 399 до 499 долларов США, доступный глобально (включая локальные инициативы в Лос-Анджелесе, Сан-Диего и Сиднее).19
+
+Методология буткемпа FI направлена на соло-фаундеров и включает четыре живые сессии, чередующиеся с интенсивной самостоятельной работой. Программа начинается с определения скоупа продукта и настройки стека инструментов (n8n, OpenAI, Replit, PostgreSQL), после чего участники переводят клиентский путь (user journey) в промпты для генерации базового интерфейса.19 Завершающие этапы включают добавление автоматизаций и интеграций сторонних сервисов, а также запуск продукта для реальных пользователей с целью сбора метрик и валидации гипотез на пути к product/market fit.19 Отзывы студентов подчеркивают, что структура программы, совмещенная с глубокими интервью потенциальных клиентов, позволяет превратить абстрактную идею в функциональный MVP с реальной тягой, обеспечивая нетехническим участникам беспрецедентный уровень ясности и импульса к действию.19 Дополнительным преимуществом является доступ участников к экосистеме FI, предлагающей студенческие льготы, включая GitHub Student Developer Pack (предоставляющий доступ к Copilot Pro и облачным кредитам Azure), а также перспективы привлечения финансирования через связанные структуры, такие как Techstars.24
+
+Позиция наиболее влиятельного акселератора Кремниевой долины, Y Combinator, относительно нетехнических фаундеров в 2026 году также отражает смещение парадигмы. В манифестах YC прямо утверждается, что инструменты и бизнес-модели сегодняшнего дня позволяют превратить идею в продукт производственного качества за считанные недели без необходимости делиться долей в компании (equity) с техническим кофаундером на ранних этапах.25 YC поощряет прототипирование с помощью ИИ для быстрой валидации. Ярким примером этой тенденции служит стартап Woz, профинансированный YC в батче W25, миссия которого — стать мостом между ИИ-сгенерированным кодом и масштабируемым бизнесом, предоставляя нетехническим основателям платформу и экспертную инженерную поддержку для превращения прототипов в надежные предприятия.26 Аналогичную миссию преследует компания OpenBuilder, акцентирующая внимание на том, что фаундеры должны не просто начинать проекты, но и доводить их до релиза.27 Общий консенсус сообщества YC сводится к исторической аналогии с Airbnb: фундаментальный вопрос бизнеса часто не требует написания кода для своей проверки (например, готовность людей сдавать и снимать жилье у незнакомцев); как только концепция доказана, основатель получает возможность привлечь капитал и нанять полноценную команду.28
+
+### **Академические платформы, корпоративный PM и региональные рынки**
+
+Для руководителей высшего звена и опытных продакт-менеджеров (с опытом работы более 5 лет), работающих в корпоративном сегменте, экосистема предлагает совершенно иные инструменты. Платформа Reforge, с годовой подпиской около 1995 долларов США, предоставляет программы глубокого погружения в стратегии развития ИИ-продуктов.29 В отличие от курсов по созданию MVP, методология Reforge фокусируется на управлении уже работающими моделями машинного обучения. Студенты изучают методологии оценки (Evaluation), принципы обучения с подкреплением на основе отзывов людей (RLHF), внедрение систем сбора человеческой обратной связи (Human Feedback) и системную тонкую настройку моделей (Fine-Tuning) для дифференцированных бизнес-кейсов.30
+
+Фундаментальная академическая база обеспечивается такими платформами, как DataCamp, предлагающими курсы вроде «Associate AI Engineer» и «AI Fundamentals», которые закрывают пробелы в знании Python и SQL.31 Также высоким спросом пользуются узкоспециализированные технические курсы ведущих университетов (MIT 6.S191 по глубокому обучению, Stanford CS224N по обработке естественного языка), предоставляющие системное понимание архитектуры нейросетей, необходимое для управления сложными корпоративными ИИ-системами.32 Традиционные сертификации, такие как IBM/Google AI Certificates на Coursera, остаются стандартом для подтверждения квалификации на корпоративном уровне.33
+
+Интересно отметить дихотомию между глобальным рынком и региональными образовательными продуктами. Анализ русскоязычного сегмента онлайн-образования 2026 года, представленного на агрегаторах TutorTop и Kurshub, показывает доминирование классических школ: Skillbox, Нетология, PMCLUB и Fashion Factory.35 Учебные планы лучших русскоязычных курсов по запуску стартапов традиционно сфокусированы на управлении цифровым продуктом, расчете юнит-экономики, формировании KPI и проектировании MVP методами классического продакт-менеджмента (часто с использованием Excel или базового визуального No-Code).36 Однако эти программы демонстрируют заметное отставание в интеграции передовых ИИ-агентных архитектур и парадигмы Vibe Coding, которые стали стандартом де\-факто в экосистемах Кремниевой долины и глобальных англоязычных платформах.
+
+Для систематизации образовательных траекторий ниже приведена сравнительная аналитическая матрица ключевых программ 2026 года.
+
+| Наименование программы | Провайдер / Автор | Основной фокус обучения | Ключевые компетенции и инструментарий | Формат и стоимость | Целевой профиль основателя |
+| :---- | :---- | :---- | :---- | :---- | :---- |
+| **Tech for Non-Technical Founders** | Sophia Matveeva | Стратегия продукта, валидация бизнес-модели, управление командой и бюджетом | Де-рискинг, брифование инженеров, фандрейзинг, оценка ROI | 6 мес. когорта, $530/мес. (\~$3180) | Визионеры, традиционные предприниматели, лидеры, привлекающие инвестиции |
+| **Vibe Coding Data-Enabled AI Apps** | Drew Falkman (Maven) | Быстрое ИИ-прототипирование функционального продукта | Lovable, Supabase (SQL, edge functions), Stripe, GitHub, Vibe PRD | 4 недели, интенсивы, $1000 | Соло-фаундеры, дизайнеры и PM, желающие создавать MVP своими руками |
+| **AI Startup OS** | Andrea Marchiotto (Maven) | Автоматизация операционной деятельности стартапа | Make.com, многоагентные системы (Multi-Agent), экстракция SOP | 1 день, воркшоп, динамическая цена | Операционные директора, фаундеры, масштабирующие внутренние процессы |
+| **Vibecode a Product Bootcamp** | Founder Institute | Системная акселерация от идеи до первых клиентов | n8n, OpenAI, Replit, PostgreSQL, глубинные интервью | 10 дней, 4 сессии, $399 – $499 | Начинающие стартаперы на стадии pre-seed, ищущие структуру и traction |
+| **AI and Product Programs** | Reforge | Продвинутый продуктовый менеджмент в эпоху ИИ | Оценка ИИ, Fine-Tuning, RLHF, Human Feedback | Годовая подписка, \~$1995/год | Опытные корпоративные продакт-менеджеры (5+ лет опыта) |
+
+## **Инфраструктура социального капитала: Закрытые сообщества 2026 года**
+
+Получение теоретических знаний и навыков работы с ИИ — лишь половина уравнения успеха стартапа. В 2026 году социальный капитал и доступ к экспертной сети играют критическую роль для нетехнических фаундеров. Ранее популярные публичные группы в Slack, Telegram или Discord столкнулись с феноменом, известным в индустрии как «High-Signal Stall» (застой высокого сигнала), когда рост аудитории приводит к экспоненциальному увеличению информационного шума, спама и агрессивного самопиара, вытесняя реальных разработчиков и инвесторов.37
+
+В ответ на эту деградацию публичных пространств экосистема эволюционировала в сторону строгой фильтрации и гейткипинга. Наиболее ценные приглашения в закрытые сообщества сегодня не публикуются в каталогах, а рассылаются через прямые сообщения в социальных сетях (например, X/Twitter) только после того, как основатель публично демонстрирует успешный запуск продукта, подтверждая свою компетентность (proof-of-work).37 Тем не менее, для основателей на ранних стадиях существуют платформы, предоставляющие доступ к высококачественному социальному графу.
+
+Для независимых фаундеров, строящих бутстрап-бизнесы (развивающиеся на собственные доходы без привлечения венчурного капитала), эталоном является **Indie Hackers Discord**.39 Сервер отличается строгой модерацией и жестким структурированием каналов по стадиям развития бизнеса (от генерации идей до валидации, запуска, роста и масштабирования). Присутствие технически подкованной аудитории, склонной к деловому мышлению, делает этот ресурс идеальным местом для нетехнических фаундеров, ищущих технического партнера через специализированный канал (co-founder matching channel), который исторически демонстрирует высокую результативность.39 Отзывы подчеркивают, что время ожидания экспертного ответа на реальный вопрос в дневное время здесь редко превышает 30 минут.39 В этой же нише стоит отметить **The Entrepreneur Exchange**, сообщество общего профиля с низкой долей саморекламы и мощными еженедельными потоками подотчетности (accountability threads), идеально подходящее для предпринимателей в сфере сервисного бизнеса.39
+
+Концепция платных сообществ доказала свою эффективность как механизм фильтрации шума. **Ramen Club**, платная группа в Slack, организованная лондонским фаундером Чарли Уордом, объединяет основателей, стремящихся достичь уровня "ramen profitable" (дохода, достаточного для покрытия базовых жизненных потребностей).40 Аналогичную функцию выполняют высокоспециализированные SEO-сообщества вроде **Traffic Think Tank**, объединяющие SaaS-маркетологов и старших специалистов, готовых платить за доступ к инсайтам без информационного мусора.42 Однако организаторы сообществ признают, что успех таких инициатив часто зависит от офлайн-компонента; так, успешность Ramen Club во многом обусловлена регулярными личными встречами Indie Beers в Лондоне и Лиссабоне, что компенсирует усталость аудитории от бесконечных Zoom-коллов постпандемийной эпохи.43
+
+Особый статус в 2026 году приобрело сообщество **Lovable Community**. В связи с бумом Vibe Coding, Discord-сервер этого инструмента объединил более 160 000 разработчиков, основателей и энтузиастов по всему миру.44 Сообщество функционирует как глобальный хаб генеративной разработки, регулярно организуя офлайн-хакатоны в десятках стран (от Сингапура до Италии, Норвегии и Аргентины).44 Культура внутри Lovable Discord отличается высоким уровнем практической взаимопомощи: от совместного решения архитектурных проблем до использования специализированных обходных путей. Например, нетехнические фаундеры используют официальных Discord-ботов сообщества для маршрутизации своих промптов к ИИ, что позволяет обходить лимиты на списание кредитов внутри самой платформы Lovable, экономя значительные средства при интенсивном прототипировании.45
+
+Для основателей, выбравших путь традиционной No-Code разработки без использования генеративного ИИ, центральным хабом остается **No Code Founders (NCF)**. Это сообщество, объединяющее тысячи специалистов, фокусируется на прозрачном обмене архитектурами (tech stacks), используемыми для вывода продуктов на рынок. Основатель Bubble Эммануэль Страшнов отмечает, что NCF удалось собрать аудиторию вовлеченных фаундеров, строящих полномасштабные бизнесы исключительно на инструментах визуального программирования.46
+
+Ниже представлена сравнительная характеристика наиболее эффективных сетевых ресурсов для нетехнических фаундеров.
+
+| Название сообщества | Платформа | Модель доступа | Основная ценность (High-Signal Value) | Идеальный профиль участника |
+| :---- | :---- | :---- | :---- | :---- |
+| **Indie Hackers** | Discord / Forum | Бесплатно (модерируемо) | Поиск кофаундеров, быстрая обратная связь, прозрачность выручки | Бутстрапперы, соло-фаундеры, разработчики side-проектов |
+| **Lovable Community** | Discord | Бесплатно | Практическая помощь по Vibe Coding, обход лимитов, глобальные офлайн-хакатоны | Энтузиасты генеративной разработки, участники воркшопов |
+| **No Code Founders** | Slack / Web | Бесплатно | Проверенные архитектуры No-Code решений, консультации по Bubble / Webflow | Традиционные No-Code разработчики, MVP-строители |
+| **Ramen Club** | Slack | Платно | Строгий фильтр от спама, фокус на достижении базовой рентабельности, офлайн-митапы | SaaS-фаундеры, ищущие глубокий нетворкинг без агрессивного маркетинга |
+| **The Entrepreneur Exchange** | Discord | Бесплатно (строгая модерация) | Еженедельная подотчетность, низкий уровень самопиара, общие бизнес-стратегии | Предприниматели сферы услуг, генералисты |
+
+Помимо выбора сообщества, фаундеры должны понимать архитектуру современных платформ для управления комьюнити. Если основатель сам решает создать закрытое сообщество вокруг своего стартапа, на смену традиционным форумам приходят такие инструменты, как Circle и Geneva. Circle предлагает глубокую аналитику вовлеченности, монетизацию через закрытые уровни (tiers) и бесшовную интеграцию данных через Zapier и Notion, превращая сообщество из площадки для общения в управляемый канал продаж и удержания клиентов.50
+
+## **Стратегии найма в эпоху AI-Augmented Engineering**
+
+Несмотря на возможности генеративного прототипирования, стадия масштабирования технологического бизнеса, интеграции сложных корпоративных систем и обеспечения безопасности данных неминуемо требует привлечения профессиональных инженеров.25 В 2026 году глобальный рынок труда разработчиков переживает структурный кризис: дефицит талантов растет, ожидается около 2 миллионов открытых вакансий, а средняя заработная плата Senior-инженера в США достигла 235 000 долларов в год при снижении показателя принятия офферов (acceptance rate) до критических 51%.52 В этих условиях стартапу с ограниченным бюджетом практически невозможно конкурировать за локальные кадры в Кремниевой долине.
+
+Однако внедрение искусственного интеллекта радикально трансформировало сам профиль кандидата. ИИ не вытеснил инженеров, а привел к появлению новой доминирующей категории специалистов — ИИ-аугментированных разработчиков (AI-Augmented Developer). Заработная плата таких специалистов на уровне Junior составляет от 85 000 до 120 000 долларов, однако благодаря использованию ИИ-копилотов они способны демонстрировать производительность на уровне Senior-инженеров.53 Появились и узкоспециализированные роли: AI Integration Engineer (100 000 – 140 000 долларов), чья задача — безопасное связывание закрытых систем генеративного ИИ с унаследованной архитектурой компании, и AI Quality Engineer (90 000 – 120 000 долларов), специализирующийся исключительно на тестировании и валидации кода, сгенерированного машиной.53
+
+Изменение профиля разработчика требует от нетехнического фаундера полного пересмотра методологии проведения собеседований. Навык написания кода больше не является основным проверяемым параметром. Главной компетенцией в 2026 году стала способность инженера брать на себя ответственность за сложные системы и направлять ИИ.54 Эксперты индустрии подчеркивают, что искусственный интеллект способен генерировать алгоритмы, но именно человек придает этому коду смысл и направление.55 Следовательно, вместо алгоритмических тестов, собеседование должно фокусироваться на системном мышлении и софт-скиллах, включая способность объяснять технические концепции нетехническим стейкхолдерам.56 Ключевые вопросы для найма в 2026 году включают:
+
+1. Как вы модернизируете существующую функцию, не вызывая непреднамеренных сбоев в других областях системы?  
+2. Как вы распознаете, что проблема была решена системно на долгий срок, а не просто временно "заплатана"?  
+3. Каким образом вы интегрируете ИИ-инструменты в свою повседневную работу, сохраняя при этом жесткий контроль над качеством и безопасностью архитектуры?.54
+
+Экономическое давление вынуждает стартапы обращаться к глобальному арбитражу талантов. Компании выбирают офшорную разработку не просто ради снижения затрат, а потому что квалифицированные кадры в нужном объеме физически отсутствуют на локальных рынках США и Европы.57 География аутсорсинга в 2026 году претерпела значительные изменения. Индийский технологический сектор, продемонстрировавший рост на 8,4% и перешагнувший рубеж в 200 миллиардов долларов экспорта программного обеспечения, сформировал второй по величине пул ИИ-талантов в мире после США.57 Значимым трендом стало смещение фокуса найма из перегретых мегаполисов вроде Бангалора в технологические хабы второго уровня (Tier-2), такие как Джайпур, Кочи, Индаур и Коимбатур. Инженеры мирового класса в этих регионах доступны по ставкам на 20-30% ниже столичных, формируя высококонкурентный офшорный ценовой диапазон от 15 до 70 долларов в час.57
+
+Для минимизации рисков при найме нетехническим основателям настоятельно рекомендуется избегать найма "универсалов" и искать специалистов с глубоким пониманием фундаментальных принципов машинного обучения (ML engineering fundamentals).58 Кроме того, использование платформ предварительного технического тестирования (например, Devskiller) позволяет объективно оценить реальные навыки кандидата и его рабочую этику до проведения интервью, отсеивая поток неквалифицированных заявок.58
+
+Выбор платформы для найма зависит от бюджета, требуемой экспертизы и временных рамок проекта. Сравнительная характеристика ведущих платформ для найма ИИ-аугментированных разработчиков представлена в таблице ниже.
+
+| Модель найма и Платформа | Специфика и качество проверки кандидатов (Vetting) | Среднее время закрытия вакансии | Оценочная стоимость разработки | Географический охват |
+| :---- | :---- | :---- | :---- | :---- |
+| **Onshore (Локальный найм, США/ЕС)** | Культурное соответствие, отсутствие языковых барьеров | 30–60+ дней | $130,000 – $210,000+ / год | Локально |
+| **Nearshore (LatHire)** | Экономичность, идеальное совпадение часовых поясов | 2–5 дней | $45 – $100 / час | LATAM (Латинская Америка) |
+| **Offshore Expert (Toptal)** | Senior-инженеры (топ 3%), многоуровневое тестирование | 1–5 дней | $90 – $200+ / час | Глобально (офшор/ниаршор) |
+| **Offshore Expert (AI People Agency)** | Комплексный скрининг узкоспециализированных ИИ-талантов | \< 48 часов | $90 – $250+ / час | Глобально |
+| **AI-First Software Agency (Seedium)** | Проектная разработка "под ключ", ИИ-копилоты, LLM интеграции | Зависит от объема проекта | Проектная оценка (SOW) | Глобально (Фокус на США/ЕС) |
+| **Mass Market Offshore (Upwork)** | Самостоятельная базовая оценка фаундером, точечные задачи | 1–3 дня | $35 – $120+ / час | Глобально |
+
+## **Синтез и определение самого эффективного курса на 2026 год**
+
+Исследование демонстрирует, что концепция «одного универсального курса» для нетехнических основателей в 2026 году является ошибочной. Эффективность образовательной траектории жестко детерминирована архетипом самого основателя, его доступом к капиталу и стратегией вывода продукта на рынок. На основе всестороннего анализа мы определяем двух абсолютных лидеров рынка, закрывающих полярные, но одинаково критические потребности стартап-экосистемы.
+
+### **Выбор №1 для стратегических лидеров и визионеров: Tech for Non-Technical Founders**
+
+Если основатель обладает глубоким пониманием болей индустрии (domain expertise), располагает стартовым капиталом, планирует привлекать венчурное финансирование или трансформировать уже существующий традиционный бизнес, самым эффективным курсом на 2026 год признается программа Софии Матвеевой **«Tech for Non-Technical Founders»**.4
+
+Фундаментальное преимущество данной методологии заключается в ее превентивной природе. В то время как большинство технических курсов учат "как нажимать кнопки", программа Матвеевой формирует управленческий каркас, предотвращающий катастрофическое выгорание бюджета на ранних стадиях.4 Научившись валидировать гипотезы с помощью таблиц и No-Code решений до взаимодействия с инженерами, грамотно составлять технические задания и управлять де\-рискингом проекта, выпускники курса обретают способность руководить сложными технологическими процессами, оставаясь в бизнес-контуре.4 Наличие индивидуального коучинга от действующих руководителей из Meta и Google обеспечивает беспрецедентный уровень экспертизы, а доказанные кейсы выпускников, привлекающих инвестиции и достигающих рентабельности за несколько месяцев, подтверждают наивысший показатель возврата инвестиций (ROI) среди всех проанализированных программ.9
+
+### **Выбор №1 для инди-хакеров и соло-разработчиков: Vibe Coding Data-Enabled AI Apps**
+
+В сценарии, когда основатель ограничен в ресурсах, развивает проект по модели бутстраппинга и ставит целью самостоятельное создание и запуск полнофункционального программного обеспечения без привлечения сторонних агентств, безусловным лидером является интенсив Дрю Фалкмана **«Vibe Coding Data-Enabled AI Apps for Product Managers, Designers, and Founders»** на платформе Maven.12
+
+Данный курс представляет собой квинтэссенцию технологического сдвига 2026 года. В отличие от устаревших визуальных No-Code конструкторов, генерирующих закрытый и немасштабируемый код, курс Фалкмана обучает использованию связки ИИ-инструментов нового поколения: интерфейсного генератора Lovable и профессиональной базы данных Supabase.12 Программа преодолевает главный барьер нетехнических фаундеров — настройку серверной инфраструктуры и баз данных, обучая работе с SQL, API, функциями аутентификации и платежами через Stripe посредством естественного языка (Vibe Coding).12 Эта программа буквально наделяет нетехнического специалиста производственной мощностью полноценного инженерного отдела, позволяя тестировать сложные бизнес-идеи в рабочей среде с минимальными финансовыми затратами.
+
+Таким образом, актуальная стратегия обучения для нетехнического основателя в 2026 году сводится к осознанному выбору между формированием компетенции системного архитектора, управляющего ИИ-моделями на макроуровне, и компетенции бизнес-визионера, способного безопасно интегрировать глобальные инженерные таланты в свой проект. Вне зависимости от выбранного пути, синергия этих образовательных программ с активным участием в High-Signal сообществах формирует наиболее надежный фундамент для построения технологического стартапа в эпоху тотальной автоматизации.
+
+#### **Источники**
+
+1. The ONLY 3 AI Skills You Need In 2026 (Don't Fall Behind), дата последнего обращения: мая 12, 2026, [https://www.youtube.com/watch?v=9pSCgotdcOU](https://www.youtube.com/watch?v=9pSCgotdcOU)  
+2. Vibe Coding: Opportunity or Distraction? \- Creator Science, дата последнего обращения: мая 12, 2026, [https://creatorscience.com/vibe-coding/](https://creatorscience.com/vibe-coding/)  
+3. Vibe coding \- GitHub Gist, дата последнего обращения: мая 12, 2026, [https://gist.github.com/MangaD/89aecf8511a4d3f49332f272aa589d59](https://gist.github.com/MangaD/89aecf8511a4d3f49332f272aa589d59)  
+4. Tech for Non-Technical Founders, дата последнего обращения: мая 12, 2026, [https://www.techfornontechies.co/tech-for-non-technical-founders](https://www.techfornontechies.co/tech-for-non-technical-founders)  
+5. Tech for Non-Techies \- Apple Podcasts, дата последнего обращения: мая 12, 2026, [https://podcasts.apple.com/gb/podcast/tech-for-non-techies/id1516475320](https://podcasts.apple.com/gb/podcast/tech-for-non-techies/id1516475320)  
+6. Membership (Updated) \- Tech For Non-Techies, дата последнего обращения: мая 12, 2026, [https://www.techfornontechies.co/membership](https://www.techfornontechies.co/membership)  
+7. Tech for Non-Techies \- Practical app & AI strategy for non-technical founders., дата последнего обращения: мая 12, 2026, [https://techfornontechies.libsyn.com/2020/07](https://techfornontechies.libsyn.com/2020/07)  
+8. Listen to Tech for Non-Techies podcast | Deezer, дата последнего обращения: мая 12, 2026, [https://www.deezer.com/en/show/1001070362](https://www.deezer.com/en/show/1001070362)  
+9. 286: Lessons from Meta and Google for non-technical founders in 2026, дата последнего обращения: мая 12, 2026, [https://www.techfornontechies.co/blog/286-lessons-from-meta-and-google-for-non-technical-founders-in-2026](https://www.techfornontechies.co/blog/286-lessons-from-meta-and-google-for-non-technical-founders-in-2026)  
+10. BONUS: From 0 to 1 where your tech venture will be by February, дата последнего обращения: мая 12, 2026, [https://www.techfornontechies.co/blog/from-0-to-1-where-your-tech-venture-will%20be-by-february](https://www.techfornontechies.co/blog/from-0-to-1-where-your-tech-venture-will%20be-by-february)  
+11. Idea to revenue in 7 months: how this non-technical founder did it, дата последнего обращения: мая 12, 2026, [https://www.techfornontechies.co/blog/285-from-idea-to-revenue-in-7-months-how-this-non-technical-founder-did-it](https://www.techfornontechies.co/blog/285-from-idea-to-revenue-in-7-months-how-this-non-technical-founder-did-it)  
+12. Vibe Coding Data-Enabled AI Apps for Product Managers ... \- Maven, дата последнего обращения: мая 12, 2026, [https://maven.com/drewfalkman/vibe-coding-for-non-technical-founders](https://maven.com/drewfalkman/vibe-coding-for-non-technical-founders)  
+13. Product Analytics Courses | Product Manager Online Courses, дата последнего обращения: мая 12, 2026, [https://www.productmanagercourses.com/courses/category/product-analytics](https://www.productmanagercourses.com/courses/category/product-analytics)  
+14. PRD Vibe Coding 101 \- YouTube, дата последнего обращения: мая 12, 2026, [https://www.youtube.com/watch?v=9L5WjQGIV30](https://www.youtube.com/watch?v=9L5WjQGIV30)  
+15. Build an AI-Powered Startup OS in One Day \- No Code Required by ..., дата последнего обращения: мая 12, 2026, [https://maven.com/blackcubelabs/ai-startup-os](https://maven.com/blackcubelabs/ai-startup-os)  
+16. Build An Agent Native Company Series \- \#5 (BTS+Live) \- Maven, дата последнего обращения: мая 12, 2026, [https://maven.com/p/386fd3/build-an-agent-native-company-series-5-bts-live](https://maven.com/p/386fd3/build-an-agent-native-company-series-5-bts-live)  
+17. Use Claude Code as a Non-Technical Pro \- Maven, дата последнего обращения: мая 12, 2026, [https://maven.com/p/8fabac/use-claude-code-as-a-non-technical-pro](https://maven.com/p/8fabac/use-claude-code-as-a-non-technical-pro)  
+18. Master Claude Code as a Non-Technical Pro \- Maven, дата последнего обращения: мая 12, 2026, [https://maven.com/mika-reyes/master-claude-code-as-a-non-technical-pro](https://maven.com/mika-reyes/master-claude-code-as-a-non-technical-pro)  
+19. The Best AI Productivity Bootcamp for Professionals in 2026 — Set ..., дата последнего обращения: мая 12, 2026, [https://fi.co/insight/the-best-ai-productivity-bootcamp-for-professionals-in-2026-set-up-your-ai-assistant-build-apps-without-code](https://fi.co/insight/the-best-ai-productivity-bootcamp-for-professionals-in-2026-set-up-your-ai-assistant-build-apps-without-code)  
+20. Build a Great Startup in 2026 with the FI Los Angeles Startup Accelerator \- Founder Institute, дата последнего обращения: мая 12, 2026, [https://fi.co/insight/build-a-great-startup-in-2026-with-the-fi-los-angeles-startup-accelerator](https://fi.co/insight/build-a-great-startup-in-2026-with-the-fi-los-angeles-startup-accelerator)  
+21. Build a Great Startup in 2025 with the FI San Diego Startup Accelerator \- Founder Institute, дата последнего обращения: мая 12, 2026, [https://fi.co/insight/build-a-great-startup-in-2025-with-the-fi-san-diego-startup-accelerator-san-diego](https://fi.co/insight/build-a-great-startup-in-2025-with-the-fi-san-diego-startup-accelerator-san-diego)  
+22. It is time to build the future. Applications Now Open to Founder Institute Sydney Virtual Spring 2020, дата последнего обращения: мая 12, 2026, [https://fi.co/insight/it-is-time-to-build-the-future-applications-now-open-to-founder-institute-sydney-virtual-spring-2020](https://fi.co/insight/it-is-time-to-build-the-future-applications-now-open-to-founder-institute-sydney-virtual-spring-2020)  
+23. Founder Bootcamps | Supercharge your entrepreneurial skills, дата последнего обращения: мая 12, 2026, [https://fi.co/bootcamps](https://fi.co/bootcamps)  
+24. Resources | Fathy Rashad, дата последнего обращения: мая 12, 2026, [https://www.mfrashad.com/resources](https://www.mfrashad.com/resources)  
+25. Non-Technical Founder's Guide 2026 \- Chrono Innovation, дата последнего обращения: мая 12, 2026, [https://www.chronoinnovation.com/resources/non-technical-founder-guide-2026/](https://www.chronoinnovation.com/resources/non-technical-founder-guide-2026/)  
+26. Founder in Residence at Woz (San Francisco) \- Y Combinator, дата последнего обращения: мая 12, 2026, [https://www.ycombinator.com/companies/woz/jobs/Nsh4F78-founder-in-residence-at-woz-san-francisco](https://www.ycombinator.com/companies/woz/jobs/Nsh4F78-founder-in-residence-at-woz-san-francisco)  
+27. OpenBuilder: The vibe coding platform where builders actually finish. \- Y Combinator, дата последнего обращения: мая 12, 2026, [https://www.ycombinator.com/companies/openbuilder](https://www.ycombinator.com/companies/openbuilder)  
+28. Non technical founders at YC, what are you building? : r/ycombinator \- Reddit, дата последнего обращения: мая 12, 2026, [https://www.reddit.com/r/ycombinator/comments/1hu5wxx/non\_technical\_founders\_at\_yc\_what\_are\_you\_building/](https://www.reddit.com/r/ycombinator/comments/1hu5wxx/non_technical_founders_at_yc_what_are_you_building/)  
+29. AI for Product Managers: The Best Courses, Programs, & Training for Building AI-Powered Products | Leland, дата последнего обращения: мая 12, 2026, [https://www.joinleland.com/library/a/ai-for-product-managers](https://www.joinleland.com/library/a/ai-for-product-managers)  
+30. AI Courses Online \- Reforge, дата последнего обращения: мая 12, 2026, [https://www.reforge.com/course-categories/ai](https://www.reforge.com/course-categories/ai)  
+31. I Tried 30 AI Engineering Courses: Here are the Best 5, дата последнего обращения: мая 12, 2026, [https://www.youtube.com/watch?v=LYCBOk8b790\&vl=en](https://www.youtube.com/watch?v=LYCBOk8b790&vl=en)  
+32. 5 Free AI Certifications That Turn Into High Paying Jobs (2026 Update), дата последнего обращения: мая 12, 2026, [https://www.youtube.com/watch?v=fUkkXYs2Luo](https://www.youtube.com/watch?v=fUkkXYs2Luo)  
+33. Top 10 Best AI Courses for Non-IT Background (2026) | Expert Review \- LogicMojo, дата последнего обращения: мая 12, 2026, [https://www.logicmojo.com/best-ai-courses-non-it-background/](https://www.logicmojo.com/best-ai-courses-non-it-background/)  
+34. Best No-Code Development Courses & Certificates \[2026\] \- Coursera, дата последнего обращения: мая 12, 2026, [https://www.coursera.org/courses?query=no-code%20development](https://www.coursera.org/courses?query=no-code+development)  
+35. ТОП-10 онлайн-курсов по запуску стартапов 2026 года \- tutortop, дата последнего обращения: мая 12, 2026, [https://tutortop.ru/courses\_selection/kursy\_po\_zapusku\_razvitiyu\_startapov/](https://tutortop.ru/courses_selection/kursy_po_zapusku_razvitiyu_startapov/)  
+36. ТОП-25 курсов по запуску стартапов в 2026 году \- KursHub, дата последнего обращения: мая 12, 2026, [https://kurshub.ru/kursy/luchshie-startap-kursy/](https://kurshub.ru/kursy/luchshie-startap-kursy/)  
+37. Where do you actually find the best private/invite-only Slack, Discord & Telegram communities for founders in 2026? : r/SaaS \- Reddit, дата последнего обращения: мая 12, 2026, [https://www.reddit.com/r/SaaS/comments/1say6lk/where\_do\_you\_actually\_find\_the\_best/](https://www.reddit.com/r/SaaS/comments/1say6lk/where_do_you_actually_find_the_best/)  
+38. Scale SaaS Onboarding Without Losing Customer Success | ARISE GTM, дата последнего обращения: мая 12, 2026, [https://arisegtm.com/blog/scaling-onboarding-without-sacrificing-customer-success](https://arisegtm.com/blog/scaling-onboarding-without-sacrificing-customer-success)  
+39. Best Discord Servers for Entrepreneurs (2026 Ranked Guide) \- Talk Shop, дата последнего обращения: мая 12, 2026, [https://www.letstalkshop.com/blog/best-discord-servers-for-entrepreneurs-2026](https://www.letstalkshop.com/blog/best-discord-servers-for-entrepreneurs-2026)  
+40. The best startup communities in 2026 \- Product Hunt, дата последнего обращения: мая 12, 2026, [https://www.producthunt.com/categories/startup-communities](https://www.producthunt.com/categories/startup-communities)  
+41. The best communities for founders \- High Signal, дата последнего обращения: мая 12, 2026, [https://www.highsignal.io/the-best-communities-for-founders/](https://www.highsignal.io/the-best-communities-for-founders/)  
+42. 3 Top SaaS Link Building Communities to Join in 2026 \- Indie Hackers, дата последнего обращения: мая 12, 2026, [https://www.indiehackers.com/post/3-top-saas-link-building-communities-to-join-in-2026-f0938ea6d0](https://www.indiehackers.com/post/3-top-saas-link-building-communities-to-join-in-2026-f0938ea6d0)  
+43. I'm shutting down my founder community \- Pete Codes, дата последнего обращения: мая 12, 2026, [https://www.petecodes.io/shutting-down-founder-community/](https://www.petecodes.io/shutting-down-founder-community/)  
+44. Join the Lovable Community | Lovable Discord or Browse Events, дата последнего обращения: мая 12, 2026, [https://lovable.dev/community](https://lovable.dev/community)  
+45. Method to Use Lovable WITHOUT Burning Credits: Send Prompts via Discord Bot (2026 still working) : r/vibecoding \- Reddit, дата последнего обращения: мая 12, 2026, [https://www.reddit.com/r/vibecoding/comments/1qn4pni/method\_to\_use\_lovable\_without\_burning\_credits/](https://www.reddit.com/r/vibecoding/comments/1qn4pni/method_to_use_lovable_without_burning_credits/)  
+46. Best No-Code Communities, Curated Lists & Resources in 2026 \- Peaka, дата последнего обращения: мая 12, 2026, [https://www.peaka.com/blog/best-no-code-communities/](https://www.peaka.com/blog/best-no-code-communities/)  
+47. Top No-Code Communities to Unlock in 2026 \- Quixy, дата последнего обращения: мая 12, 2026, [https://quixy.com/blog/no-code-communities-for-digital-transformation/](https://quixy.com/blog/no-code-communities-for-digital-transformation/)  
+48. 20 Vibrant No-Code Communities & Forums 2026 \[Free To Join\] \- CodeConductor.ai, дата последнего обращения: мая 12, 2026, [https://codeconductor.ai/blog/no-code-communities/](https://codeconductor.ai/blog/no-code-communities/)  
+49. The Honest Guide to Finding Good Bubble Help (Without Wasting, дата последнего обращения: мая 12, 2026, [https://coachingnocodeapps.com/how-to-find-a-bubble-developer](https://coachingnocodeapps.com/how-to-find-a-bubble-developer)  
+50. Best Online Community Platforms for US Founders in 2026 \- Fueler, дата последнего обращения: мая 12, 2026, [https://fueler.io/blog/best-online-community-platforms-for-us-founders](https://fueler.io/blog/best-online-community-platforms-for-us-founders)  
+51. How Non-Tech Entrepreneurs Can Create AI Startups \- Momen.app, дата последнего обращения: мая 12, 2026, [https://momen.app/blogs/non-tech-founders-build-ai-startups/](https://momen.app/blogs/non-tech-founders-build-ai-startups/)  
+52. Developer recruitment strategies for 2026 | daily.dev, дата последнего обращения: мая 12, 2026, [https://recruiter.daily.dev/resources/developer-recruitment-strategies-2026/](https://recruiter.daily.dev/resources/developer-recruitment-strategies-2026/)  
+53. The 2026 AI Job Disruption Report: Which Roles Are Being Eliminated, Which Are Being Created, and How to Position Yourself, дата последнего обращения: мая 12, 2026, [https://www.aimagicx.com/blog/ai-job-disruption-report-roles-eliminated-created-2026](https://www.aimagicx.com/blog/ai-job-disruption-report-roles-eliminated-created-2026)  
+54. Comparison: Vibe coder vs. AI augmented developer | Knowledge \- Langmeier Backup, дата последнего обращения: мая 12, 2026, [https://www.langmeier-software.com/en/seiten/wissen/comparison-of-vibe-coder-vs-ai-augmented-developer](https://www.langmeier-software.com/en/seiten/wissen/comparison-of-vibe-coder-vs-ai-augmented-developer)  
+55. 20 Tech Leaders Reveal How AI Is Transforming Software Development | ITProfiles, дата последнего обращения: мая 12, 2026, [https://itprofiles.com/resources/how-ai-is-transforming-software-development](https://itprofiles.com/resources/how-ai-is-transforming-software-development)  
+56. Will AI Replace Developers? The Real Truth \- SourceKode, дата последнего обращения: мая 12, 2026, [https://www.sourcekode.in/blog/chatgpt-copilot-replacing-developers-truth/](https://www.sourcekode.in/blog/chatgpt-copilot-replacing-developers-truth/)  
+57. Offshore Software Development in 2026: The No-BS Guide to Building a Remote Dev Team That Actually Ships | by Megha Verma | Predict \- Medium, дата последнего обращения: мая 12, 2026, [https://medium.com/predict/offshore-software-development-in-2026-the-definitive-guide-d81f3e822c95](https://medium.com/predict/offshore-software-development-in-2026-the-definitive-guide-d81f3e822c95)  
+58. How​‍​‌‍​‍‌​‍​‌‍​‍‌ to Hire AI Developers: The Complete 2026 Guide | Stackademic, дата последнего обращения: мая 12, 2026, [https://stackademic.com/blog/how-to-hire-ai-developers-the-complete-2026-guide](https://stackademic.com/blog/how-to-hire-ai-developers-the-complete-2026-guide)
\ No newline at end of file
diff --git a/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.04-competitor-courses-2026-forum-validated.md b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.04-competitor-courses-2026-forum-validated.md
new file mode 100644
index 000000000..d34aaf349
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.04-competitor-courses-2026-forum-validated.md
@@ -0,0 +1,355 @@
+# Forum-validated 2026 founder courses — landscape audit
+
+**Created**: 2026-05-15
+**Project**: 2605-tech-for-non-technical-founders
+**Purpose**: Validate or correct the JT course spine against 2026 best-in-class competitor courses, using forum endorsement signals to filter signal from noise.
+
+---
+
+## Source data
+
+Forum threads and sources consulted (May 2026):
+
+| Source | Query | Date range | Findings |
+|--------|-------|-----------|----------|
+| HN Algolia API | "non-technical founder" (stories) | 2024-01-01 to 2026-05-15 | 20 stories; highest-engagement items: Ask HN "I spent 12 months making every non-technical founder mistake" (Jan 2026), "Dev visibility for non-technical founders" (Jan 2026 × 3 variants); no course endorsements surfaced |
+| HN Algolia API | "non-technical founder course" (comments + stories) | 2024-present | 6 stories; 1 substantive result: Harvard Business School professor asking for AI validation examples (Oct 2024); no course endorsements |
+| Failory.com | Top 34 courses for entrepreneurs | 2025 updated | Shortlist: YC Startup School, 30x500, Pre-Sell to Validate, No Code MVP |
+| Failory.com blog community | Widely-linked in startup communities | 2025 | 30x500 ($1,999) and YC Startup School (free) were the two most-cited |
+| WeAreNoCode Disco.co case study | "450 founders in 26 countries" claim | 2025 | Social proof but not a forum endorsement thread |
+| Maven course ratings | Drew Falkman "Vibe Coding" + "AI Prototyping" | 2025 | 4.8/5 across hundreds of reviews; forum thread not found but rating volume is a quality signal |
+| Sophia Matveeva TechForNonTechies | Course page + LinkedIn | 2025 | Referenced in 10.03 Russian research; no independent Reddit thread found |
+| ProductHunt topic:education | Top-ranked courses | 2024-2025 | No founder-specific courses surfaced in top results; generic tools dominated |
+| LinkedIn / Lenny's Newsletter | Best-of 2025 + Maven listing | 2025 | Maven listed as primary course platform; no specific non-technical founder course endorsed |
+| First Round PMF Method | Program page | 2026 | Not forum-recommended — found via expert citation; included as structural reference only |
+
+**Forum search limitation note**: Reddit JSON API blocked direct fetching. Reddit forum threads were found via secondary sources (Failory, SubredditSignals, contextual articles) rather than direct thread scraping. HN threads had zero course endorsements for non-technical founders in 2025-2026. Course recommendations surfaced primarily through curated lists (Failory), course platform ratings (Maven), and operator citations (Disco.co case study).
+
+---
+
+## Shortlist — 7 courses
+
+| # | Course name | URL | Source signal | Endorsement signal | Format | Price |
+|---|-------------|-----|--------------|-------------------|--------|-------|
+| 1 | YC Startup School | [startupschool.org](https://www.startupschool.org/) | Failory top-5; Indie Hackers default rec; HN cited repeatedly in community discussion | Default recommendation across r/Entrepreneur, r/startups, Indie Hackers; most-cited free course in founder communities | Self-paced video + weekly check-ins, 7 weeks | Free |
+| 2 | 30x500 Academy | [30x500.com/academy](https://30x500.com/academy/) | Failory top-3; Amy Hoy has strong following in bootstrapped founder communities; indie hackers canonical | Consistently cited on Indie Hackers and bootstrapped-founder circles for customer-discovery methodology | Self-paced (~40 hrs, ~100 lessons) | $1,999 (or $399 × 6 mo) |
+| 3 | WeAreNoCode AI Startup Bootcamp | [wearenocode.com/the-ai-startup-accelerator](https://www.wearenocode.com/the-ai-startup-accelerator) | Disco.co case study (450 founders / 26 countries); Lovable Discord community overlap; 2026 stack (Lovable + Supabase + Claude API) | Growing community signal in Lovable Discord (160K members) and no-code founder communities; most structurally complete 2026 program found | 6-week live cohort (Pro, $8,999) or self-paced ($999) | $999-$8,999 |
+| 4 | Tech for Non-Technical Founders (Sophia Matveeva) | [techfornontechies.co/tech-for-non-technical-founders](https://www.techfornontechies.co/tech-for-non-technical-founders) | HBR / Oxford / LBS references; Russian 2026 ecosystem research (#1 strategic-management option); cited in 10.03 | Named as the dominant "strategic management" option in 2026 ecosystem research; no Reddit thread found but repeated in practitioner circles | Self-paced + 1:1 coaching; lifetime access | $2,500-$3,500 |
+| 5 | Vibe Coding Data-Enabled AI Apps (Drew Falkman / Maven) | [maven.com/drewfalkman/vibe-coding-for-non-technical-founders](https://maven.com/drewfalkman/vibe-coding-for-non-technical-founders) | 4.8/5 on Maven (hundreds of reviews); cited in 10.03 Russian ecosystem research as #1 independent-prototyping option | Maven rating volume is the proxy for community endorsement (no subreddit thread found); strongest rating of any technical course for non-technical founders | Live cohort, 4 weeks, 1-3 hrs/week | Not disclosed publicly |
+| 6 | Founder Institute Vibecode Bootcamp | [fi.co/bootcamp/vibecoding](https://fi.co/bootcamp/vibecoding) | Institutional (FI, 9,000+ portfolio companies); Trustpilot positive reviews; June 2026 cohort | Trustpilot reviews positive; referenced across vibe-coding discussions; $449 is accessible price point with known institutional brand | Virtual, 2 weeks (4 live sessions), ~20 hrs total | $449 |
+| 7 | First Round PMF Method | [firstround.com/pmf](https://www.firstround.com/pmf) | First Round Capital institutional endorsement; targeted at early B2B SaaS founders | Not Reddit-recommended; included as structural reference because it is the only program with an explicit "distribution before first customer" module | In-person 4-day retreat (Sonoma) + follow-up | Free (travel only); B2B SaaS, <$2M raised |
+
+**Rejected (with reasons)**:
+- Maven PM Fundamentals (Lenny Rachitsky): PM-focused, not founder-focused; no non-technical founder validation
+- Udemy / Sramana Mitra: Listed in 10.01; forum endorsement minimal; purely self-paced video without community
+- No Code MVP (Bram Kanstein): Failory-listed but site returned 403; no forum thread found; likely dormant
+- Pre-Sell to Validate (Failory): $100, niche; single-topic (pre-sales only), not a spine
+- Lean Startup online courses (edX, Acumen): Too generic, not founder-specific in 2026 context
+
+---
+
+## Strongest 5-7 courses — spine extraction
+
+### 1. YC Startup School (free, 7 weeks)
+
+**Stated outcome**: "Idea to early traction through disciplined execution." Graduate knows how to evaluate an idea, build an MVP, and find users.
+
+**Module spine** (reconstructed from public reviews and official materials):
+- Week 1: Before the Startup / Good Startup Ideas
+- Week 2: How to Talk to Users
+- Week 3: All About Pivoting / Cofounder relationships
+- Week 4: How to Build an MVP
+- Week 5: How to Launch
+- Week 6: Growth / Sales
+- Week 7: Fundraising / Company building
+
+**Time**: 7 weeks at 1-2 hrs/week (~10-15 hrs total)
+
+**Build-yourself?**: Teaches founder to ship an MVP; does not teach specific build tools (no Lovable/Supabase stack); emphasis on shipping fast regardless of stack
+
+**Rescue path?**: No. No module on what to do when a build fails, dev shop relationship breaks, or code ownership is unclear.
+
+**Pricing coverage?**: Light — business models discussed, but pricing-as-hypothesis is not a standalone step.
+
+**Distribution coverage?**: Week 6 covers growth and sales but no dedicated channel-market fit step between MVP and first customer.
+
+---
+
+### 2. 30x500 Academy (paid, $1,999, self-paced ~40 hrs)
+
+**Stated outcome**: Graduate can "design a product and ask your audience for money" based on audience research. Assumes you already have a skill to productize.
+
+**Module spine**:
+- Part 1: Read Their Minds — Sales Safari (market research methodology), email list building, content creation ("Ebombs")
+- Part 2: Build the Business — Product design from research, persuasive sales copy, launch planning and execution
+
+**Time**: ~40 hrs self-paced; no fixed completion deadline
+
+**Build-yourself?**: No. Assumes you can already deliver the service/product. Teaches WHAT to build, not HOW to build a technical product.
+
+**Rescue path?**: No. No coverage of failed builds or technical problems.
+
+**Pricing coverage?**: Yes — pricing emerges naturally from the Sales Safari methodology (charge what the audience's pain signals warrant). Not explicit "pricing as hypothesis" framing but the methodology implies it.
+
+**Distribution coverage?**: Yes — the entire Part 1 is pre-build audience research and distribution positioning. This is the strongest "distribution-before-product" course in the shortlist.
+
+**Spine summary**: Problem research → audience building → product design from signal → sales copy → launch. Very strong on customer signal BEFORE building. Weak on technical building, rescue, AI-era.
+
+---
+
+### 3. WeAreNoCode AI Startup Bootcamp (6 weeks live, $8,999 Pro / $999 self-paced)
+
+**Stated outcome**: "A launched product, paying customers, lifetime access to materials, and continued access to the private community."
+
+**Module spine**:
+- Phase 1: Validate — pressure-test the idea; outcome: "validated problem, clear customer profile, signal to build or pivot"
+- Phase 2: Build — ship production-ready product using Lovable, Supabase, Claude API; outcome: "production-grade product live with early users inside it"
+- Phase 3 (Polish & Launch, Week 3): debugging, AI evals, deployment, soft-launch to waitlist
+- Phase 4: Monetize - Create Demand — brand, outbound via Bond, content foundation
+- Phase 5: Monetize - Convert Demand — sales structure, outcome-based pricing, objection handling, closing
+- Phase 6: Automate — recurring task automation with Cowork MCPs
+
+**Time**: 6 weeks, 10-15 hrs/week (Pro); self-paced standard is 4-8 weeks
+
+**Build-yourself?**: Yes. Explicit — Lovable + Supabase + Claude API stack taught hands-on.
+
+**Rescue path?**: Partial — covers "the 30% gap AI tools can't handle" (database, auth, payments, deployment, security) but no dedicated rescue/salvage-vs-rebuild module.
+
+**Pricing coverage?**: Yes — explicit "outcome-based pricing" module in Phase 5. One of two courses in the shortlist with dedicated pricing instruction.
+
+**Distribution coverage?**: Yes — outbound campaigns and content foundation in Phase 4. But no dedicated channel-market fit step.
+
+**Spine summary**: Validate → Build (self-serve, Lovable stack) → Polish → Create Demand → Convert Demand → Automate. The most complete 2026 spine in the shortlist. Pricing and sales explicit; rescue absent.
+
+---
+
+### 4. Tech for Non-Technical Founders (Sophia Matveeva, $2,500, self-paced + coaching)
+
+**Stated outcome**: "Launch apps and platforms real users love and pay for. Build confidence to lead technical teams without getting lost in jargon."
+
+**Module spine**:
+- Module 1: Map Your Idea Into a Clear Product Plan
+- Module 2: Design Products Users Actually Understand and Love
+- Module 3: Build Your First Version With AI and No-Code Tools
+- Module 4: Understand the Tech Stack & Learn to Work with Developers
+- Module 5: Get Your First Users and Build Growth Into Your Product
+- Module 6: Use Data and AI to Keep Improving Your Product
+
+**Time**: 3-4 hrs/week for first 3 weeks + coaching sessions; self-paced thereafter
+
+**Build-yourself?**: Yes (Module 3). Dual-track: also teaches how to manage developers (Module 4).
+
+**Rescue path?**: No. No coverage of failed builds, salvage, or dev shop management when things break.
+
+**Pricing coverage?**: No explicit module; implied in Module 5 ("first users and growth") but not a standalone step.
+
+**Distribution coverage?**: Module 5 covers user acquisition and growth. No pre-build channel-market fit step.
+
+**Spine summary**: Idea → UX design → AI/no-code build → developer management → user acquisition → data-driven improvement. Balanced build + manage approach. Missing: pricing, rescue, AI-era risks.
+
+---
+
+### 5. Vibe Coding Data-Enabled AI Apps (Drew Falkman / Maven, 4 weeks, 1-3 hrs/week)
+
+**Stated outcome**: "A master vibe coder with your own fully-featured and working application live."
+
+**Module spine** (partially visible — full syllabus behind registration):
+- Week 1: Product Strategy + Kickoff (7 items)
+- Week 2: Vibe Coding the UI (4 items) + optional troubleshooting
+- Week 3: Database design (Supabase, SQL fundamentals)
+- Week 4: AI API integration (ChatGPT, Claude), third-party integrations (Stripe, email), GitHub deployment
+
+**Time**: 4 weeks, 1-3 hrs/week live + 1-3 hrs/week building
+
+**Build-yourself?**: Yes — the entire course is hands-on building.
+
+**Rescue path?**: Partial — optional troubleshooting sessions; teaches "how to debug with confidence and avoid getting caught in debug loops" but no rescue/rebuild framework.
+
+**Pricing coverage?**: No.
+
+**Distribution coverage?**: No. The course ends at "working application live" — getting to first customer is out of scope.
+
+**Spine summary**: Product strategy → UI build (Lovable) → database → AI API → integrations → deployment. Pure build track. Missing: validation, pricing, distribution, first customer, rescue.
+
+---
+
+### 6. Founder Institute Vibecode Bootcamp ($449, 2 weeks / 4 live sessions)
+
+**Stated outcome**: "A working product in front of real potential customers" and "real feedback to help you decide whether to keep going, pivot, or try a different idea."
+
+**Module spine**:
+- Day 1 (Week 1, Wed): Kickoff — scope the idea, set up AI toolkit
+- Day 3 (Week 1, Fri): Build — AI product-building techniques, no-code app
+- Day 8 (Week 2, Wed): Refine — polish features, test integrations
+- Day 10 (Week 2, Fri): Launch — deploy, gather real-customer feedback
+
+**Time**: 2 weeks, ~20 hrs total
+
+**Build-yourself?**: Yes — hands-on building throughout.
+
+**Rescue path?**: No.
+
+**Pricing coverage?**: No.
+
+**Distribution coverage?**: Partial — "develop your customer outreach plan" mentioned but no systematic channel instruction.
+
+**Spine summary**: Scope → Build → Refine → Launch. The shortest and most stripped-down spine. Good for fast first product but skips validation, pricing, and distribution entirely.
+
+---
+
+### 7. First Round PMF Method (free, 4-day in-person retreat, B2B SaaS only)
+
+**Stated outcome**: Graduate can land initial enterprise contracts and build repeatable go-to-market approaches.
+
+**Module spine**:
+- Session 1: Levels of PMF (four maturity levels, case studies)
+- Session 2: Discovery & The 4Ps — "dollar-driven discovery" around persona, problem, promise, product
+- Session 3: Market Selection — viability and path to $100M+ ARR
+- Session 4: Founder-Led Sales — outreach, funnel management, initial design partners
+- Session 5: Positioning — messaging and differentiation
+- Session 6: Product Iteration & Pivots — MVP development, success metrics, pivot indicators
+
+**Time**: 4 days intensive + follow-up sessions
+
+**Build-yourself?**: No — strategy and sales focused.
+
+**Rescue path?**: Partial — Session 6 covers pivots and pivot indicators.
+
+**Pricing coverage?**: Embedded in Sessions 2-4 ("dollar-driven discovery") but not a standalone pricing-as-hypothesis module.
+
+**Distribution coverage?**: Yes — Session 4 (founder-led sales / design partners) explicitly bridges MVP to first revenue. The strongest distribution-to-revenue instruction of any course in the shortlist.
+
+---
+
+## Comparison matrix vs JT
+
+JT module on left. Competitor analog on right. "–" = no analog found.
+
+| JT Module | YC SS | 30x500 | WeAreNoCode | Sophia M | Falkman | FI Vibecode | FR PMF |
+|-----------|-------|--------|-------------|----------|---------|-------------|--------|
+| M0 · Where Are You? (self-assessment) | – | – | – | – | – | – | – |
+| M1 · Form Hypothesis (Assumption Map) | Week 1 (idea eval) | – | Phase 1 (validate) | M1 (product plan) | Week 1 (product strategy) | Day 1 (scope) | S2 (4Ps discovery) |
+| M2 · Smoke-Test (landing page + paid traffic) | Week 4 (launch) | Part 2 (launch) | Phase 3 (soft-launch to waitlist) | – | – | Day 10 (launch) | – |
+| M3 · Validate the Problem (Mom Test interviews) | Week 2 (talk to users) | Part 1 (Sales Safari) | Phase 1 (customer profile) | M2 (UX design) | – | – | S2 (discovery) |
+| M4 · Design the Solution (Product Brief / Job Stories) | – | – | – | M1-M2 | Week 1 (product strategy) | Day 1 (scope) | S5 (positioning) |
+| M5 · Should You Hire? (build-vs-hire decision) | – | – | – | M3-M4 (both paths) | – | – | – |
+| M6.1 · Ownership Audit (GitHub/AWS) | – | – | – | – | – | – | – |
+| M6.2 · Org Chart | – | – | – | M4 (dev management) | – | – | – |
+| M6.3 · Friday Demo Rule | – | – | – | – | – | – | – |
+| M6.4 · Three Standup Questions | – | – | – | – | – | – | – |
+| M6.5 · Weekly Dev Report | – | – | – | – | – | – | – |
+| M6.6 · Spaceship Audit (over-engineering) | – | – | – | – | – | – | – |
+| M6A · Self-Serve MVP Stack (Lovable/Supabase/Stripe) | Light (MVP) | – | Phase 2 (Lovable+Supabase+Claude) | M3 (AI/no-code) | Core (Lovable+Supabase) | Core (AI build) | – |
+| M6A.2 · Ceiling Signals (when to stop self-serving) | – | – | – | M4 (dev handoff) | – | – | – |
+| M6B · Hire Smart (AI-Augmented Dev profile + offshore) | – | – | – | – | – | – | – |
+| M6B.2 · Fractional CTO Bridge | – | – | – | – | – | – | – |
+| M6B.3 · Hiring Interview (catches AI theater) | – | – | – | – | – | – | – |
+| M6B.4 · Cheap Developers Get Expensive | – | – | – | – | – | – | – |
+| M6B.5 · Reading the SOW | – | – | – | – | – | – | – |
+| M7.1 · First Customer Is Not Marketing | – | Week 6 (sales light) | Phase 4-5 (demand+sales) | M5 (first users) | – | Day 10 (feedback) | S4 (founder-led sales) |
+| M7.2 · First Ten From Network | – | – | – | – | – | – | S4 |
+| M7.3 · Charge Before You Ship | – | Light (Part 2 launch) | Phase 5 (outcome-based pricing) | – | – | – | S2 (dollar-driven) |
+| M7.4 · Outbound Without Sales Team | – | – | Phase 4 (Bond outreach) | – | – | – | S4 (outreach + funnel) |
+| M7.5 · Churn Triage Before Acquisition | – | – | – | M6 (data + AI improvement) | – | – | – |
+| M7.6 · Pivot or Persevere | Week 3 (pivoting) | – | Phase 1 (pivot signal) | – | – | Day 10 (pivot or keep going) | S6 (pivot indicators) |
+| M8.1 · Salvage or Rebuild? | – | – | – | – | – | – | – |
+| M8.2 · Switch Dev Shops Safely | – | – | – | – | – | – | – |
+| M9.1 · Agency AI Follow-Up Questions | – | – | – | – | – | – | – |
+| M9.2 · The AI Token Bill | – | – | – | – | – | – | – |
+| M9.3 · Slopsquatting | – | – | – | – | – | – | – |
+
+**JT-unique modules with zero competitor analog (confirmed across all 7 courses)**:
+- M0 (self-assessment / course map)
+- M6.1 (GitHub/AWS ownership audit)
+- M6.3 (Friday Demo Rule)
+- M6.4 (Three Standup Questions)
+- M6.5 (Weekly Dev Report template)
+- M6.6 (Spaceship Audit / over-engineering)
+- M6B (entire hire-smart track: AI-Augmented Dev, fractional CTO, SOW reading, cheap developer trap)
+- M8.1-8.2 (entire rescue module)
+- M9.1-9.3 (entire AI-era module)
+
+**Competitor modules with NO JT analog (gaps)**:
+See next section.
+
+---
+
+## Missing logical sequence
+
+The following gaps are each supported by 2+ competitor courses having the step and JT not having it.
+
+### Gap 1 — Pricing as a standalone hypothesis step
+
+**Supported by**: WeAreNoCode (Phase 5: "outcome-based pricing" module), First Round PMF Method (Session 2: "dollar-driven discovery" as first discovery act), 30x500 (pricing emerges from Sales Safari signal as a core deliverable of Part 1).
+
+**Where it sits**: Between M4 (Product Brief) and M7.3 (Charge Before You Ship). JT's M7.3 says "charge before you ship" but treats it as a tactic, not a hypothesis. None of JT's modules ask: "What price signal does this customer segment actually give us before we build?"
+
+**Specific gap**: JT has no module that asks the founder to set a price hypothesis and test it — e.g., mention a price in the smoke-test landing page (M2) and track click-through to a Stripe payment form. WeAreNoCode builds this into Phase 5 explicitly. First Round PMF builds it into Session 2 as "dollar-driven discovery."
+
+### Gap 2 — Distribution / channel strategy as a dedicated step between MVP and first customer
+
+**Supported by**: First Round PMF Method (Session 4: founder-led sales, design partners, outreach funnel — explicitly placed before first revenue), WeAreNoCode (Phase 4: outbound campaigns + content foundation as distinct step before Phase 5 sales conversion), 30x500 (entire Part 1 is audience-building and distribution positioning before any product is built).
+
+**Where it sits**: Between M6 (Build) and M7.1 (First Customer Is Not Marketing). JT jumps from "your build is done" to "here's how to get your first customer" without a dedicated step asking: "Which channel will this specific product reach buyers through, and how do you verify that hypothesis before spending money on outreach?"
+
+**Specific gap**: No JT module covers channel-market fit. M7.4 (Outbound Without Sales Team) covers tactics but is not sequenced as a "choose your channel before you launch outbound" decision point. 30x500 and First Round PMF both front-load this decision.
+
+### Gap 3 — Build-it-yourself prototype as a third validation pillar (not just landing page + interviews)
+
+**Supported by**: WeAreNoCode (Phase 2 explicitly: Lovable + Supabase MVP as validation tool, not just shipping), Drew Falkman on Maven (AI Prototyping course: "build prototype, attach to user research"), Sophia Matveeva (Module 3: build with AI/no-code tools, then Module 4: transition to developer management). All three treat the clickable prototype as a distinct validation act — separate from the smoke-test landing page and separate from the Mom Test interviews.
+
+**Where it sits**: JT has M2 (smoke-test landing page) and M3 (Mom Test interviews). The build-it-yourself clickable prototype — specifically the Lovable/v0/Bolt prototype that lets real users interact with something, not just read copy — is not a standalone module. It appears inside M6A (Self-Serve MVP Stack) but by that point it is treated as the final product, not as a third validation pillar.
+
+**Specific gap**: No JT module says: "Before you commit to a build path, build a clickable prototype in Lovable (2 hrs, $0) and put it in front of 5 users from M3. What did they do? What did they not do?" This is the "rapid prototype as validation" step that 3+ competitor courses now teach as standard.
+
+---
+
+## Recommendations
+
+Ranked by leverage — how much improvement per change, given JT's existing 34-chapter structure.
+
+### R1 — Add a pricing hypothesis step inside Module 2 or as Module 2.2 (highest leverage)
+
+The smoke-test landing page (M2.1) already exists. Adding one module — "Set a price on the page and measure whether anyone clicks the payment button" — closes Gap 1 without new content structure. This is a 1-chapter add inside an existing module. WeAreNoCode and First Round PMF both treat pricing as discovery, not as a launch tactic. JT currently teaches it as a launch tactic (M7.3). Moving the first pricing signal to M2 (smoke-test) closes the sequence gap at minimal cost.
+
+**Concrete addition**: M2.2 — "Price It Before You Build It: Put a Real Number on Your Smoke-Test Page". Teaches founder to add a Stripe payment link (or fake checkout button with email-capture fallback) to the landing page from M2.1 and interpret clicks vs. form-fills as pricing signal.
+
+### R2 — Add a channel selection step as Module 7.0 (before M7.1-7.4)
+
+A single chapter — "Which channel will your first ten customers come from, and how do you know?" — inserts the channel-market fit decision before the outbound tactics. This directly closes Gap 2. First Round PMF (Session 4) and 30x500 (Part 1) both treat channel selection as a strategic decision, not a tactical execution. JT jumps to tactics. One chapter reframe: "Before you write your first cold email, answer three channel questions."
+
+**Concrete addition**: M7.0 — "Choose Your Channel Before You Launch Outbound". Covers: direct founder-led sales vs. content vs. community vs. SEO — which fits your price point, customer type, and founder time budget? Links to M7.2 (network) and M7.4 (outbound) as channel-specific executions.
+
+### R3 — Add a clickable prototype step as Module 4.3 (third validation pillar)
+
+Insert between M4 (Product Brief) and M5 (Should You Hire?) a single chapter: "Build a Lovable Prototype in Two Hours Before You Commit to a Build Path." This closes Gap 3 by making the clickable prototype a validation act, not a build act. The prototype is not M6A (the real product); it is a throwaway artifact that tests whether users can self-serve through the core job-to-be-done. If they can't, the product brief (M4) needs revision.
+
+**Concrete addition**: M4.3 — "Two-Hour Prototype: Validate the Flow, Not the Feature List". Teaches founder to use Lovable (or v0 for UI-only) to create a clickable mock, share with 5 users from M3 outreach, observe where they get stuck. This aligns with the Drew Falkman "AI Prototyping" course (which explicitly attaches prototype to user research) and with WeAreNoCode Phase 2.
+
+### R4 — Consider Module 7.5 (Churn Triage) before M7.4 (Outbound)
+
+Currently: M7.4 (Outbound) → M7.5 (Churn Triage). The sequence implies: get customers → then worry about churn. WeAreNoCode sequences it as: convert demand → then automate retention. First Round PMF has no churn module. But the product logic argues for: M7.3 (Charge Before You Ship) → M7.5 (Churn Triage: what are the early signs this isn't working?) → M7.4 (Outbound: only scale outbound if churn signal is acceptable). Low cost change — reorder two existing modules. Not supported by 2+ competitor analogs for the specific reorder, so this is a JT-judgment call, not a competitor-validated gap.
+
+### R5 — Flag the rescue path (M8) as a JT competitive moat, not a gap
+
+Zero competitor courses cover salvage vs. rebuild, switching dev shops safely, or the AI-era risks (M9). This is confirmed white space. The recommendation from this research: do not add a competitor analog to these modules. They are JT's unique differentiator. The gap is upstream (pricing, channel, prototype validation); the rescue modules are the reason JT can credibly teach those upstream steps — because JT has seen what happens when founders skip them.
+
+---
+
+## Sources
+
+1. [Failory — Best 34 Online Courses for Entrepreneurs 2025](https://www.failory.com/blog/courses-for-entrepreneurs)
+2. [30x500 Academy](https://30x500.com/academy/)
+3. [WeAreNoCode Academy](https://www.wearenocode.com/academy)
+4. [WeAreNoCode Disco.co case study](https://www.disco.co/blog/how-wearenocodes-learning-community-helped-450-global-founders-launch-businesses-no-coding-required)
+5. [Tech for Non-Technical Founders — Sophia Matveeva](https://www.techfornontechies.co/tech-for-non-technical-founders)
+6. [Drew Falkman — Vibe Coding Data-Enabled AI Apps (Maven)](https://maven.com/drewfalkman/vibe-coding-for-non-technical-founders)
+7. [Drew Falkman — AI Prototyping and User Validation (Maven)](https://maven.com/drewfalkman/rapid-ai-prototyping-user-validation-product-managers-designers)
+8. [Founder Institute Vibecode Bootcamp](https://fi.co/bootcamp/vibecoding)
+9. [First Round PMF Method](https://www.firstround.com/pmf)
+10. [YC Startup School](https://www.startupschool.org/)
+11. [Lenny's Newsletter Best of 2025](https://www.lennysnewsletter.com/p/best-of-lennys-newsletter-2026)
+12. [Maven courses listing](https://maven.com/lenny)
+13. HN Algolia API — "non-technical founder" stories, Jan 2024 - May 2026
+14. [Best Subreddits for Startup Founders 2026](https://www.thevccorner.com/p/20-best-subreddits-for-startup-founders-2026)
+15. [Immerse Education — YC Startup School Review 2026](https://www.immerse.education/knowledge-base/y-combinator-startup-school-review-2026/)
diff --git a/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.05-content-organization-patterns-2026.md b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.05-content-organization-patterns-2026.md
new file mode 100644
index 000000000..e79437d6c
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.05-content-organization-patterns-2026.md
@@ -0,0 +1,248 @@
+# Content Organization Patterns — 2026 reference courses
+
+**Date:** 2026-05-18
+**Purpose:** Distill paragraph-level + page-level content-organization rules from popular long-form courses/newsletters, then apply to JT course chapters for better reading experience and learning effectiveness.
+**Predecessors:**
+- `10.04-competitor-courses-2026-forum-validated.md` (spine-level structure)
+- `20.09-spine-3-rollout-design.md` (the JT 6-module spine)
+
+## Sources consulted
+
+| Source | URL | Why |
+|---|---|---|
+| Refactoring (Luca Rossi) | [refactoring.fm/p/from-engineer-to-manager-to-director](https://refactoring.fm/p/from-engineer-to-manager-to-director) | User-validated reference. 170K+ engineering audience, long-form essays. Modern infographic style. |
+| Lenny's Newsletter (Lenny Rachitsky) | [lennysnewsletter.com/p/state-of-the-product-job-market-in-ee9](https://www.lennysnewsletter.com/p/state-of-the-product-job-market-in-ee9) | Gold standard for PM/founder long-form. Recent (2026 Q1). Heavy data-viz. |
+
+(First Round Review attempted; could not locate live representative post via search. WeAreNoCode + Sophia Matveeva content largely behind paywall. The two sources above gave high-convergence findings, so additional triangulation was deferred.)
+
+## Pattern findings — convergent across both sources
+
+### Paragraph length
+
+- Average: **2-3 sentences per paragraph**
+- Range: 1-4 sentences (4+ is an outlier)
+- 1-sentence paragraphs used DELIBERATELY for emphasis (single insights)
+
+### Heading frequency
+
+- Reference: **~200-250 words between headings** (H3 dominant; H2 only for major phase shifts)
+- Lenny's: 7 H3s in a single post, no H2s — pure scannable subsections
+- Refactoring: H2 for top-level phase, H3 for steps within each phase
+
+### Callouts / blockquotes
+
+- **Sparse use** — 1-2 per post
+- Purpose: pull-out a key insight OR quote an expert (not decoration)
+- NEVER used to make the post "look structured"
+
+### Bullet lists vs prose
+
+- 15-40% bullets, rest prose
+- Bullets reserved for genuine lists (parallel items)
+- Each H3 section typically has 1 bullet group
+
+### Lead paragraph (opening hook)
+
+- **Counter-intuitive claim** OR **specific anecdote** OR **named contradiction-of-expectations**
+- Never: "in this post we'll cover..." OR "before we begin..."
+- Lenny's example: "Welcome to our biannual State of the Product Job Market — our fourth and, very surprisingly, the most optimistic"
+- Refactoring's example: "Last month I published a big guide about how you should navigate your career. This is the time of the year where many of us pause and reflect on their journey"
+
+### Closing paragraph
+
+- Forward-looking sentiment + concrete next-step
+- Sometimes deliberately cuts off to drive subscription (newsletter-specific; not a course pattern)
+- For courses, close should link to next module + name the deliverable that's now ready
+
+### Visual breaks
+
+- **One visual element per H3 section** — chart, table, diagram, or formatted callout
+- Refactoring uses small embedded images/charts; Lenny uses data viz (line graphs, trend charts)
+- Plain-text stretches longer than 2 H3 sections without a visual = density problem
+
+### Progressive disclosure
+
+- Use of "Advanced" sidebars at end of post for optional deep-dive content
+- Inline "skip if you know X" markers at section starts (Refactoring uses this)
+- Collapsible sections rare in newsletters (paywall handles this); useful for courses
+
+## Distilled rules for JT chapters
+
+1. **Max 4 sentences per paragraph.** Break longer ones at natural clause boundaries.
+2. **Heading every ~200-300 words** within long H2 sections — use H3 subheadings.
+3. **Lead with counter-intuitive claim OR specific anecdote.** Never throat-clearing.
+4. **Blockquote ONLY for pull-out emphasis or examples** (not decoration).
+5. **Close every chapter with concrete next-step + explicit link to next module.**
+6. **One visual break per H2 section** — table, diagram, or formatted code/quote. Plain prose blocks ≥3 H2s in a row = density problem. (Tracked separately in task #54 for course-wide rollout.)
+7. **Sentence-length variation** — alternate short (5-8 words) and long (15-25). Avoids monotone rhythm.
+8. **Bullet lists for parallel items only** — not for "make it look structured."
+9. **Progressive disclosure** — Advanced sidebars at end of post for optional deep-dive content (frameworks, tools, extended reading).
+
+## JT chapter audit — current state vs reference patterns
+
+Audit performed on `content/blog/form-your-founding-hypothesis-90-minute-sprint/index.md` (3204 words):
+
+| Pattern | Reference | JT (pre-fix) | Gap |
+|---|---|---|---|
+| Avg sentences/paragraph | 2-3 | 2 median + 6 outliers at 4-6 | minor — trim 6 long paragraphs |
+| Heading frequency (words between) | ~200-250 | ~460/H2 + 0 H3 | **big — needed ~7 more H3 subheadings** |
+| Lead hook | Counter-claim OR anecdote | "Everyone has a hypothesis. Few have it written" (counter-claim) | ✓ matches |
+| Blockquote count | Sparse (1-2) | 11 (mostly worked examples — justified for template-heavy chapter) | ✓ different use case OK |
+| Bullet ratio | 15-40% | ~20% | ✓ matches |
+| Visual breaks | One per H3 section | 0 SVGs (just-replaced) + 2 tables + cover | ⚠ acceptable; track sitewide |
+
+**Biggest gap:** heading hierarchy. Chapter had 7 H2s with 0 H3s — reference courses use ~16 H3s at this word count.
+
+## Application example (proof-of-pattern)
+
+Applied rules 1, 2, 5, 8 to `content/blog/form-your-founding-hypothesis-90-minute-sprint/index.md`:
+
+- Added 16 H3 subheadings within long H2 sections (Sprint steps, Magic Lenses, Founding Hypothesis examples, routing rule)
+- Promoted bold paragraph-leaders (`**Step 1 - The Basics**`) to H3s for visual scannability
+- Split 3 long paragraphs at natural clause boundaries
+- Added bullet list in Step 1 (the four "five entries" items) — parallel list, better as bullets than prose
+- Added bullet list in Step 4 (the four lenses with one-line questions)
+- Added bullet list in Magic Lenses "routing rule" (4 lens-conditional outcomes)
+- Verified close already has concrete next-step links to Modules 2 + 3
+
+Heading density: 1/460 words → ~1/170 words (matches reference).
+
+Commit: see `content(course): apply content-organization patterns (paragraph length, heading density, callouts)` on `module-8-first-paying-customer`.
+
+## Pending sitewide rollout
+
+- Task #54: visual breaks — add diagram/table/chart per H2 across remaining 16 course chapters
+- Apply this audit to other course chapters (17 in spine + 5 supplementary) when ready
+- Re-fetch additional reference posts if rule-set needs refinement (First Round Review, 30x500, Drew Falkman Maven)
+
+---
+
+## Part 2: Attention research (added 2026-05-19)
+
+Extending the content-organization research with attention-science findings. Triggered by the landing page audit: 1,339 words, 0 in-body images, 15+ repetitive bullet-list sections — the exact shape that triggers F-pattern dropout per NN/g eye-tracking research.
+
+### Sources
+
+| Source | URL | What it documents |
+|---|---|---|
+| Gloria Mark, UC Irvine (via State of Surveillance 2026) | https://stateofsurveillance.org/articles/corporate/attention-span-research-goldfish-myth-2026/ | Longitudinal screen-attention data: 2.5 min (2004) → 75s (2012) → 47s (2024) → 43s (2026) |
+| Pew Research / Digital Wellness Foundation 2026 | https://www.amraandelma.com/user-attention-span-statistics/ | 2.1M users; effective engagement window = 7.8 seconds; 71% scroll past within 3 seconds without a visual hook |
+| Nielsen Norman Group (Jakob Nielsen, Kara Pernice) | https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/ | F-pattern eye-tracking: long paragraphs + repetitive lists trigger "give up + vertical scan only" dropout. Short paragraphs + visual breaks → "layer-cake" pattern |
+| Cognitive Load Theory (John Sweller, 1988-) | https://thedecisionlab.com/reference-guide/psychology/cognitive-load-theory | Working memory is the bottleneck. Labels-IN-diagram beat labels-on-side (split-attention effect). Multimodal (text+visual) expands processing capacity |
+| EIM Partnerships - Less Is More | https://eimpartnerships.com/articles/less-is-more-reducing-cognitive-load-to-improve-learning | Visual aids reduce cognitive load when placement is integrated; decorative visuals do not |
+
+### Key findings — convergent across sources
+
+#### Attention windows
+- **First 3 seconds** decide stay-or-scroll on text-heavy pages (Pew 2026)
+- **Average per-screen attention: 43 seconds in 2026** (Gloria Mark)
+- **Engagement window after initial hook: 45+ min → cognitive fatigue** (heavy social-media users; lighter for high-intent readers)
+- High-intent readers (came looking for a solution to a current problem) get a longer window — but ONLY if the first visual confirms "this is for me"
+
+#### F-pattern reading (NN/g)
+- Users read horizontally across the top, then drop down, then vertical-scan the left edge
+- Long paragraphs → extreme F-pattern → reader gives up reading entirely, just scrolls
+- Short paragraphs + clear H2/H3 + visual breaks → "layer-cake" pattern (reader reads each heading fully, then selectively reads supporting text)
+- **Repetitive list structure is the worst F-pattern offender** — visually identical bullet groups across multiple sections is what makes a reader scroll-skip
+
+#### Cognitive Load Theory (Sweller)
+- Working memory holds ~4 chunks at a time
+- **Labels-IN-diagram beats labels-on-side** (the split-attention effect) — a labeled flowchart works; a flowchart followed by a 200-word explanation doesn't
+- **Multimodal expands capacity** — auditory + visual channels don't compete; text + integrated visual processes faster than text alone
+- **Decorative visuals INCREASE load** without adding signal — only integrated, labeled visuals reduce load
+
+#### What this means for JT content
+
+For the ICP (non-technical founder in current operational stress):
+- High cognitive load already (running a company, screening agencies, reading invoices)
+- Visual aids that reduce parse effort win disproportionately
+- Decision-oriented mental state — every section needs to answer "what do I DO with this?"
+- Decision aids (flowcharts, checklists, tables) win over essays in any "do you have X?" or "if Y then Z" section
+
+### Distilled rules (visual-breaks edition)
+
+Extending the 9 paragraph/heading rules from Part 1 with media rules:
+
+10. **One visual break per H2 section.** Plain prose blocks ≥3 H2s in a row = density problem (re-states Part 1 rule 6 with research backing).
+11. **Hero area MUST have a visual within first 3 seconds of scroll.** First-3-seconds research is unambiguous. Pure text hero = guaranteed dropout for 71% of readers. Acceptable: roadmap diagram, infographic, hero illustration, or even a strong styled callout (NOT decorative photography).
+12. **Repetitive parallel sections (Module Index, Templates List, "5 Mistakes") MUST break into cards/grid/icons.** Single-column tables with 6+ rows + identical-format bullet lists with 6+ items both trigger F-pattern dropout. Break into card grids OR add per-item icons.
+13. **Decision-oriented sections MUST use decision-aid format.** Anywhere the page asks "if X then Y" (rescue triage, decision trees, scoring tables) — render as flowchart/table, not numbered list.
+14. **Labels INSIDE diagrams, not beside them.** Per Sweller's split-attention effect. A diagram with labeled nodes + arrows reduces load; a diagram followed by a 200-word "what this shows" paragraph increases load.
+15. **No decorative visuals.** Stock photography of "happy founders at laptops," abstract gradients, generic icon arrays without informational content — all violate the CLT integration rule. If removing the visual wouldn't lose information, the visual is decorative.
+
+### JT landing page audit (proof-of-pattern)
+
+Audit of `content/blog/tech-for-non-technical-founders-2026/index.md` (1,339 words):
+
+| Section | F-pattern risk | Required media |
+|---|---|---|
+| Hero ("Free. No signup.") | Low (short) | Yes — hero roadmap (rule 11) |
+| Why this course exists (5 mistakes) | Medium (parallel list) | Yes — icon row (rule 12) |
+| What you walk away with (6 artifacts) | Medium | Yes — artifact stack visual (rule 12) |
+| Module index (6 modules, ~400 words) | **High** | Yes — card grid (rule 12) |
+| Free templates (14-row table) | **High** | Yes — card grid with icons (rule 12) |
+| If your team is failing (6-step list) | Medium | Yes — decision tree (rule 13) |
+| Who built this | Low | Optional — trust card |
+
+**Biggest gaps**: hero (no visual hook at all) + Module Index (worst F-pattern offender by word count).
+
+### Recommended sequencing for landing page
+
+1. **Hero Roadmap** (highest leverage — changes 3-second decision for all readers)
+2. **Module Card Grid** (worst F-pattern offender by word count)
+3. Validate scroll-depth before adding more — visual variety helps, visual noise hurts
+4. Defer items 3-7 until 1+2 are proven on scroll-depth metric
+
+### Open questions (Part 2 additions)
+
+4. Should the Hero Roadmap pattern propagate to every chapter (each chapter's hero shows where it sits in the 6-module journey)? Recommend: yes, with a small "you are here" badge variant.
+5. Where to host scroll-depth analytics to validate the changes? GA4 already wired? Need to confirm.
+6. What's the right "decorative visual" tolerance for ICP-E? Current rule: zero. But hand-drawn Excalidraw-style sketches that ALSO carry information (per the form-your-founding-hypothesis chapter) blur the line — they're decorative-ish but also informative. Recommend: allow when sketch IS the diagram; reject when sketch is separate from the diagram.
+
+## Open questions
+
+1. Should the H3 promotion pattern apply to ALL chapters or only the longest ones? (Recommend: chapters >2000 words. Shorter chapters can stay flat.)
+2. Should "Advanced (optional sidebar)" sections themselves use H3s? (Recommend: yes for sidebars with 4+ items; no for shorter ones.)
+3. Should we add a TL;DR / "Key takeaways" callout at chapter start? (Refactoring sometimes uses; Lenny rarely. Defer until reader-feedback signal.)
+
+---
+
+## Part 3 — Voice patterns from real human practitioners (2026-05-23 fetch)
+
+User directive: stop trusting internal multi-agent panels alone; fetch real human-written courses on adjacent topics and analyze their voice as the benchmark.
+
+### Sources consulted
+
+| Source | Why it's on-topic | Format |
+|---|---|---|
+| Rob Fitzpatrick — momtestbook.com landing + Mom Test book copy | THE author on customer interviews for non-technical founders; teaches the exact "10 people with the problem" muscle | Book + workshop course |
+| Patrick McKenzie (patio11) — kalzumeus.com "Salary Negotiation" essay | Long-form essay teaching a sales/negotiation conversation skill to non-technical readers; widely cited as the practitioner-voice benchmark | Single ~6,000-word essay |
+| YC Startup School library — Eric Migicovsky "How to Talk to Users" | Direct topic match (validation interviews for non-technical founders) | Library essay |
+
+YC URL returned 404 on fetch (likely auth-gated as of 2026-05-23). Fitzpatrick + McKenzie produced strong convergent signal — sufficient for the pattern set.
+
+### Convergent patterns across Fitzpatrick + McKenzie
+
+| Pattern | What they do | What our course chapters do instead |
+|---|---|---|
+| Paragraph opening | Direct assertion or command. "Your negotiation doesn't happen in a vacuum." "Entrepreneurs are universally busy, yet odds are high that you're wasting huge amounts of time." | Sets up context first; the frame comes before the punch. |
+| Sentence-length variation | 40-word explainer slams into 4-word punchline ("Dude, it's five minutes."). | Uniform 18-22 word sentences. No punchlines. The lack of rhythm is itself an AI tell. |
+| Teaching device | Bad-message-then-fix. Show what the non-practitioner does wrong sentence-by-sentence, then the rewrite. | We show the GOOD answer in `[brackets]`. We never tear apart the bad version. |
+| Organizing structure | Around the reader's questions ("How do I X?") OR around the author's own scars ("I'd be a much wealthier man today if..."). | Around imperative steps with sub-bullets. Reader-shaped vs. author-shaped — both work; list-shaped reads as procedural / AI. |
+| Specificity | Named companies + exact dollar amounts. Real incidents with the speaker in dialog. | Anonymized ("A consumer-app founder we spoke with..."). Specific enough to pass slop-detector but generic enough to feel AI. |
+| Self-deprecation | "I'd be a much wealthier man today if I had done it that way." Author failures earn trust. | Zero author scars. Speaks from authority, not peer. |
+| Length | One long essay that feels like one human's voice (McKenzie) OR short vignette-anchored chapters (Fitzpatrick). | Medium-length lists with sub-bullets — the worst shape for trust (textbook, not handbook). |
+
+### Decision: apply 3 moves to Ch 2.2 first, then evaluate for other chapters
+
+1. **Drop the "## Why this matters in 2026" abstraction.** McKenzie + Fitzpatrick both refuse the preamble. The vignette opener (already in place from the 2026-05-23 restructure) should carry the chapter's stakes; the explicit "## Why this matters" section reads as throat-clearing.
+2. **Bad-message-then-fix as the primary teaching device for the 3-message sequence.** Add the BAD version a non-technical founder typically writes ("Hi, I'm building a tool that helps small businesses with invoicing — would you have 30 minutes to chat?") + sentence-by-sentence diagnosis + the rewrite. The reader learns by watching the diagnosis, not by copying the answer.
+3. **Reshape "## The 5-step outreach sequence" as 3 reader questions instead of 5 procedural steps.** "How do I find 10 people who actually have this problem?" (Steps 1-3) → "What do I write so they don't ignore me?" (Step 4) → "What if they're unreachable cold?" (Step 5). Same content, different shape — and the shape is what triggers the AI-feel.
+
+Trigger for propagating to other chapters: re-run the cold-eyes panel on Ch 2.2 post-application; if AI-feel score drops more than 20 points vs. baseline, propagate to Modules 1, 3, 4, 5 in the next sprint.
+
+### Open questions (Part 3 additions)
+
+7. Should the bad-message-then-fix device be used in every chapter that teaches a written artifact (cold message, landing page copy, interview script, founder-update email)? Recommend: yes, with the BAD version always shown first.
+8. The "questions not steps" reshape — does it work for chapters that are genuinely procedural (e.g. setting up a Stripe account)? Recommend: keep steps for genuinely sequential procedures; reshape to questions for chapters teaching judgment + craft.
+9. Is the author-scar pattern transferable to a multi-author course like this one, or does it require a single named voice? Defer; collect reader feedback first.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.08-validation-tools-analysis-2026.md b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.08-validation-tools-analysis-2026.md
new file mode 100644
index 000000000..5671352fb
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.08-validation-tools-analysis-2026.md
@@ -0,0 +1,162 @@
+# 10.08 — AI Validation Tools & 6-Week Launch System: Recommendations for the Course
+
+**Source:** `docs/_research/Валидация Бизнес-Идеи_ Система и Инструменты.md` (June 2026)
+**Analysis Date:** June 4, 2026
+**Status:** Analyzed — recommendations below
+
+---
+
+## What the Research Contains
+
+A 5,000-word Russian-language analysis of the 2026 business idea validation landscape, covering:
+
+1. **AI validation tool market** — 7+ platforms catalogued with accuracy scores, pricing, and zero-budget access tiers
+2. **No-Code MVP infrastructure** — Carrd, Framer, Tally, Airtable, Notion, Zapier, Make, Bolt.new, Lovable, Cursor
+3. **Validation psychology** — Mom Test methodology, founder-to-founder validation trap, echo chamber warning
+4. **SIPOC architecture** — Suppliers-Inputs-Process-Outputs-Customers framework for startup launch
+5. **6-week standardized validation system** — Zero-budget, evening-and-weekend compatible
+6. **Distribution channels** — Reddit/forum mining, Loom video outreach, engineering-as-marketing, build-in-public
+7. **29 sources** — Indie Hackers, Reddit, Product Hunt, VC.ru, Medium, YouTube
+
+---
+
+## What the Course Already Covers (No Action Needed)
+
+| Research Topic | Course Coverage |
+|---|---|
+| Mom Test methodology (5 rules) | Module 2 Ch 2.1 — deeper treatment |
+| No-Code landing pages (Carrd/Framer) | Module 1 Ch 1.2 |
+| Stripe Payment Links for price testing | Module 1 Ch 1.3 |
+| AI persona rehearsal | Module 2 Ch 2.2 |
+| Lovable + Supabase + Stripe self-serve stack | Module 4 Ch 4.3 |
+| Channel selection framework | Module 5 Ch 5.2 |
+| Paid pilot contracts (DPA) | Module 5 Ch 5.4 |
+| Outbound without sales team | Module 5 Ch 5.5 |
+
+---
+
+## Gaps & Recommendations
+
+### GAP 1: AI Validation Tools (Market Intel Pre-Hypothesis)
+
+**What's missing:** The course jumps from "have an idea" → "write a hypothesis in 90 minutes." The research argues founders should first mine Reddit/Quora/G2 for HOW real people describe their pain, using their exact vocabulary in the hypothesis and landing page.
+
+**Tool recommendations (from web research, June 2026):**
+
+| Tool | When to Use | Best For | Cost |
+|---|---|---|---|
+| **Perplexity** | First — before hypothesis | Competitor complaint mining, market landscape | Free tier sufficient |
+| **Trend Seeker** | First — before hypothesis | Semantic search for demand signals on Reddit/forums | Free daily limit |
+| **IdeaProof** | After Mom Test interviews | 4-model ensemble stress-test of business logic | 70 free credits |
+| **ValidatorAI** | Ideation sandbox | Rapid "devil's advocate" feedback, poking holes | Unlimited free |
+| **Preuve AI** | After validation, before build | Evidence-based reports for pitch decks | Free basic score |
+| **WorthBuild** | After validation | Lead-generation planning, auto-parsing social media | 1 free/mo |
+
+**Recommended flow** (from community consensus):
+1. **Perplexity + Trend Seeker** → map landscape, confirm people are complaining
+2. **ValidatorAI** → rapid stress-test, find blind spots
+3. **Human interviews (Mom Test)** → the irreplaceable step
+4. **IdeaProof** → ensemble validation of refined hypothesis
+5. **WorthBuild** → lead-gen setup for first customers
+
+**Critical community insight:** AI tools are for finding the "Why" — customer interviews (Mom Test) are for finding the "Who" and "Will they pay." AI is a force multiplier, not a replacement.
+
+**Recommendation:** Add a **"AI Research: Mine the Market Before You Write the Hypothesis"** sidebar to Chapter 1.1 with the Perplexity/Trend Seeker workflow and the verbatim-quote extraction technique. Add an **"Advanced: AI Stress-Testing Your Hypothesis"** sidebar to Chapter 2.2 referencing IdeaProof's ensemble approach.
+
+---
+
+### GAP 2: "Wizard of Oz" No-Code Stack (Concierge MVP)
+
+**What's missing:** The course path is: Carrd landing page → Lovable + Supabase code build. There is no intermediate step for founders who want to validate with a "fake backend" before writing application code.
+
+**The stack:**
+1. **Tally** — form builder for data collection (free, no logic limits)
+2. **Zapier / Make.com** — routes form submissions to database (free tier: 1,000 ops/month)
+3. **Airtable / Notion** — simulates the backend database (free tier covers first hundreds of customers)
+
+**The pattern:** Founder manually processes requests behind the scenes while the customer experiences what looks like an automated SaaS product. This is the "Concierge MVP" or "Wizard of Oz" pattern.
+
+**Recommendation:** Add as an **alternative path** in Module 4 Ch 4.3 (Self-Serve MVP Stack) — "Before you build on Lovable: the $0 Concierge MVP with Tally + Zapier + Airtable." This fills a critical gap for founders who should validate demand more deeply before committing to a code build.
+
+---
+
+### GAP 3: Echo Chamber Warning (Founder-to-Founder Validation Trap)
+
+**What's missing:** Chapter 5.3 states "The First Ten Come From People Who Already Know You." The research explicitly warns against this as a validation strategy — friends, family, and other founders will lie to you out of politeness. The only valid signal comes from cold strangers describing the problem in their own words and showing willingness to pay.
+
+**Research quote:** "Общение в предпринимательских сообществах создает эхо-камеру. Настоящий сигнал спроса поступает только тогда, когда человек без технических навыков и бизнес-интереса описывает проблему своими словами и заявляет о готовности платить."
+
+Translation: "Communication in entrepreneurial communities creates an echo chamber. A real demand signal only arrives when a person without technical skills and business interest describes the problem in their own words and declares readiness to pay."
+
+**Recommendation:** Add an **inline warning callout** to Chapter 5.3 distinguishing between "warm network for your FIRST PAID PILOT (valid, this is a sales motion)" vs "warm network for PROBLEM VALIDATION (invalid, this is an echo chamber)." The chapter's advice is correct for the sales stage but dangerous if a reader applies it to the validation stage. Also add a **cross-reference** from Chapter 2.3 (finding interview subjects) warning against interviewing only other founders.
+
+---
+
+### GAP 4: Loom Video Outreach (Distribution Tactic)
+
+**What's missing:** The course covers channel selection and cold outbound, but does not mention asynchronous video (Loom) as a distinct high-conversion B2B channel.
+
+**The tactic:** Record a 10-minute video showing a specific prospect's pain point on THEIR website or in THEIR processes, then demonstrate how your MVP solves it. Send directly to the decision-maker. Conversion is significantly higher than cold text email because it's personalized and demonstrates effort.
+
+**Recommendation:** Add as a **tactic option** in Chapter 5.2 (Channel Selection) or 5.5 (Outbound Without a Sales Team). Low effort, high differentiation.
+
+---
+
+### GAP 5: Engineering as Marketing (Free Micro-Tools)
+
+**What's missing:** The course covers personal network, channel selection, and cold outbound, but does not cover "engineering as marketing" — building free mini-tools (calculators, checklists, graders) that attract organic SEO traffic and generate waitlists.
+
+**The tactic:** Build a free No-Code micro-tool (on Carrd/Tally/Notion) that solves one micro-problem for your ICP. The tool attracts targeted organic traffic, and users who find it useful are pre-warmed leads for your main product. Zero CAC.
+
+**Recommendation:** Add as a **tactic option** in Chapter 5.2 (Channel Selection). Distinct from content marketing — this is a functional tool, not a blog post.
+
+---
+
+### GAP 6: Week 1 Semantic Search (Pre-Hypothesis Research Layer)
+
+**What's missing:** The course's Week 1 equivalent (Module 1) is "write a hypothesis and build a landing page." The research's Week 1 is "map the market, run semantic search, find verbatim customer complaints." This upstream research layer would make the hypothesis sharper before it's written.
+
+**Specific tactical additions:**
+- Perplexity query template: "Find 5 existing software solutions for [niche]. List the main user complaints about pricing and missing features, citing G2 and Capterra reviews."
+- Reddinbox/Pushshift: Automated Reddit archive search for high-commercial-intent phrases ("how to automate X," "sick of doing Y manually")
+- Verbatim quote extraction: Copy-paste exact customer vocabulary into the landing page headline
+
+**Recommendation:** Could form a **new Chapter 0** (pre-Module 1) or be integrated as a **detailed sidebar** in Chapter 1.1. The overview chapter (`how-this-course-works`) already serves as the container for this pre-hypothesis research guidance, covering the Perplexity and Trend Seeker workflow.
+
+---
+
+## SIPOC Framework — Relevance to Course Architecture
+
+The research presents a SIPOC model that maps the startup launch pipeline:
+
+| SIPOC | Research Content | Course Mapping |
+|---|---|---|
+| **S**uppliers | Reddit, Quora, Hacker News, AI providers, Infra providers | Covered in Modules 1-2 |
+| **I**nputs | Hypothesis, keywords, zero budget, Mom Test script, 20-30 ICP profiles | Covered in Modules 1-2 |
+| **P**rocess | 6-week validation cycle | Maps to Modules 1-5 linearly |
+| **O**utputs | JTBD profiles, search volume reports, landing page, waitlist, LOIs | Covered as course artifacts |
+| **C**ustomers | Early adopters + founder (internal customer) | Covered in Module 5 |
+
+**Recommendation:** The SIPOC framework is useful as a **high-level visual** in the course overview chapter. It shows the reader the entire system at a glance before they dive into individual chapters.
+
+---
+
+## Priority Ranking
+
+| # | Gap | Effort | Impact | Status |
+|---|---|---|---|---|
+| 1 | Perplexity/Trend Seeker pre-hypothesis research | Low (sidebar) | High | → Overview chapter |
+| 2 | Wizard of Oz Concierge MVP stack | Medium (new alt path) | Critical | → Future chapter |
+| 3 | Echo chamber warning in Ch 5.3 + 2.3 | Low (inline callout) | High | → Future edit |
+| 4 | Loom video outreach tactic | Low (tactic option) | Medium | → Future edit |
+| 5 | Engineering as Marketing micro-tools | Low (tactic option) | Medium | → Future edit |
+| 6 | IdeaProof/ValidatorAI ensemble validation | Low (sidebar) | Medium | → Overview chapter |
+
+---
+
+## Sources
+
+- `docs/_research/Валидация Бизнес-Идеи_ Система и Инструменты.md` — primary research document
+- Web research on AI validation tool usage flow (June 4, 2026)
+- Course source of truth: `data/course_sequence.yaml`
+- Course goal: `docs/projects/2605-tech-for-non-technical-founders/GOAL-AT-A-GLANCE.md`
diff --git a/docs/projects/2605-tech-for-non-technical-founders/10-19-research/_ARCHIVED_10.06-icp-persona-course-walkthrough.md b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/_ARCHIVED_10.06-icp-persona-course-walkthrough.md
new file mode 100644
index 000000000..f8abd2bad
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/_ARCHIVED_10.06-icp-persona-course-walkthrough.md
@@ -0,0 +1,249 @@
+# ICP-E (Alex) Course Walkthrough — Companion to ICP-Sam Walkthrough
+
+**Created**: 2026-05-29
+**Last updated**: 2026-05-29
+**Project**: 2605-tech-for-non-technical-founders
+**Method**: AI persona simulation — agent assigned the ICP-E profile (from `90.10-icp-primary-website-target.md`) walked the full 5-module course sequentially, recording assessments after each module.
+**Evaluator**: ICP-E persona agent ("Alex")
+**Companion to**: [`10.07-icp-sam-persona-course-walkthrough.md`](10.07-icp-sam-persona-course-walkthrough.md) — the parallel ICP-Sam (idea-stage non-technical first-timer) walk
+
+> **Scope note**: This walkthrough evaluates the course through Alex's lens (the post-team-fail burned founder with a built product, dev shop relationship, and infrastructure to audit). The course was redesigned 2026-05-12 to be **Sam-first** (idea-stage non-technical first-timer); Alex is the secondary audience served by conditional side-paths. Read this file alongside the Sam walk — both are correct relative to their ICP; both miss the OTHER ICP's experience. The Sam walk surfaces 5 BLOCKING gaps Alex's perspective cannot see (because Alex already has the team / product / users Sam doesn't).
+
+---
+
+## 1. Persona: Alex
+
+- 38, BBA/MBA, founder & CEO of a B2B SaaS at 8 employees
+- $500K raised, 14 months of runway
+- 6 months into a dev-shop engagement that delivered 4 weeks late with half the features
+- Cannot read code, cannot evaluate the GitHub commit log, cannot tell if the agency is productive or stalling
+- Tech literacy: can use Stripe, Notion, Google Sheets, and send a Loom — cannot read a PR, set up a DB, or deploy
+
+**Key ICP-E traits active during evaluation**: distrust of technical authority, need for plain-English explanations, preference for concrete scripts over abstract frameworks, fear of being sold to, limited time for learning (fits between founder duties).
+
+> **Note on chapter ordering**: This walkthrough presents chapters in the order Alex encountered them during the simulation (prioritizing the burned-founder experience). The actual shipped chapter sequence may differ. See `../20-29-strategy/20.01-course-modules.md` or `../../data/course_sequence.yaml` for canonical ordering.
+
+---
+
+## 2. Module-by-Module Walkthrough
+
+### Module 1 — Hypothesis & Smoke Test (estimated 2 hr)
+
+**Alex's experience:**
+
+Alex opens Chapter 1.1 at 9 AM Monday. The three-sentence hypothesis template asks her to write *customer / business / solution* in plain English — no jargon, no features. She fills in:
+
+> *Customer: A 12-person law-firm office manager on Friday afternoon trying to invoice 10 clients before QuickBooks logs her out.*
+> *Business: B2B SaaS, self-serve, $29/month, annual billing.*
+> *Solution: A one-click invoice export to Stripe that saves 90 minutes every Friday.*
+
+She moves to Chapter 1.2. The smoke-test landing page builder walks her through a headline, a subheadline, a Stripe price button, and a 7-day wait. No code required — the tools named are Carrd + Stripe. She builds it in 90 minutes. Chapter 1.3 adds the price button: she sets it at $29/month and watches the email-capture rate.
+
+**ICP verdict — Practicality**: ✓ High. The three-sentence structure removes the blank-page paralysis. Every tool is named with a free tier. The 7-day wait is concrete. Alex says: *"I can do this before lunch without asking anyone for help."*
+
+**ICP verdict — Engagement**: ✓ High. The chapter opens with a real founder story (dev-shop disaster → landing page test), which mirrors Alex's own situation. The tone is direct — no buzzwords, no "harness the power." She feels spoken *to*, not lectured *at*.
+
+**ICP verdict — Goal achievability**: ✓ Yes. After 2 hours she has a live landing page with a Stripe button and email capture. The output is real and investor-showable.
+
+**Modernity / Validation**: ✓ The 2026-specific stack (Carrd + Stripe Checkout, not WordPress + PayPal) and the "write three sentences before building" pattern are modern. References to YC Startup School and the Mom Test ground it in validated methodology.
+
+---
+
+### Module 2 — Validate the Problem (estimated 3 hr)
+
+**Alex's experience:**
+
+Chapter 2.1 introduces the Mom Test. Alex reads the core rule: *ask about the past, not the future.* She drafts 8 questions. Chapter 2.2 asks her to paste those questions into Claude with an ICP persona prompt. She runs the 5-prompt rehearsal sequence for 30 minutes. Claude flags her Q2 ("Would you use a tool like this?") as hypothetical → generates polite yes. She rewrites it: "Walk me through the last time you had to invoice clients on a Friday afternoon."
+
+Chapter 2.3 is the outreach playbook — the longest chapter. Alex learns to find people on Reddit/Discord/G2 who are already complaining about the problem. The 6-a-day cold-message cadence is concrete. She spends 2 hours reading Reddit threads and builds a spreadsheet of 30 named people.
+
+Chapter 2.4 wraps with the clickable prototype in Lovable. Alex builds a 3-screen clickable prototype in 2 hours. She shows it to 5 interview subjects. One says "I expected this button to go to a different screen." She catches a UX failure she would have shipped to production.
+
+**ICP verdict — Practicality**: ✓ High-medium. The Mom Test rehearsal using Claude is the most practical 2026-specific innovation. Alex says: *"I would never have caught that 'would you use this' question on my own, and I would have wasted 8 interview slots on polite yeses."*
+
+**ICP verdict — Engagement**: ✓ High. The chapter structure (interview → rehearse → find people → run prototype) mirrors a real validation sprint. Alex stays engaged because each chapter has a tangible deliverable that feeds the next.
+
+**ICP verdict — Goal achievability**: ✓ Yes, conditionally. Alex can complete all 4 chapters in a week if she dedicates 45 min/day. The risk is the outreach chapter (2.3) — it's the longest and most labor-intensive, and she might stall there. The 6-a-day rule is the right countermeasure.
+
+**Modernity / Validation**: ✓ The AI persona rehearsal (Claude/ChatGPT acting as the ICP) is not taught by any competing course. The Mom Test (Fitzpatrick) is the gold standard for customer discovery interviews. The Lovable prototype is 2026-native. The outreach playbook references Apollo, Clay, Gmail multi-send, NeetoCal — modern tooling.
+
+---
+
+### Module 3 — Product Brief (canonical landing page says 1 hr)
+
+**Alex's experience:**
+
+Chapter 3.1 introduces the Vibe PRD: a one-page outcome-shaped Product Brief. Alex fills in 6 sections: persona, problem, current behavior, solution (outcomes, not features), what we won't build, how we'll know it worked. She completes it in 60 minutes.
+
+Chapter 3.2 is the critical framing shift: *stop specifying features, start specifying outcomes.* Alex reads the job-story format: "When [situation], I want to [motivation], so I can [expected outcome]." She rewrites her feature list ("invoices page with export button") as a job story ("When it's 4pm Friday and 10 clients haven't been invoiced yet, I want to get their invoices approved and sent in one pass, so I can leave at 5pm like I promised my family"). The outcome shift is real.
+
+**ICP verdict — Practicality**: ✓ High. The Vibe PRD template is the killer artifact. Alex says: *"I have something I can hand to a developer and say 'build this,' and they won't come back with 12 clarifying questions."*
+
+**ICP verdict — Engagement**: ✓ Medium-high. Chapter 3.2 is the most intellectually demanding chapter in the course. Alex has to unlearn the feature-specification habit. The job-story format is a new muscle. Engagement is high because the payoff is clear (fewer costly misunderstandings), but the learning curve is steeper than earlier modules.
+
+**ICP verdict — Goal achievability**: ✓ Yes. A one-page PRD is achievable in a single focused session. The template reduces cognitive load.
+
+**Modernity / Validation**: ✓ The Vibe PRD concept is from the 2026 vibe-coding ecosystem (Drew Falkman). Job Stories are from JTBD (Christensen, Kalbach), which are widely cited in product management. The "outcomes not features" principle aligns with YC's "talk to users, build what they need" ethos.
+
+---
+
+### Module 4 — Choose Your Build (estimated 3 hr)
+
+**Alex's experience:**
+
+Chapter 4.1 presents the build decision tree: self-serve or hire. The decision tree includes the Airbnb test, the "shed not skyscraper" warning (Rob Walling), and a budget-range tool comparison. The self-serve path uses Lovable + Supabase + Stripe (~$50/month total). The hire path uses the AI-Augmented Developer profile (~$85-120K annual).
+
+Chapter 4.2 is the Ownership Audit checklist: who owns your GitHub org, AWS root account, domain registrar, and database? Alex runs the checklist and discovers her dev shop owns the GitHub org and AWS root. She requests transfer immediately.
+
+Chapters 4.3-4.4 walk through the self-serve stack with a staging URL build. Alex writes the appointment booking flow using AI coding tools.
+
+**ICP verdict — Practicality**: ✓ High. The ownership audit (Chapter 4.2) is the most immediately useful chapter in the entire course for Alex. She was 6 months into a dev-shop relationship without knowing the root account was under their email. *"This chapter alone saved me from being held hostage when I eventually switch shops."*
+
+**ICP verdict — Engagement**: ✓ High. The stakes are personal for Alex. The ownership audit is a gut-check moment. The self-serve walkthrough is motivating because she can see a path to shipping without the agency.
+
+**ICP verdict — Goal achievability**: ✓ Yes. The decision tree is structured as 4 yes/no questions. The ownership audit is 12 line items. The self-serve walkthrough is a step-by-step build. Each chapter produces a concrete artifact.
+
+**Modernity / Validation**: ✓ The Lovable + Supabase + Stripe stack is 2026-specific. The ownership audit pattern is drawn from real rescue cases. The AI-Augmented Developer profile ($85-120K) is from 2026 research. The Rob Walling "shed not skyscraper" warning anchors it in known startup thinking.
+
+---
+
+### Module 5 — First Paying Customer (canonical landing page says 1 hr; realistic 3-4 weeks elapsed)
+
+> **Correction 2026-05-29**: the original draft of this section had the Module 5 chapter mapping wrong. Canonical mapping per `data/course_sequence.yaml`:
+> - **Ch 5.1** — Your First Customer Is Not Marketing: The Sean Ellis 40% Test
+> - **Ch 5.2** — Choose Your Channel Before You Send One Message
+> - **Ch 5.3** — The First Ten From Your Network
+> - **Ch 5.4** — Charge Before You Ship: The Paid Pilot Contract
+> - **Ch 5.5** — Going Outbound Without a Sales Team
+>
+> The rewritten Alex walk below uses the correct chapter assignments.
+
+**Alex's experience (corrected):**
+
+Chapter 5.1 introduces the Sean Ellis 40% PMF test. Alex needs 10-30 users on the MVP to run the survey; she already has 47 paying customers from her dev-shop build, so she runs the survey immediately and finds 38% "very disappointed" — just under the 40% threshold.
+
+Chapter 5.2 is channel selection — pick ONE channel and commit for 4 weeks. Alex's interview transcripts (from her own past research) suggest outbound to vertical CFO communities.
+
+Chapter 5.3 is the first-ten-from-personal-network playbook — Alex builds a 50-name list in 4 buckets (champions, peers, advisors, weak ties) and sends 15 personalized DMs by Friday.
+
+Chapter 5.4 is the paid pilot close: Alex sets a $500 pilot price, writes a Design Partner Agreement, and signs her first NEW paying customer (independent of her dev-shop legacy customers) via Stripe deposit.
+
+Chapter 5.5 is the cold-outbound playbook for when the network is exhausted — Alex saves it for next month.
+
+**ICP verdict — Practicality**: ✓ High. The paid pilot template (scope, price, duration, graduation terms) is the most valuable artifact in Module 5. Alex says: *"I now have a signed paid pilot — real money, not another 'we'll pay when you're done' commitment. This changes everything for investor conversations."*
+
+**ICP verdict — Engagement**: ✓ High. The momentum from the staging URL build carries through. The milestone of a $500 Stripe deposit is the first real revenue — a concrete achievement after modules of research and planning.
+
+**ICP verdict — Goal achievability**: ✓ Yes, with caveat. The initial paid pilot at $500 is achievable for most ICP-E founders with a validated product. The scaling path (Chapter 5.4 for B2B, Chapter 5.5 for customer acquisition) is optional.
+
+**Modernity / Validation**: ✓ The channel selection framework is from Justin McGill / modern B2B go-to-market playbooks. The 3-message outbound sequence follows the cold-email conversion playbook (YC Startup School style). The paid pilot structure ($500 deposit, 6-week, go/no-go gate) is modeled on real best-practice agency pilot structures.
+
+---
+
+## 3. Overall Course Evaluation
+
+| Dimension | Score (1-10) | Notes |
+|-----------|-------------|-------|
+| **Practicality** | 10 | Every chapter produces a concrete deliverable. No theory without output. Tools are named with free tiers. |
+| **Engagement** | 9 | Founder stories mirror the ICP's reality. Tone is direct without being cold. Momentum builds across modules. |
+| **Goal achievability** | 9 | Linear path from idea to paying customer is clearly mapped. Realistic timeline is **12-22 weeks elapsed (40-60 focused hours)**; the often-misquoted "4 weeks" is the BUILD portion of M4.3 only. |
+| **Modernity / Validation** | 9 | Stack is 2026-native. Methodology is grounded in proven frameworks (Mom Test, JTBD, YC). AI-persona rehearsal is a genuine innovation. |
+
+**Overall: 9.25/10**
+
+### What the course does exceptionally well
+
+1. **Every chapter has a concrete output** — landing page, interview transcript, prototype, PRD, staging URL, paid pilot. No chapter ends with "reflect on what you learned."
+2. **Tools are named with free tiers and 2026 relevance** — Carrd, Stripe, Lovable, Supabase, Apollo, NeetoCal, Claude. No imagined tools, no affiliate-driven picks.
+3. **The AI-persona rehearsal (Module 2) is a genuine innovation** — no competing course teaches founders to validate their question script against an AI persona before running real interviews.
+4. **The ownership audit (Module 4) is the most immediately useful chapter for the burned-founder ICP** — it surfaces a hostage situation the founder didn't know existed.
+5. **The linear sequence is forced-choice and opinionated** — no "pick your own adventure" confusion. The reader knows exactly what to do next.
+
+### Gaps and suggestions
+
+| Gap | Severity | Suggestion |
+|-----|----------|------------|
+| Module 2 (outreach) is disproportionately long | Medium | Split into 2 chapters: "Find 10 People" and "Book the Calls." The current single-chapter density risks reader dropout. |
+| Module 5 (first paying customer) is lighter than earlier modules | Medium | Add a "Preparing for the Pilot Kickoff" chapter: how to set expectations, define success criteria, and run the first 2 weeks. |
+| No "what if I get stuck" per-module section | Medium | Add a "Blocked?" sidebar per module with the most common reason readers stall and the unblocking action. |
+| Glossary chapter references technical terms not all chapters define inline | Low | Add inline definitions for the 3-4 most technical terms per chapter rather than relying on the glossary. |
+| No completion estimate per chapter | Low | Add "Time: ~45 min" badge at the top of each chapter so the reader can plan their session. |
+
+### What Alex (ICP) would say after completing
+
+> *"I went in thinking I needed to learn to code or hire someone who can. I came out with a paying customer and a checklist I can re-run for the next product. The course didn't try to make me technical — it gave me a system for being a non-technical founder effectively."*
+
+---
+
+## 4. Verification Against Project Requirements
+
+### Does the course teach practical, implementable skills? ✓
+
+Every chapter names specific tools (Carrd, Stripe, Claude, Lovable, Supabase, NeetoCal, Apollo, Gmail multi-send) with free tiers or low entry costs. Every chapter has a concrete output the reader produces. The course passes the "could a reader complete this in a single focused session?" test.
+
+### Does the course engage the ICP? ✓
+
+The opening-founders-vignette pattern (used in modules 1-3) mirrors Alex's own experience of being burned by a dev shop. The direct, plain-English tone avoids both cheerleading and lecturing. The "skip if you're too busy" callout on longer chapters respects the reader's time.
+
+### Can the reader reach the stated goal by following instructions? ✓
+
+The linear module structure forces the reader through hypothesis → validation → brief → build → pilot. Each module's output is the next module's input. A reader who completes all 18 chapters in sequence will have: a validated hypothesis, a live smoke-test landing page, 10+ interview transcripts, a clickable prototype shown to 5 subjects, a one-page outcome-shaped PRD, a build decision, a live staging URL, and one signed paid pilot. This matches the course promise: "From idea to first paying customer."
+
+### Are the instructions modern and validated by market professionals? ✓
+
+The course references or builds on:
+
+| Source | What it validates |
+|--------|------------------|
+| Y Combinator Startup School methodology | Hypothesis validation, talk-to-users ethos |
+| Rob Fitzpatrick, *The Mom Test* | Customer interview technique (ask about past, not future) |
+| Rob Walling (Drip, TinySeed, MicroConf) | "Shed not skyscraper" build philosophy |
+| Jim Kalbach / JTBD canon | Job Stories for outcome specification |
+| Drew Falkman, Vibe PRD | One-page product brief for AI-era building |
+| Justin McGill / B2B outbound playbooks | Channel selection and cold-outreach sequences |
+| Sean Ellis PMF test | Must-have / nice-to-have survey methodology |
+| Sophia Matveeva, *Tech for Non-Technical Founders* | Validation-first curriculum design |
+| Christensen / JTBD (Jobs to Be Done) | Outcome specification over feature specification |
+| Click (Knapp/Zeratsky), Foundation Sprint | Lightweight experiment before heavy design sprint |
+
+---
+
+## 5. Module Scoring Matrix
+
+| # | Module | Practicality | Engagement | Achievability | Modernity | Overall |
+|---|--------|-------------|-----------|---------------|----------|---------|
+| 1 | Hypothesis & Smoke Test | 10 | 9 | 10 | 9 | 9.5 |
+| 2 | Validate the Problem | 9 | 9 | 8 | 10 | 9.0 |
+| 3 | Product Brief | 10 | 8 | 10 | 9 | 9.25 |
+| 4 | Choose Your Build | 10 | 9 | 9 | 10 | 9.5 |
+| 5 | First Paying Customer | 9 | 9 | 8 | 8 | 8.5 |
+
+---
+
+## 6. Key Findings
+
+1. **Strongest chapters**: Ownership Audit (4.2), Mom Test Rehearsal with AI (2.2), Smoke Test Landing Page (1.2). These produce immediate, high-value outputs that teach the reader something they didn't know they were missing.
+
+2. **Weakest chapter**: Charge Before You Ship (5.4 — the paid pilot close chapter, originally mis-attributed as 5.3 in the first draft of this walk). The $500 pilot price point is validated but the chapter could be more specific about the kickoff conversation script, the go/no-go decision criteria, and handling objections.
+
+3. **Most underutilized asset**: The AI-persona rehearsal in Module 2. This is a genuine 2026 innovation no competitor teaches. It deserves a standalone section in the course landing page to attract the mom-test-curious audience.
+
+4. **Risk of reader dropout**: The sequence from Module 2.3 (outreach) to Module 2.4 (prototype) has the highest dropout risk because it requires the most active work (building the list, running interviews, building the prototype) without an intermediate checkpoint. Consider adding a "halfway checkpoint" after Module 2.2.
+
+5. **Burned-founder fast path works**: Alex would route through the fast path (Module 4.2 Ownership Audit first, then Module 5 oversight chapters, then backfill Modules 1-3 only if rebuilding from scratch). The landing-page router correctly handles this case, but the per-chapter routing blocks were correctly removed to avoid distracting the primary reader.
+
+---
+
+## 7. What Alex's perspective misses — read the Sam walk
+
+The 9.25/10 verdict above is Alex-specific. The course's primary ICP is Sam (idea-stage), and the Sam walk (see [`10.07-icp-sam-persona-course-walkthrough.md`](10.07-icp-sam-persona-course-walkthrough.md)) surfaced 5 BLOCKING gaps that Alex's perspective could not see:
+
+| Gap (visible to Sam, invisible to Alex) | Why Alex can't see it | Status after 2026-05-29 fix sprint |
+|-----------------------------------------|-----------------------|--------|
+| **M4.3 → M5.1 invisible bridge** — no instructions for getting first 10-30 users onto MVP | Alex already has 47 paying customers from her dev-shop build | FIXED — Week-5 Module 5 onramp section added to M4.3 |
+| **M4.2 Ownership Audit reads as wrong-stage** for self-serve Sam | Alex (post-team-hire) finds it the most valuable chapter | FIXED — top-of-chapter skip-out for Path 2 self-serve readers |
+| **M4.4 Ceiling Signals has no Monday action** for pre-launch Sam | Alex already has a live product to monitor | FIXED — reframed as monthly-review reference with "set calendar block today" as the one concrete action |
+| **M4.1 Q1 pre-order requirement** routes Sam back to Path 1 unnecessarily | Alex has paying customers and skips Q1 entirely | FIXED — sub-callout: "Already completed Modules 1-3? Answer Yes" |
+| **Stripe lead-time** buried at L77 of M1.3 gotcha list | Alex already has Stripe set up from her dev-shop build | FIXED — top-of-chapter warning surfaces 1-3 day verification time |
+
+The Alex walk's 9.25/10 was correct **for Alex**; the Sam walk's "GOAL REACHABLE WITH GAPS" was correct **for Sam**. The 2026-05-29 fix sprint closed Sam's gaps, raising the Sam-walk verdict to "MOSTLY REACHABLE." This file (Alex's walk) is preserved as the secondary-ICP record; the Sam walk is the primary-ICP record per the 2026-05-12 course redesign.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/10-19-research/_ARCHIVED_10.07-icp-sam-persona-course-walkthrough.md b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/_ARCHIVED_10.07-icp-sam-persona-course-walkthrough.md
new file mode 100644
index 000000000..759cff93a
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/_ARCHIVED_10.07-icp-sam-persona-course-walkthrough.md
@@ -0,0 +1,311 @@
+# _ARCHIVED_ — ICP-Sam Persona Course Walkthrough — Sam, the Idea-Stage First-Timer
+
+> **ARCHIVED 2026-06-07.** This walkthrough is superseded by two newer, more comprehensive documents:
+> - **40.06** (`docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.06-sam-customer-journey-report-2026-06.md`) — definitive Sam reference: per-chapter trust scores, emotional arcs, mobile analysis, artifact chains, 3 entry-point doors, overall journey score.
+> - **40.07** (`docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.07-sam-experience-improvement-report-2026-06.md`) — canonical actionable recommendations: 6 Sam-first improvements logged in TASK-TRACKER for triage.
+>
+> The 8 recommendations from this walkthrough have been triaged:
+> - 2 captured in 40.07 (landing fast path, stuck boxes)
+> - 5 tabled as aspirational/structural (split M2.3, alt ch1.1 opener, jargon audit, idea discovery worksheet, Sam/Alex comparison)
+> - 1 superseded by broader work (M2.2 repositioning discussion)
+>
+> **Kept for historical record only** — the illustrative Sam persona (BFA Industrial Design, $40K runway, dog-walking marketplace) was a useful exploration vector but is not canonical.
+
+**Created**: 2026-05-29
+**Last updated**: 2026-05-29
+**Project**: 2605-tech-for-non-technical-founders
+**Source definition**: `20.01-course-modules.md` § "Primary reader (course ICP)" and `CLAUDE.md` § "ICP-reader read-back" ("Sam, the idea-stage non-technical first-timer, NOT the website lead-gen ICP Alex the burned founder").
+**Method**: AI persona simulation — agent assigned the course ICP profile walked the full 5-module course sequentially, recording assessments after each module.
+**Evaluator**: ICP-Sam persona agent ("Sam")
+
+> **Note on persona specificity**: Sam's age, background, product choice, and specific numbers (BFA Industrial Design, $40K runway, dog-walking marketplace) are **illustrative** — they embody the traits from the source definitions above. They are NOT canonical requirements for the ICP. Future agents should treat the traits (no technical trauma, low jargon tolerance, need progressive disclosure) as canonical, not the illustrative details.
+
+---
+
+## 1. Persona: Sam
+
+- 33, BFA in Industrial Design, founder & sole employee of a pre-revenue B2B SaaS
+- Self-funded from savings ($40K runway, 8 months left)
+- Validated an idea through 3 hallway conversations with friends ("they all said they'd use it")
+- Has NOT hired anyone. Has NOT been burned. Has NOT raised money.
+- Tech literacy: can use Notion, Figma (basic), Gmail, Google Sheets — has never deployed anything, never touched a terminal, never heard of GitHub
+- Emotional state: excited, anxious about the technical parts, afraid of wasting time/money, open to learning but easily overwhelmed by jargon
+
+**Key ICP-Sam traits active during evaluation**: no prior technical trauma, low tolerance for unexplained jargon, need for progressive disclosure (orientation before mechanics), preference for value-first framing over sales/pitch, visual rhythm sensitivity (no two same-form callouts adjacent), aversion to "this will be hard" warnings that imply the reader isn't smart enough.
+
+> **Note on chapter ordering**: This walkthrough presents chapters in the order Sam encountered them during the simulation (linear idea-stage sequence). The actual shipped chapter sequence may differ. See `../20-29-strategy/20.01-course-modules.md` or `../../data/course_sequence.yaml` for canonical ordering.
+
+---
+
+## 2. Module-by-Module Walkthrough
+
+### Module 1 — Hypothesis & Smoke Test (estimated 2 hr)
+
+**Sam's experience:**
+
+Sam opens Chapter 1.1 at 10 PM Tuesday after putting the kids to bed. The three-sentence hypothesis template asks her to write *customer / business / solution* in plain English. She hesitates — she's been describing her idea as "an Airbnb for pet sitting" to friends. The template pushes her to be specific. She writes:
+
+> *Customer: A 35-year-old dog owner in a city who travels for work 2x/month and doesn't trust boarding kennels.*
+> *Business: B2C marketplace, 15% commission per booking, $0 upfront.*
+> *Solution: A vetted pet-sitter network with live video check-ins, so they can travel without guilt.*
+
+She moves to Chapter 1.2. The smoke-test landing page builder names Carrd + Stripe. Carrd is new to Sam — the chapter glosses it as "a one-page website builder, like a nicer Google Form that looks like a real product page." She builds the page in 90 minutes. The Stripe price button asks for $29/month — she pauses and re-reads Chapter 1.3's guidance on pricing: *"Price is a hypothesis too. The button tests whether strangers will click 'buy' — not whether they'll complete checkout."* She sets the price and launches.
+
+**ICP verdict — Practicality**: ✓ High. Sam went from "I have an idea I told 3 friends about" to "I have a live landing page with a Stripe button" in one evening. The Carrd gloss is essential — without it she would have Googled "how to use Carrd" for 30 minutes and lost momentum.
+
+**ICP verdict — Engagement**: ✓ High. The opening founder story (dev-shop disaster → landing page) is less resonant for Sam than it would be for Alex — she hasn't been burned by a dev shop. But the chapter structure (template → tools → deploy) is fast enough that she doesn't dwell on the mismatch. The "you don't need to code" framing is the real hook for Sam.
+
+**ICP verdict — Goal achievability**: ✓ Yes. 2 hours, one landing page, live URL she can send to friends. The output is concrete and demystifying — Sam now knows what a "smoke test" actually looks like.
+
+**Modernity / Validation**: ✓ The Carrd + Stripe stack is 2026-specific. The three-sentence hypothesis template is drawn from YC Startup School methodology. The 7-day wait is from validated lean startup practice.
+
+**ICP-Sam-specific check — Jargon glossed at first mention**: ✓ "Carrd" gets a plain-English explanation. "Stripe" is explained as "a payment processor — the company that handles credit cards for most startups." "Smoke test" is defined inline.
+
+**ICP-Sam-specific check — Progressive disclosure**: ✓ Chapter 1.1 orients (what is a hypothesis, why it matters) before mechanics (the three-sentence template). Chapter 1.2 orients (what is a smoke test, why run one) before build steps. No thresholds or metrics are front-loaded.
+
+---
+
+### Module 2 — Validate the Problem (estimated 3 hr)
+
+**Sam's experience:**
+
+Chapter 2.1 introduces the Mom Test. Sam has never interviewed a customer before — she only asked friends. The core rule (*ask about the past, not the future*) is new. She drafts 8 questions, most of which sound like "would you use..." and "do you think..." — hypotheticals.
+
+Chapter 2.2 asks her to paste those questions into Claude with an ICP persona prompt. Sam has heard of "AI" but never used it as a rehearsal tool. The chapter glosses Claude as "a free AI assistant — think of it as a practice customer who answers honestly." She runs the prompt. Claude flags Q3 ("Would you pay $29/month?") as hypothetical. She rewrites: "How much do you currently spend on kennels or pet sitters per month?"
+
+Chapter 2.3 is the outreach playbook — the longest chapter. Sam needs to find 10 people with the problem. The chapter walks her through Reddit, Discord, and G2 reviews. Sam has never used Reddit seriously before — the chapter includes a sidebar on Reddit etiquette ("read the sub for a week before posting, leave 3 real comments first"). She spends 2 hours reading r/dogs and r/petsitting threads. She finds 12 named people complaining about boarding costs, adds them to a spreadsheet.
+
+Chapter 2.4 — the clickable prototype in Lovable. Sam builds a 3-screen clickable prototype in 2 hours. Lovable is glossed as "an AI app builder — you describe what you want in plain English and it generates the screens." She shows the prototype to 3 interview subjects. One says "I thought clicking the dog photo would show me sitter reviews." Sam catches a UX assumption she would have coded into the real product.
+
+**ICP verdict — Practicality**: ✓ High. The AI rehearsal (Chapter 2.2) is the most practical tool for Sam — she has no interview experience and the practice run saves her first 3 real interviews. The outreach playbook is dense but methodical.
+
+**ICP verdict — Engagement**: ✓ Medium-high. Sam's primary engagement risk is the outreach chapter (2.3). She has never done sales-adjacent work. The chapter's "6 messages a day, 30 minutes a day" rule is a lifeline — it prevents paralysis. But the density (Reddit + Discord + G2 + LinkedIn + Apollo + NeetoCal + Gmail multi-send) risks overwhelm. Sam says: *"I had to re-read the outreach chapter twice. It's good but there's a lot of tools named."*
+
+**ICP verdict — Goal achievability**: ✓ Yes, conditionally. Sam can complete the 4 chapters in a week if she paces herself. The risk is the outreach chapter's tool density — Sam might stall researching each tool instead of just picking one channel and executing. The "just Reddit is enough" callout helps but could be more prominent.
+
+**Modernity / Validation**: ✓ AI persona rehearsal is a 2026-native innovation. The Mom Test (Fitzpatrick) is the validated interview methodology. The Lovable prototype chapter is modern. The outreach playbook references Apollo, Clay, Gmail multi-send, and NeetoCal.
+
+**ICP-Sam-specific check — Jargon glossed at first mention**: ✓ "Mom Test" is explained (book by Rob Fitzpatrick, method for truthful customer interviews). "ICP" is glossed. "Apollo" is explained as "a sales database with a free tier — it finds people by job title and company size." "Gmail multi-send" is explained. "NeetoCal" is glossed as "a free booking calendar." All tools get an inline what-this-is sentence.
+
+**ICP-Sam-specific check — Progressive disclosure**: Partially ✓. The outreach chapter orients (why find people, what channels exist) but the tool list in the "read where they're already complaining" section is dense. Sam has to absorb 6 channel types (Reddit, LinkedIn, Slack/Discord, G2, Twitter/X, personal network) and 3 tool names (Apollo, Clay, NeetoCal) in one section. Splitting this chapter into "find the people" and "book the calls" would improve progressive disclosure for Sam.
+
+**ICP-Sam-specific check — No two adjacent same-form callouts**: ✓ The chapter alternates between tool tips, Reddit etiquette sidebars, and channel examples — no two adjacent same-format blocks.
+
+---
+
+### Module 3 — Product Brief (landing page declares 1 hr reading time; realistic 1-2 sessions execution)
+
+**Sam's experience:**
+
+Chapter 3.1 introduces the Vibe PRD. Sam has never written a product brief — she has a Notion doc with bullet points. The template asks for 6 sections: persona, problem, current behavior, solution (outcomes, not features), what we won't build, how we'll know it worked. She fills it in 60 minutes. The "what we won't build" section is hardest — she wants to build everything.
+
+Chapter 3.2 introduces job stories: "When [situation], I want to [motivation], so I can [expected outcome]." Sam rewrites her feature list. One example: instead of "a booking calendar with availability slots," she writes: "When I'm going on a work trip next week, I want to find and book a sitter who's available those specific dates, so I don't spend Friday afternoon texting 5 friends asking who's free." The outcome shift clicks.
+
+**ICP verdict — Practicality**: ✓ High. The Vibe PRD template is the key artifact. Sam now has a one-page document she can show anyone. The "what we won't build" section is especially valuable for her — it prevents scope creep before she starts.
+
+**ICP verdict — Engagement**: ✓ High. Module 3 is the shortest module and the most intellectually satisfying. Sam says: *"The job-story format was a lightbulb moment. I had been describing my product as features, not situations. Now I understand why my friends said 'sounds cool' instead of signing up."*
+
+**ICP verdict — Goal achievability**: ✓ Yes. One focused session. The template is short enough that Sam doesn't stall. The chapter is designed for completion in one sitting.
+
+**Modernity / Validation**: ✓ Vibe PRD (Drew Falkman's 2026 format). Job Stories (JTBD canon from Christensen/Kalbach). The "outcomes not features" principle is validated by YC and product management best practice.
+
+**ICP-Sam-specific check — Jargon glossed at first mention**: ✓ "Vibe PRD" is explained as "a one-page product brief — think of it as the simplest possible blueprint for what you're building." "Job story" is explained with the format and an example. "Outcome" vs "feature" is demonstrated with before/after examples.
+
+**ICP-Sam-specific check — Progressive disclosure**: ✓ Module 3 follows a natural progression: template → fill → reframe. No mechanics are front-loaded. Sam learns the job story format by writing one, not by reading a definition.
+
+---
+
+### Module 4 — Choose Your Build (landing page declares 2 hr reading time; realistic 4-6 weeks execution including the 4-week ship plan + Week-5 Module 5 onramp)
+
+**Sam's experience:**
+
+Chapter 4.1 presents the build decision tree. Sam has never considered "should I build this myself or hire someone" as a structured decision. The tree asks 4 yes/no questions. For Sam (pre-revenue, solo, not technical), the answer is clearly self-serve.
+
+Chapter 4.2 is the Ownership Audit. Sam doesn't have a GitHub org or an AWS account — she's never deployed anything. The audit checklist includes a prelude: *"If you haven't started building yet: create these accounts today under your personal email. One hour now saves you a migration nightmare later."* She creates GitHub, AWS, and Stripe accounts under her company email.
+
+Chapters 4.3-4.4 walk through the self-serve stack build. Sam builds the pet-sitter matching flow using Lovable + Supabase + Stripe. Supabase is glossed as "a database that lives in the cloud — think of it as Google Sheets for your app's data." Stripe is re-glossed for the integration step. She reaches a staging URL by the end of Chapter 4.4.
+
+**ICP verdict — Practicality**: ✓ High. The ownership audit prelude (new section written for the idea-stage founder) is essential for Sam — without it, she would start building under a personal email and face the migration problem 6 months later. The self-serve build chapters give her a real staging URL.
+
+**ICP verdict — Engagement**: ✓ High. The staging URL milestone is the most motivating moment in the course for Sam. She has a real, clickable app — not a mockup, not a landing page, an app with a database. She texts a screenshot to her co-founder friend.
+
+**ICP verdict — Goal achievability**: ✓ Yes, with caveat. The self-serve stack walkthrough is the most technically demanding section of the course. Sam can follow the steps if she goes slowly and uses the tool-specific glossaries. The risk is that a single failed step (e.g., Stripe webhook misconfiguration) could stall her for a day. The chapter's "stuck? paste the error into Claude and ask 'what do I do next?'" callout is a practical workaround.
+
+**Modernity / Validation**: ✓ The Lovable + Supabase + Stripe stack is 2026-specific and widely discussed in founder communities. The ownership audit pattern is derived from real rescue cases. The "create accounts now" prelude is a forward-looking fix for a common post-hoc pain point.
+
+**ICP-Sam-specific check — Jargon glossed at first mention**: ✓ "Supabase" is glossed. "AWS" is explained as "Amazon Web Services — the cloud provider where most startups host their app." "Staging URL" is glossed as "a private web address where your app lives during development — not yet public, but clickable." "Webhook" is glossed as "a way for one service to notify another when something happens — like Stripe telling your app 'the customer paid'."
+
+**ICP-Sam-specific check — Progressive disclosure**: ✓ Chapter 4.1 orients (build decision framework) before mechanics (tool-specific steps). The ownership audit audits before the build — natural sequence for a first-timer. The self-serve build chapters start with "what you'll build by the end" before the step-by-step.
+
+**ICP-Sam-specific check — Value-first, not sales**: ✓ No "hire JetThoughts" framing. The ownership audit is positioned as founder empowerment, not as a service upsell. The self-serve stack is presented as a real alternative to hiring.
+
+---
+
+### Module 5 — First Paying Customer (landing page declares 1 hr reading time; realistic 3-4 weeks execution)
+
+> **Correction 2026-05-29**: an earlier draft of this section had the Module 5 chapter mapping wrong. Canonical mapping per `data/course_sequence.yaml`:
+> - **Ch 5.1** — Your First Customer Is Not Marketing: The Sean Ellis 40% Test
+> - **Ch 5.2** — Choose Your Channel Before You Send One Message
+> - **Ch 5.3** — The First Ten From Your Network
+> - **Ch 5.4** — Charge Before You Ship: The Paid Pilot Contract
+> - **Ch 5.5** — Going Outbound Without a Sales Team
+>
+> The rewritten Sam walk below uses the correct chapter assignments.
+
+**Sam's experience (corrected):**
+
+Chapter 5.1 introduces the Sean Ellis 40% PMF test. Sam needs 10-30 users on the MVP to run the survey — she has the 10 Module 2 interviewees she just invited via the new M4.3 Week-5 onramp section. She sends the 5-question Typeform; 4 of 10 respond, 2 say "very disappointed" without her product = 50% must-have rate. Sean Ellis's framework treats anything ≥40% as PMF signal. Sam has a green light at 10 users.
+
+Chapter 5.2 is channel selection — pick ONE channel and commit for 4 weeks. Sam's interview transcripts named Reddit (r/dogs, r/petsitting) as the channel her ICP actually uses. She picks personal network first (Module 5.3), Reddit second.
+
+Chapter 5.3 is the first-ten-from-personal-network playbook — Sam builds a 50-name list in 4 buckets (champions, peers, advisors, weak ties) and sends 15 personalized Looms by Friday. 4 reply, 2 book intro calls.
+
+Chapter 5.4 is the paid-pilot close: Sam sets a $250 pilot price (lower than the course default of $500 — the chapter's "B2C pricing range $99-$499 / month" sidebar guides her). She writes a 4-week scope with weekly checkpoints and a go/no-go decision gate. Her first pilot customer (a friend-of-a-friend from the interview pool) pays via Stripe deposit. Sam now has her first revenue.
+
+Chapter 5.5 is the cold-outbound playbook for when personal network is exhausted — Sam saves it for week 4-6 of Module 5 to find pilot #2.
+
+**ICP verdict — Practicality**: ✓ High. The paid pilot template (scope, price, checkpoints, graduation terms) is the most valuable artifact for Sam. A B2C pricing sidebar (recommended — see Gaps table) would be a necessary addition to prevent Sam from following the $500 default and scaring off early users.
+
+**ICP verdict — Engagement**: ✓ Very high. The $250 Stripe deposit notification is Sam's first revenue ever. She says: *"I cried. Someone paid me for something I built. This is real now."* The emotional milestone is the most powerful engagement driver in the entire course.
+
+**ICP verdict — Goal achievability**: ✓ Yes. The 4-week paid pilot at $250 is achievable for Sam with a validated product and 10 interview subjects. The scaling chapters (5.4, 5.5) are optional.
+
+**Modernity / Validation**: ✓ Channel selection framework (Justin McGill / modern B2B). Cold-email conversion playbook (YC Startup School). Paid pilot structure is modeled on real best practices.
+
+**ICP-Sam-specific check — Jargon glossed at first mention**: ✓ "Cold email" is explained as "an email to someone who doesn't know you — short, specific, not spam." "Paid pilot" is glossed as "a short-term paid engagement — like a trial but with real money, so both sides take it seriously." "Go/no-go gate" is explained as "a pre-agreed checkpoint where you decide whether to continue or stop."
+
+**ICP-Sam-specific check — Progressive disclosure**: ✓ Module 5 follows a natural escalation: choose channel → write script → close pilot → scale. The high-ticket B2B chapter is clearly flagged as skippable for B2C founders — no pressure to read it.
+
+---
+
+## 3. Overall Course Evaluation (Sam's Perspective)
+
+| Dimension | Score (1-10) | Notes |
+|-----------|-------------|-------|
+| **Practicality** | 10 | Every chapter produces a concrete deliverable. Sam built a landing page, prototype, PRD, staging URL, and signed pilot — none of which she had before. |
+| **Engagement** | 9 | The staging URL milestone (Module 4) and the first Stripe deposit (Module 5) are emotional peaks that sustain momentum through the slower chapters. |
+| **Goal achievability** | 9 | The linear path is clearly mapped. Realistic timeline is **12-22 weeks elapsed (40-60 focused hours)** at 2-4 hours/week — the "4 weeks" figure in earlier drafts was the BUILD portion of M4.3 only, not the full idea-to-paying-customer journey. The main risk is Module 2's outreach chapter density. |
+| **Modernity / Validation** | 9 | Stack is 2026-native. Methodology is grounded. AI-persona rehearsal is genuine innovation. |
+| **Progressive Disclosure** | 8 | Most chapters orient before mechanizing. Module 2 outreach chapter is the weak point — tool density risks overwhelm for a first-timer. |
+| **Jargon Handling** | 9 | All major tools/terms glossed at first mention. A few omissions: "database migration" (Module 4.2) is used without definition. |
+
+**Overall: 9.0/10**
+
+### What the course does exceptionally well for Sam
+
+1. **Every chapter has a concrete output** — Sam goes from "I have an idea" to "I have revenue" with no chapter that ends in reflection-only.
+2. **Tools are named with plain-English glosses** — Carrd, Claude, Lovable, Supabase, Stripe all get real explanations, not just links.
+3. **The self-serve build path is complete and achievable** — Sam builds a real app, not a mockup.
+4. **The paid pilot is the right first-revenue milestone** — $250 is low enough to close, high enough to count. The B2C pricing sidebar prevents the $500 default from being a blocker.
+5. **The ownership audit prelude (create accounts now) prevents a future crisis** — Sam would have started building under a personal email without this chapter.
+
+### Gaps and suggestions (Sam-specific)
+
+| Gap | Severity | Suggestion |
+|-----|----------|------------|
+| Module 2 outreach chapter is tool-dense | **High** | Split into 2 chapters: "Find 10 People" (channels + reading + list building) and "Book the Calls" (message templates + calendar + follow-ups). The current density is the highest dropout risk for the idea-stage ICP. |
+| "Database migration" in Module 4.2 is not glossed | Medium | Add a one-sentence gloss: "moving your data from one database to another — imagine moving all your files from one Google Drive account to another, but more technical." |
+| The opening founder story in Module 1 is dev-shop focused | Medium | Add an alternative opening for the idea-stage reader: a founder who validated with 3 friends, built a smoke test, and discovered the friends were just being nice. The current opener (dev-shop disaster) is off-persona for Sam. |
+| No "what to do when you're stuck" per-module for first-timers | Medium | Add a "Stuck? Try this" box per module with the most common first-timer stall point. Module 2: "Your list has 3 names, not 10. Go back to Step 2 and search for a related keyword — 'boarding costs' instead of 'pet sitter.'" |
+| Module 1 assumes the reader has a clear hypothesis | Low | Add a one-page "Idea Discovery Worksheet" for readers who have a vague feeling ("I want to build something for dog owners") but not a specific hypothesis. |
+
+### What Sam (ICP) would say after completing
+
+> *"I started with an idea I told three friends and a Notion doc. Roughly four months later — about 50 hours of evenings and weekends — I have a live app, a paying customer, and a process I can repeat. The course didn't assume I knew anything about tech — it explained every tool the first time it appeared and never made me feel dumb for not knowing. The hardest part was finding interview subjects, but the '6 messages a day' rule made it manageable. I'm going to run the whole thing again for my second product."*
+
+---
+
+## 4. Verification Against Course ICP Requirements
+
+Per `20.01-course-modules.md` § "Primary reader (course ICP)":
+
+> A non-technical founder going from idea (or a half-built MVP) to first paying customer. They mostly have NOT hired a team yet.
+
+### Does the course serve the idea-stage first-timer? ✓
+
+Every module produces a concrete output that builds on the previous one. The self-serve build path is complete and accessible. The ownership audit includes a "start here" prelude for founders who haven't built yet. The paid pilot chapter includes a B2C pricing sidebar. Sam completed the course with: hypothesis → landing page → interview transcripts → prototype → PRD → staging URL → paid pilot.
+
+### Does the course gloss every term at first mention? Mostly ✓
+
+All major tools and frameworks (Carrd, Stripe, Claude, Mom Test, ICP, Apollo, Lovable, Supabase, AWS, Vibe PRD, job story, cold email, paid pilot, go/no-go gate, staging URL, webhook) receive plain-English explanations at first mention. One missed term: "database migration" (Module 4.2) is used without definition.
+
+### Does the course use progressive disclosure? Mostly ✓
+
+Modules 1, 3, 4, and 5 orient the reader before introducing mechanics. Module 2 (outreach chapter) is the weakest — it presents 6 channel types and 3 tool names in a single dense section. The "just Reddit is enough" callout helps but should be more prominent.
+
+### Does the course maintain a value-first (not sales) tone? ✓
+
+No service CTAs. No pitch framing. The ownership audit is positioned as founder empowerment. The self-serve build path is a genuine alternative to hiring, not a lead-in to a "when you need professionals" upsell. The "Built by JetThoughts" footer is the only brand presence, and it's unobtrusive.
+
+### Does the course maintain visual rhythm? ✓
+
+No two adjacent same-form callouts across the 18 chapters. Callout types alternate between tool tips, Reddit etiquette asides, pricing guidance sidebars, and blocking notes.
+
+### Does the course avoid rescue/trauma framing in idea-stage chapters? ✓
+
+Per CLAUDE.md: "rescue/trauma framing is off-ICP for course bodies." Module 1.1 uses a dev-shop disaster opener — this is the one deviation flagged as off-persona for Sam. Modules 2-5 use neutral framing (opportunity, not rescue). The ownership audit (Module 4.2) is framed as future-proofing, not trauma recovery, which is correct for Sam.
+
+### Does the course avoid per-chapter routing blocks? ✓
+
+Per CLAUDE.md: "per-chapter routing blocks were tried on Ch 1.1 and removed 2026-05-22 — they interrupted the primary reader." The shipped course has no routing blocks ("If you're here because your dev shop is failing, skip to Chapter 4.2") in any chapter. All routing is handled by the landing page assessment worksheet, which is appropriate for both Alex and Sam.
+
+---
+
+## 5. Module Scoring Matrix (Sam vs Alex)
+
+| # | Module | Sam Practicality | Sam Engagement | Sam Achievability | Sam Score | Alex Score | Delta |
+|---|--------|-----------------|----------------|-------------------|-----------|------------|-------|
+| 1 | Hypothesis & Smoke Test | 10 | 8 | 10 | 9.3 | 9.5 | -0.2 (dev-shop opener less resonant) |
+| 2 | Validate the Problem | 9 | 8 | 8 | 8.3 | 9.0 | -0.7 (outreach tool density overwhelms first-timer) |
+| 3 | Product Brief | 10 | 9 | 10 | 9.7 | 9.25 | +0.45 (job stories click harder for idea-stage) |
+| 4 | Choose Your Build | 10 | 10 | 9 | 9.7 | 9.5 | +0.2 (staging URL is more emotional for first build) |
+| 5 | First Paying Customer | 10 | 10 | 9 | 9.7 | 8.5 | +1.2 (first revenue is more powerful for pre-revenue founder) |
+
+**Sam's overall: 9.0/10**
+
+**Key deltas from Alex (10.06):** Sam scores Module 5 higher (first revenue is a more emotional milestone for a pre-revenue founder than for a burned founder who has already raised). Sam scores Module 2 lower (outreach tool density and first-time interview anxiety are bigger barriers than for Alex, who has probably had sales conversations before). Sam scores Module 1 engagement lower (the dev-shop opener is off-persona).
+
+---
+
+## 6. Key Findings (Sam-Specific)
+
+1. **Strongest chapters**: Charge Before You Ship / paid pilot close (5.4 — originally mis-attributed as 5.3 in the first draft of this walk), Self-Serve Stack Walkthrough (4.3-4.4), Vibe PRD (3.1). These produce tangible, emotional milestones for a first-timer: revenue, a live URL, and a one-page blueprint.
+
+2. **Weakest chapter**: Find 10 People (2.3). The tool density (Reddit + Discord + G2 + Twitter/X + LinkedIn + personal network + Apollo + Clay + NeetoCal + Gmail multi-send) is the highest overwhelm risk in the course for an idea-stage first-timer. The "just Reddit is enough" callout needs to be more prominent — ideally the first sentence of the section.
+
+3. **Most underutilized asset**: The glossary chapter. Sam would use it heavily, but it's a separate reference page, not inline guidance. Adding inline glosses (already done for most terms) is the right approach, but the one missed term ("database migration") confirms the system needs a gloss audit.
+
+4. **Risk of reader dropout**: Highest risk point is Module 2 → Module 3 transition. Sam finishes outreach (dense, labor-intensive) and faces the prototype chapter (another build task). Adding a "halfway checkpoint" between Module 2 and 3 would reduce dropout — something like: "You've found 10 people. You've run 5 interviews. Take a breath. You now know more about your customer than 90% of founders at your stage."
+
+5. **The ownership audit prelude is essential for Sam**: Without the "if you haven't started building yet, create these accounts now" section, Sam would start under a personal email and face the migration problem later. This section should be preserved and highlighted in any future revision.
+
+6. **Sam would benefit from a "first-timer fast path" on the landing page**: Unlike Alex (who needs the burned-founder route), Sam enters without trauma. A landing page option that reads "New to this? Start here →" and routes to Module 1.1 directly would save her from the decision-paralysis of the self-assessment worksheet.
+
+---
+
+## 7. Comparison: Sam vs Alex — When the Course Works for Whom
+
+| Dimension | Sam (idea-stage) | Alex (burned founder) |
+|-----------|-----------------|----------------------|
+| Entry point | Module 1.1 (linear start) | Module 4.2 (ownership audit first) or Module 5 (oversight chapters) |
+| Emotional peak | First Stripe deposit (Module 5.3) | Ownership audit discovery (Module 4.2) |
+| Biggest risk | Outreach tool density overwhelm | Trust: "is this course selling me something?" |
+| Most valuable chapter | Paid Pilot Close (5.3) | Ownership Audit (4.2) |
+| Least valuable chapter | Build Decision Tree (4.1) — obvious for pre-revenue | Hypothesis chapter (1.1) — already has product |
+| Best course promise | "From Idea to First Paying Customer" (the course title) | "Rescue your project without becoming technical" |
+| Needs from landing page | "New? Start here" button + idea-stage testimonials | "Your team is failing?" fast path + rescue case studies |
+| Dropout risk zone | Module 2.3 outreach density | Module 3.2 (outcomes framing) — impatient to build |
+| Preferred module order | 1 → 2 → 3 → 4 → 5 | 4.2 → 5 oversight → 6 (if applicable) → backfill |
+
+---
+
+## 8. Recommendations for Sam-First Improvements
+
+| Priority | Recommendation | Rationale |
+|----------|---------------|-----------|
+| **P1** | Split Module 2 outreach into 2 chapters: "Find 10 People" (channels + reading) and "Book the Calls" (templates + calendar) | Single highest dropout risk for Sam. Current density is ~45 min read + ~2 hr execution in one sitting. |
+| **P1** | Add a "New to this? Start here →" routing option on the landing page | Sam currently sees the same landing page as Alex. First-timers need a clear "you're in the right place" signal. |
+| **P2** | Write an alternative opener for Module 1 Chapter 1.1: idea-stage founder + 3 friends who said "sounds great" → smoke test → friends were just being nice | Current dev-shop opener is off-persona. The first 80 words of the first chapter set the tone for the entire course. |
+| **P2** | Audit all 18 chapters for unexplained terms: add gloss to any term that appears without definition | "Database migration" missed in Module 4.2. A systematic grep for un-glossed technical terms would catch others. |
+| **P3** | Add "Stuck? Try this" box per module (first-timer version) | Sam needs different unblocking advice than Alex. E.g., Module 2: "List has 3 names? Search a related keyword." Not "License Apollo Pro." |
+| **P3** | Create an "Idea Discovery Worksheet" as a pre-Module-1 artifact | Some idea-stage founders have a vague hunch, not a testable hypothesis. A 10-minute worksheet bridges that gap. |
diff --git a/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.01-course-modules.md b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.01-course-modules.md
new file mode 100644
index 000000000..c4e270ff6
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.01-course-modules.md
@@ -0,0 +1,78 @@
+# 20.01 — Course Modules (5-module spine)
+
+**Project**: 2605-tech-for-non-technical-founders
+**Last updated**: 2026-06-10
+**Canonical sequence**: `data/course_sequence.yaml`
+**Canonical lesson template**: `30-39-architecture-design/30.03-course-format-requirements-for-creators.md` (8-part micro-lesson template)
+**Migration roadmap**: `20.11-course-migration-roadmap.md` (Now/Next/Later schedule for v2 fan-out, TASK-1 through TASK-34)
+**Formal PRD**: `.agent/prd/PRD.md` (product requirements, 15 canonical quality gates, artifact carry-forward chain)
+**Spine decision record**: `20.10-sequence-decision-validate-vs-smoke-test.md` (5-module merge, 2026-05-20)
+**Predecessor**: `_ARCHIVED_20.01-course-modules-8-module-spine.md` (8-module spine, superseded)
+
+---
+
+## ICP (locked)
+
+Sam — first-time non-technical founder, no PM background, no tech expertise, no burn history. See memory: `feedback_course_icp_sam_profile.md`.
+
+The course is the prevention layer that keeps Sam from making mistakes burned founders already lived through.
+
+---
+
+## Spine
+
+5 modules. Each module gates the next. A reader who completes the course holds a **Founder OS**: 5 artifacts in a row that document the journey from idea to first paying customer.
+
+| # | Module | Input | Output | Artifact |
+|---|---|---|---|---|
+| 1 | **Hypothesis & Smoke-Test** | An idea | A live smoke-test URL + a hypothesis tested against strangers | Founding Hypothesis sheet + live landing page |
+| 2 | **Validate the Problem** | A hypothesis + smoke-test signal | 10 Mom Test interviews scored | Validated Problem Statement |
+| 3 | **Design from Evidence** | A validated problem | A one-page Product Brief naming what you'll build AND what you won't | Vibe PRD |
+| 4 | **Build the MVP** | A Product Brief | A live MVP that takes payment | Working product on AI-builder + Supabase + Stripe (or equivalents) |
+| 5 | **First Paying Customer** | A live MVP | One signed paid pilot | Friday Demo rhythm + Design Partner Agreement (DPA) |
+
+The 5 artifacts compound. Sam does not graduate without all 5.
+
+---
+
+## What each module does
+
+**Module 1 — Hypothesis & Smoke-Test.** Sam writes a one-sentence hypothesis using a Mad Libs template, publishes a smoke-test page in 45 minutes with any AI page builder, and runs a one-stranger clarity test. The module tests **demand** (do strangers want it?), not feasibility. Sam leaves with a live URL + a named customer + a named outcome.
+
+**Module 2 — Validate the Problem.** Sam runs 10 Mom Test interviews against the must-have segment. The module teaches structured past-behavior questions (not future-intent questions), AI-as-rehearsal for sharpening the interview script, and a scoring rubric for go/iterate/kill. Sam leaves with a Validated Problem Statement signed off by interview evidence.
+
+**Module 3 — Design from Evidence.** Sam writes a one-page Product Brief (Vibe PRD) drafted from interview transcripts. The module enforces "what you won't build" as a discipline equal to "what you will." Sam leaves with a brief a stranger can read and describe the target user, the job, and the scope from.
+
+**Module 4 — Build the MVP.** Sam ships a live MVP using AI-builder + Supabase + Stripe (or any equivalent tool-agnostic stack). The module teaches: Day-1 ownership (GitHub, AWS root, domain, database in Sam's name), the 12 rules of a self-built proof-of-concept, and AI critic prompts for build audits. Sam leaves with a real URL, real auth, real payments wired.
+
+**Module 5 — First Paying Customer.** Sam closes one paid pilot through a deliberately chosen channel. The module teaches the must-have segment PMF gate (Sean Ellis 40% test), the personal-network sequence, the channel-selection decision, and the Design Partner Agreement (DPA) template. Sam leaves with one payment received and named which channel produced it.
+
+---
+
+## Module 0 — deprecated
+
+The earlier 8-module spine included a Module 0 (self-assessment + routing). In the 5-module spine, routing is handled by the landing page directly:
+
+- **First-timer fast path** callout on `_index.md`: *"New founder, no team, no trauma? Skip the diagnostic. Start at Chapter 1.1."*
+- **Quickstart** page at `/quickstart/` — minimal-path for time-starved Sam
+- **FAQ** page at `/faq/` — 15 Q&A for typical blockers
+
+Self-assessment as a standalone chapter increased drop-off without adding value for Sam (who self-selects at the landing page).
+
+---
+
+## Sequence rationale
+
+See `20.10-sequence-decision-validate-vs-smoke-test.md` for the smoke-test-first sequence decision and the M1+M2 merge that produced the 5-module spine.
+
+See `20.09-spine-3-rollout-design.md` for the audience definition + competitor positioning.
+
+See `30-39-architecture-design/30.03-course-format-requirements-for-creators.md` for the canonical 8-part micro-lesson template (the unit Sam actually reads — each module decomposes into 4-5 micro-lessons of 400-900 words each).
+
+---
+
+## Migration status (Phase 1 → Phase 2)
+
+- **v1 long-form chapters:** all 18 shipped, live at `/course/tech-for-non-technical-founders-2026//`.
+- **v2 micro-lessons:** pilot pair shipped Iter 18-19 — Lesson 1.2a (`smoke-test-build-page`, ~870w) and Lesson 1.2b (`smoke-test-wire-tracking`, ~640w). Pattern: tool-agnostic worked example, deep Sam-glossing, 8-part template, hand-drawn SVG visual.
+- **Phase 2 backlog:** 17-19 remaining v1 chapters to migrate to v2 micro-lessons. See `TASK-TRACKER.md` "Course Migration Schedule" for sprint plan.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.02-positioning-vs-courses.md b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.02-positioning-vs-courses.md
new file mode 100644
index 000000000..d143408ce
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.02-positioning-vs-courses.md
@@ -0,0 +1,96 @@
+# Positioning vs Paid Courses
+
+**Project**: 2605-tech-for-non-technical-founders
+**Created**: 2026-05-12
+**Rewritten**: 2026-06-10 (ICP corrected from Alex → Sam; module count 14-posts → 5-modules / 20-25 micro-lessons; positioning gap recalibrated)
+**Source**: `10-19-research/10.01-course-program-landscape.md` (full landscape of 19 programs)
+**ICP**: `feedback_course_icp_sam_profile.md` (memory) — Sam, first-time non-technical founder, no PM background, no tech expertise, no burn history.
+
+---
+
+## The one-sentence positioning
+
+> A free, self-paced course (5 modules / ~25 micro-lessons) that teaches first-time non-technical founders the one path every paid program assumes you already know: how to go from idea to first paying customer without writing code, without hiring a developer, and without spending more than $50.
+
+---
+
+## Why the gap exists
+
+Every paid program serves one of three buyer states:
+
+| Program cluster | Assumes the founder is | Examples |
+|---|---|---|
+| **Builder** | Already knows what to build; wants to learn no-code / AI tools | FI Vibecode, ZTM Vibe Coding, Maven Cursor bootcamp, Lovable, WeAreNoCode, 100 Days of AI |
+| **Operator** | Already has a team or co-founder; needs ops, fundraising, GTM | YC Startup School, Techstars Founder Catalyst, Founder Institute Core, Antler |
+| **Manager / PM** | Mid-career, already speaks engineering, optimizing org | Reforge, Section, Maven leadership tracks |
+
+**Sam fits none of these.** Sam has an idea but doesn't know what to build (Builder cluster assumes that's done). Sam has no team and no co-founder (Operator cluster assumes one). Sam has never written a PRD, run a sprint, or done a customer interview (Manager cluster assumes PM background).
+
+Sam needs the **first-time-founder beginner path**: validate the idea before building, build the MVP without writing code or hiring, close the first paying customer with no sales team. No paid program targets this profile cleanly. The closest fit — Sophia Matveeva's "Tech for Non-Techies" — costs $2,500.
+
+---
+
+## How the curriculum compares (head to head)
+
+The axes that matter for Sam:
+- **First-time-founder beginner path?** — does the program teach idea → first paying customer for someone who has never shipped before, in one continuous arc?
+- **Tool-agnostic + AI-era?** — does it survive AI-tool churn? Does it teach the 2026 stack (AI page builders, Lovable/Supabase/Stripe, Claude/Cursor) as substitutable examples, not as defining commitments?
+- **Free + indexed?** — can Sam find it at 2am via Google without a paywall or signup?
+
+| Curriculum | Format | Price | First-time founder beginner path? | Tool-agnostic + 2026? | Free + indexed? |
+|---|---|---|---|---|---|
+| **JT Tech for Non-Technical Founders 2026** | Free, self-paced, 5 modules / ~25 micro-lessons + artifacts | $0 | Yes (full arc from idea to first paying customer) | Yes (AI builders interchangeable; Lovable/Supabase/Stripe as worked examples) | Yes |
+| Sophia Matveeva "Tech for Non-Techies" | Live + on-demand cohort | $2,500 | Yes (closest competitor) | Partial (newest cohort 2025, light on AI-era stack) | No (paywalled) |
+| YC Startup School | Free, 7-week cohort + library | $0 | Partial (broad theory; assumes builder/operator track is figured out) | Partial (some AI essays) | Yes |
+| Founder Institute Core | Cohort | Tuition + equity | No (operator-stage) | Partial | No |
+| Reforge membership | Self-paced + live | $2,000/yr | No (PMs and managers) | Yes for AI-growth angle | No |
+| Section | Live cohort sprints | $995/yr | No (managers) | Yes for AI-for-managers | No |
+| FI Vibecode Bootcamp | Cohort + self-paced | $449 | No (Builder cluster — assumes you know what to build) | Yes (vibe coding) | No |
+| Maven Cursor Bootcamp | 3-week live cohort | $750 | No (Builder cluster) | Yes | No |
+| ZTM Vibe Coding Bootcamp | Self-paced | $299 | No (Builder cluster) | Yes | No |
+| 100 School / 100 Days of AI | Self-paced | Free + paid bootcamps | No (skill bootcamp, not founder path) | Yes | Partial (free tier) |
+| Don't Hire a Software Developer (Kukoyi book) | Book | $9-25 | No (hiring stage; rescue-flavored) | No (2017, predates GitHub Copilot) | Partial (book; indexed by Amazon) |
+| WeAreNoCode | Cohort | <$1,000 | No (Builder cluster) | Yes | No |
+
+**JT is the only entry that says yes to all three axes** for Sam: first-time founder beginner path, tool-agnostic + 2026-current, free + indexed.
+
+---
+
+## Five reasons a first-time founder picks this over paid courses
+
+1. **Free + indexed beats paid + gated.** Sam under stress searches Google at 2am, not a Slack workspace. YC Startup School wins because it is free and indexed; JT plays the same game on a topic YC does not own (the first-time-founder beginner path).
+2. **Tool-agnostic survives tool churn.** Mixo, Manus AI, Durable, Lovable, Cursor — these tools may merge, sunset, or be replaced within Sam's 90-day completion window. JT teaches the workflow with the example tool swappable in a 1-line edit. Paid programs that pin a 6-month cohort to a specific tool date instantly.
+3. **First-time founder voice, not consultant voice.** The 19 paid programs use definitional voice (Tech For Non-Techies), tool-evangelist voice (Lovable), or scare-stat voice. JT writes founder-to-founder with specific failure mechanics ("you cannot legally sell a 'Buy now' button on a product that does not exist yet") and exact scripts ("ask one stranger: 'in 3 seconds, who is this page for and what does it do?'").
+4. **Glossed for true beginners.** Every technical term (MVP, conversion rate, CTA, PMF, head tag, snippet, heatmap) is glossed at first mention. Sam has no prior context to fill in gaps; paid programs assume he does and lose him at the third paragraph.
+5. **Free downloadable artifacts.** Every module ships a checklist, template, or worksheet. ZTM ships scorecards and converts well; JT does the same without the $299 paywall.
+
+---
+
+## Three reasons a first-time founder picks a paid course **instead**
+
+(For honesty — the curriculum should not pretend to substitute for everything.)
+
+1. **Cohort accountability.** YC Startup School and Founder Institute include weekly check-ins. JT's curriculum is self-paced. Recommend YC Startup School on the JT landing page for founders who need cohort discipline.
+2. **Equity and capital.** Antler, FI, and YC offer money or warrants. JT does not. Out of scope.
+3. **Deep coding upskilling.** If Sam wants to LEARN to code (not just ship without coding), the FI Vibecode and Lovable paths teach generation skills. JT's curriculum is for founders who want to ship without learning to code. Surface this distinction on the landing page so we do not waste reader time.
+
+---
+
+## What we will NOT claim
+
+- We will **not** claim JT replaces YC. The JT course is one layer (idea → first paying customer for a first-timer); YC Startup School is broader.
+- We will **not** badge the course as a "bootcamp" — it is a free self-paced course with downloadable artifacts. No certificates, no cohort.
+- We will **not** invoke vague "industry-leading" / "comprehensive" language. The voice rules in `90.11` apply across every lesson.
+- We will **not** pin the course to a specific tool stack in titles or slugs. AI tools have short half-lives; the curriculum must outlive any one tool. See memory: `feedback_course_lessons_tool_agnostic.md`.
+
+---
+
+## Distribution implications
+
+| Channel | Action |
+|---|---|
+| Organic search | Each micro-lesson targets one blue-ocean keyword. Compound traffic over 6-12 months. |
+| LinkedIn (Paul Keen) | Each lesson gets a paired LinkedIn post per `linkedin-post-pipeline.md`. Use the course framing as a soft "I wrote a free course on this" CTA. |
+| Newsletter | Group the modules into a 5-week email drip (one module per week) for new subscribers. |
+| Sales conversations | Discovery call follow-up: *"Here is the free course we wrote on this exact problem."* Builds trust before contract. |
+| Conference / podcast pitching | *"We wrote the free 2026 first-time-founder course that doesn't require coding or hiring"* is a fundable narrative for podcast booking. |
diff --git a/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.09-spine-3-rollout-design.md b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.09-spine-3-rollout-design.md
new file mode 100644
index 000000000..b91d890ce
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.09-spine-3-rollout-design.md
@@ -0,0 +1,320 @@
+# JT Course Spine Rollout — Design (Phase 1 / v1)
+
+**Date:** 2026-05-15
+**Status:** Approved overall shape; PARTIALLY SUPERSEDED — see corrigendum below
+**Predecessor:** [_ARCHIVED_20.08 Spine 2 Audit + Mapping](_ARCHIVED_20.08-spine-2-audit-8-module.md) (archived 2026-06-10)
+**Approach picked:** Approach 3 — Core (6 modules) only; continuation as "Going further" callouts
+
+---
+
+> ## ⚠️ Corrigendum (2026-06-10): module count drift + ICP refinement
+>
+> **Module count:** This doc picked "Approach 3 — Core (6 modules)." The course subsequently merged Module 1 (Hypothesis) + Module 2 (Smoke-Test) into a single 3-chapter Module 1 (Hypothesis & Smoke-Test) on 2026-05-20 — see [20.10](20.10-sequence-decision-validate-vs-smoke-test.md). **Current spine is 5 modules, not 6.** Subsequent module numbers below shift down by 1 (the old "Module 2 — Test Demand Cheap" content folded into the new Module 1; old "Module 6 — First Paying Customer" is now Module 5).
+>
+> **ICP refinement:** The audience definition below ("Newbie startup founder without tech expertise. Greenfield only. No rescue framing.") is the canonical position. The corrected Sam profile (see `feedback_course_icp_sam_profile.md` in memory) additionally specifies: **no product-management background**. Every reference to MVP, PMF, CAC, LTV, sprint, backlog, etc. must be glossed at first mention because Sam has no prior PM context to fill in gaps.
+>
+> **What still stands from this doc:**
+> - Audience definition (line 22): canonical Sam-positioning prose
+> - Competitor positioning (line 28): Sophia Matveeva still the closest paid competitor
+> - Critical distinctions section (M3 prototype vs M5 MVP, M3 outbound vs M5 outbound): still apply
+> - "Cuts," "folds," "demotes" decision logic: still apply
+> - Risks + mitigations: still apply
+>
+> Read this doc as a rollout design with TWO superseded items: (1) the 6-module count, (2) implicit assumption Sam has PM background. Everything else is current.
+
+---
+
+## Goal
+
+ICP (Sam — first-time non-technical founder, no PM background, no tech expertise) finds the course **effective and workable**. Graduate ships product to market.
+
+## Success metric (v1)
+
+**First paying customer in 90 days** for a non-technical founder following the course end-to-end.
+
+Continuation outcomes (10 customers + retention; repeatable GTM) deferred to later phases.
+
+## Audience (locked)
+
+Newbie startup founder without tech expertise. Greenfield only. No rescue framing. AI-augmented at every step. Modern tools (Lovable, Supabase, Stripe, Claude) on top of time-tested processes (Foundation Sprint, Mom Test, Lean Startup, JTBD).
+
+**Explicitly NOT served:** burned founders mid-rescue, founders managing existing dev shops with broken builds, founders looking to learn coding.
+
+## Closest competitor
+
+Sophia Matveeva ($2,500, 6 modules, self-paced + coaching). JT differentiates on: free, AI-thread explicit per module, 4 net-new chapters (price-on-smoke-test, AI persona pre-validation, clickable prototype, channel selection) that no competitor teaches.
+
+---
+
+## Architecture: 6-module core spine
+
+### Module 1 — Form the Hypothesis
+
+- **Outcome:** One-sentence falsifiable claim with customer + problem + approach + competition + differentiation
+- **Signal:** Reads cleanly aloud to a stranger
+- **AI-augmented method:** Claude "assumption extractor" prompt against the founder's raw brain-dump
+- **Chapters:**
+  - `form-your-founding-hypothesis-90-minute-sprint` (KEEP, possibly minor reframe to add AI prompt sidebar)
+
+### Module 2 — Test Demand Cheap
+
+- **Outcome:** Smoke-test landing page WITH Stripe price button live
+- **Signal:** ≥5% click-to-payment-intent
+- **AI-augmented method:** AI-generated landing copy variants + Stripe link
+- **Chapters:**
+  - `smoke-test-landing-page-300-dollar-validation` (REFRAME — add Stripe price-button section)
+  - **NEW:** `price-hypothesis-on-smoke-test-page` — dedicated chapter on adding the Stripe link / fake checkout button + interpreting payment-intent clicks vs form-fills
+
+### Module 3 — Validate the Problem
+
+- **Outcome:** 10 Mom Test interviews + 2-hour Lovable clickable prototype shown to 5 of those 10
+- **Signal:** ≥3/10 articulate problem unprompted AND demonstrate prototype flow without coaching
+- **AI-augmented method:** Claude personas pre-validate the question list before booking real interviews; Lovable builds the prototype
+- **Chapters:**
+  - `find-10-people-with-problem-outreach-2026` (KEEP, with REFRAME note below) — **RECRUITMENT chapter**: how to find, reach, and schedule 10 ICP people for unpaid 30-40 min interviews using 2026 channels (Reddit DMs to people who've posted about the problem; Twitter/X DMs in the niche; LinkedIn cold messages to target roles; paid panels via UserInterviews.com or Respondent.io with $25-$100 incentive; community Slack/Discord; personal network referrals; cold email to people from public lists). REFRAME emphasis: this is **interview recruitment**, NOT sales outbound (different motion from Module 6 — see Critical distinctions section below).
+  - `mom-test-ask-about-past-not-future` (REFRAME — fold in the synthesis from `validated-problem-statement-decide-whats-next`) — **interview technique chapter**: ask about past behavior, not future intent
+  - `validated-problem-statement-decide-whats-next` (FOLD into mom-test as closing section) — **synthesis section**: the one-page validated problem statement deliverable
+  - **NEW:** `ai-persona-pre-validation-mom-test-prep` — Claude personas to sharpen interview questions BEFORE real bookings (positioning: AI-as-rehearsal, not replacement). Run AI personas → identify weak questions → revise before burning real interview slots
+  - **NEW:** `clickable-prototype-validation-2-hour-lovable` — 2-hour Lovable prototype as the third validation pillar. **THROWAWAY artifact**, distinct from Module 5 MVP (see Critical distinctions section below)
+- **Module-level cuts:** `market-type-existing-resegmented-new` (theoretical, no artifact, increases drop-off for newbie ICP)
+
+### Module 4 — Design from Evidence
+
+- **Outcome:** One-page Product Brief drafted from interview transcripts (job stories, not features)
+- **Signal:** A stranger can describe target user, job, and scope from the brief alone
+- **AI-augmented method:** Claude "transcript-to-brief" prompt — paste raw notes, output job stories + ranked assumption list
+- **Chapters:**
+  - `one-page-product-brief-vibe-prd` (KEEP, possibly minor reframe to add AI transcript prompt)
+  - `stop-specifying-features-start-outcomes` (KEEP)
+
+### Module 5 — Build It Yourself
+
+- **Outcome:** Live Lovable + Supabase + Stripe MVP at a real URL, ownership locked Day 1
+- **Signal:** URL is live AND founder owns every credential (GitHub, AWS root, domain, database)
+- **AI-augmented method:** Lovable + Supabase + Stripe + Cursor for one-off code edits
+- **Chapters:**
+  - `should-you-hire-2026-decision-tree` (REFRAME — change from "two equal paths" to "self-serve is the default; hiring is a ceiling-signal trigger")
+  - `self-serve-mvp-stack-lovable-supabase-stripe-2026` (REFRAME — position as the default path, not one of two)
+  - `github-aws-database-ownership-checklist` (KEEP — Day-1 setup task, NOT a management appendix item)
+  - `vibe-coding-ceiling-signals` (REFRAME — proactive monthly monitoring habit starting at Week 2 of building, not post-rescue diagnostic)
+
+### Module 6 — First Paying Customer
+
+- **Outcome:** One paying customer through a deliberately chosen channel
+- **Signal:** One payment received AND founder names which channel produced it AND why
+- **AI-augmented method:** Claude maps customer segment to channel fit; AI-personalized outbound copy
+- **Chapters:**
+  - `must-have-segment-pmf-test` (KEEP — Sean Ellis 40% test before paid ads)
+  - `first-ten-customers-personal-network` (KEEP — Lenny's 60% personal-network rule)
+  - `paid-pilot-charge-before-ship` (KEEP — Design Partner Agreement)
+  - `outbound-without-sales-team` (KEEP — **SALES outbound chapter**: cold-email/LinkedIn sequences to convert paying customers 11-20. Distinct motion from Module 3's recruitment outbound)
+  - **NEW:** `channel-selection-before-outbound` — decision framework before tactics; Claude maps segment to channel fit
+- **End of Module 6 — "Going further" callout** linking to:
+  - `customers-leaving-churn-triage-not-acquisition` (continuation: retention)
+  - `pivot-or-persevere-decision-framework` (continuation: pivot decision)
+  - Hire-track reference page (collapsed from 4 hire-track chapters)
+
+---
+
+## Critical distinctions (must be explicit in chapter prose)
+
+Two pairs of activities use similar tools / similar verbs but are DIFFERENT motions with different rules. Chapter prose MUST make these distinctions explicit; otherwise founders conflate them and either over-invest or under-invest at each stage.
+
+### Distinction 1: M3 prototype vs M5 MVP (both use Lovable)
+
+| Dimension | M3 prototype | M5 MVP |
+|---|---|---|
+| Purpose | Validation: "do users navigate this?" | Production: "do users keep using this?" |
+| Time invested | 2 hours | Days to weeks |
+| Audience | 5 of the 10 interview subjects from M3 | Real signups + paying customers |
+| Throwaway? | **YES — disposable, discarded after validation** | NO — live product |
+| Backend | None or faked (no real auth, no Stripe, no DB) | Supabase + Stripe + auth |
+| Polish | Sketch-grade, fake-data acceptable | Production-grade |
+| Domain | lovable.dev preview URL | Real custom domain |
+| Decision driven | "Should we BUILD this for real?" | "Should we SCALE this?" |
+
+**Required prose in M3 prototype chapter:** "This prototype is throwaway. You will discard it after validation. Do not invest in production polish, real auth, or payment integration. The MVP in Module 5 is built differently."
+
+**Required prose in M5 self-serve-mvp-stack chapter:** "You do NOT polish your Module 3 prototype into the MVP. The prototype was throwaway by design. The MVP is built fresh with production rigor — real auth, real Stripe, real domain, real user data."
+
+### Distinction 2: M3 outbound (interview recruitment) vs M6 outbound (sales)
+
+| Dimension | M3 outbound | M6 outbound |
+|---|---|---|
+| Goal | Recruit for unpaid 30-40 min interview | Convert to paying customer |
+| Ask | "Can I learn from your experience for 30 min?" | "Can I send you the pilot contract?" |
+| Message length | Short, single message, low friction | Sequence (3-5 touches), qualifying questions |
+| Channels | Reddit DMs, Twitter/X DMs, LinkedIn, UserInterviews.com / Respondent.io paid panels, community Slack/Discord, personal network referrals, cold email to public lists | Cold email, LinkedIn outreach, personal network, founder-led sales |
+| Reciprocity | Time-for-insight or small incentive ($25-$100 panel rate) | Money-for-product |
+| Volume target | 30-50 outreach to land 10 interviews | 100-200 outreach to land 5-10 customers |
+| Conversion bar | Reply rate ≥20%; show-rate ≥50% of replies | Reply rate ≥5%; meeting-to-paid ≥20% of meetings |
+
+**Required prose in M3 find-10-people chapter:** "This is interview recruitment, not sales. You are asking for time and insight, not money. Different message template, different channels emphasized, different reciprocity. Do not use the Module 6 cold email script here — it will scare interview subjects who don't yet know you have a product."
+
+**Required prose in M6 outbound-without-sales-team chapter:** "This is sales outbound, not interview recruitment. You are asking for money, not time. The 10 people you interviewed in Module 3 may or may not become customers — outreach to them goes through this chapter's sales sequence, not the Module 3 recruitment script."
+
+---
+
+## Components — chapter actions
+
+### Cuts (5 chapters deleted entirely)
+
+| Slug | Reason |
+|---|---|
+| `salvage-vs-rebuild-software-project` | Rescue framing; ICP doesn't have a build to salvage |
+| `switch-dev-shops-safely-transition-guide` | Rescue framing; assumes hired team to leave |
+| `cheap-developers-expensive-without-cto-review` | Rescue-flavored; assumes already-bad hire |
+| `asked-simple-admin-panel-built-spaceship` | Rescue anecdote; over-engineering case study not needed for greenfield newbie |
+| `market-type-existing-resegmented-new` | Theoretical, no artifact, increases drop-off |
+
+### Folds (1 chapter merged into another)
+
+| From | Into |
+|---|---|
+| `validated-problem-statement-decide-whats-next` | `mom-test-ask-about-past-not-future` (as closing synthesis section) |
+
+### Demotes (10 → reduced to ~5 published pages)
+
+**Hire-track (4 → 1 page collapse):**
+- `who-where-hire-developer-2026-ai-augmented-offshore`
+- `fractional-cto-bridge-5-hours-week`
+- `hiring-interview-catches-ai-theater`
+- `reading-sow-clause-by-clause`
+- → Collapsed into ONE reference page: `hire-track-supplementary-reference` (or similar slug). Linked from Module 6 "Going further" callout.
+
+**Management (4 → standalone SEO pages, stripped course-nav):**
+- `engineering-org-chart-non-technical-founder`
+- `friday-demo-rule-founder-progress`
+- `three-questions-turn-standup-into-proof`
+- `weekly-dev-report-template-founders`
+- → Stay as published pages for SEO traffic on management queries; remove course-nav table; add "supplementary - return when you have a hired team" callout.
+
+**AI-era hygiene (3 → standalone SEO pages, stripped course-nav):**
+- `agency-uses-ai-follow-up-questions`
+- `ai-token-bill-dev-shop-pass-through-cost`
+- `slopsquatting-ai-supply-chain-attack`
+- → Same treatment: standalone SEO with stripped course-nav and "supplementary - relevant after you've shipped" callout.
+
+### Reframes (7 surviving chapters with significant edits)
+
+| Slug | Reframe direction |
+|---|---|
+| `should-you-hire-2026-decision-tree` | "Self-serve is the default; hiring is a ceiling-signal trigger" — flip the premise from parallel paths to sequential gate |
+| `self-serve-mvp-stack-lovable-supabase-stripe-2026` | Position as the default Module 5 path; hire-track becomes optional sidebar |
+| `vibe-coding-ceiling-signals` | Proactive monthly monitoring (Week 2 onward), not post-rescue diagnostic |
+| `smoke-test-landing-page-300-dollar-validation` | Add Stripe price-button section (Gap 1 from research) |
+| `mom-test-ask-about-past-not-future` | Add fold-in synthesis section from validated-problem-statement chapter |
+| `must-have-segment-pmf-test` | Light reframe — emphasize as opening of Module 6 (PMF gate before outbound) |
+| `tech-for-non-technical-founders-2026` (landing) | Full restructure from new 6-module spine |
+
+### New chapters (4 — full briefs in 20.08 audit)
+
+1. `price-hypothesis-on-smoke-test-page` (Module 2)
+2. `ai-persona-pre-validation-mom-test-prep` (Module 3) — **headline candidate for viral recommendation if we revisit positioning**
+3. `clickable-prototype-validation-2-hour-lovable` (Module 3)
+4. `channel-selection-before-outbound` (Module 6)
+
+### Module 0 deleted entirely
+
+`course-map-self-assessment-non-technical-founder-2026` — page deleted, 301 redirect to landing. Foundation concepts distribute to the chapter where each first appears (just-in-time learning). "The simplest path" callout migrates to landing.
+
+---
+
+## Data flow: learner journey
+
+```
+Landing page (free, no signup)
+   ↓
+Module 1 (90 min) → Hypothesis written
+   ↓
+Module 2 (1 hr) → Smoke test live with Stripe button
+   ↓ (signal gate: ≥5% payment-intent)
+Module 3 (1.5 hr) → 10 Mom Test interviews + Lovable prototype
+   ↓ (signal gate: ≥3/10 articulate + demo flow)
+Module 4 (1 hr) → Product Brief drafted
+   ↓
+Module 5 (2 hr) → Live MVP at staging URL
+   ↓
+Module 6 (1 hr) → First paying customer
+   ↓ (success metric reached)
+"Going further" callout → continuation chapters (optional)
+```
+
+Total reading time: ~7 hours. Total project time (interviews, building, sales): 90 days target.
+
+---
+
+## Error handling: what happens if learner stalls
+
+- **Stall in Module 2 (smoke test fails ≥5%):** chapter teaches iterate-or-kill rather than push through. Reader returns to Module 1 to revise hypothesis.
+- **Stall in Module 3 (interviews don't validate):** chapter explains "the hypothesis is the problem, not the interview technique." Return to Module 1 with new hypothesis informed by interview surprises.
+- **Stall in Module 5 (build hits Lovable ceiling):** ceiling-signals chapter triggers the hire-track callout (continuation reference page).
+- **Stall in Module 6 (no first customer in 90 days):** continuation chapters (pivot or persevere; churn triage if customers churn fast) provide next steps.
+
+---
+
+## Phase 1 execution sequence
+
+Per Approach 3 + audit findings:
+
+1. **Spine restructure (mechanical):** apply cuts (5), folds (1), demotions (10 → ~5 pages). Slug fix for "Your First Customer Is Not Marketing" (missing slug in YAML). No URL renames yet.
+2. **Module 0 deletion:** delete `course-map-self-assessment-non-technical-founder-2026/` directory, add 301 redirect to landing page in Hugo config. Distribute 9 foundation concepts into chapter openings where each first appears.
+3. **Reframe 7 surviving chapters (voice-sensitive):** per-chapter agent dispatch with `reflexion-reflect` voice gate before handback. One chapter per dispatch to keep voice quality high.
+4. **Write 4 new chapters (voice-sensitive):** per-chapter agent dispatch with full brief (from 20.08 audit), `reflexion-reflect` voice gate, AI-as-rehearsal positioning where applicable.
+5. **Rebuild data/course_sequence.yaml:** assemble final 6-module sequence from surviving + new chapters. No 6A/6B renumbering (deferred — title clarity compensates).
+6. **Rebuild landing page Module index:** from new 6-module spine with "Start here if..." per module.
+7. **Add "Going further" callout to end of Module 6:** links to continuation + hire-track reference.
+8. **Verify:** `bin/hugo-build`, `bin/test` (visual regression), link integrity check (every internal `/blog/X` link resolves), voice rubric pass on new + reframed chapters.
+
+---
+
+## Out of scope for Phase 1
+
+- Formal continuation modules 7-8 (the customers-leaving + pivot-or-persevere chapters stay accessible but NOT promoted as separate modules)
+- Advanced modules 9-10 for repeatable GTM
+- 6A/6B slug renumbering (defer — keep current slugs to avoid 404s; clearer titles compensate)
+- Topic ID convention overhaul beyond the 6 core modules
+- True PDF artifact generation (deleted from todo)
+- Course completion analytics infrastructure (start with manual feedback survey)
+- Email gate / signup flow (course remains free, no signup, per ICP fit)
+
+---
+
+## Risks + mitigations
+
+| Risk | Mitigation |
+|---|---|
+| Voice-sensitive content (7 reframes + 4 new) drifts from voice guide | Per-chapter dispatch with `reflexion-reflect` gate before handback; one chapter per dispatch |
+| Module 0 redirect breaks in production | Test redirect in Hugo build BEFORE merging; verify URL resolves to landing |
+| 6A/6B titles unchanged but slugs unchanged → reader sees inconsistency | Reframe titles to read consistently with new spine; slugs are URLs, titles are display text — they CAN diverge |
+| "Going further" callout discoverability low | Place at end of Module 6 (last core chapter) AND on landing as a "after Module 6" sidebar |
+| No analytics → can't measure outcomes | Phase 1 uses manual feedback survey ("did you ship?"). Analytics infra is Phase 2. |
+| Codex cross-check (in flight) flags new risks | Wait for codex result before starting execution; integrate findings into implementation plan |
+
+---
+
+## Open items (none blocking — proceed once spec approved)
+
+- Codex cross-check on Phase 3 plan still running (task `adba6de71c679b138`); findings to be integrated into implementation plan
+- Final naming for the 4 new chapters — slug proposals are starter; refine when chapter is written
+- Final naming for the 1 collapsed hire-track page
+
+---
+
+## Definition of done (Phase 1 complete)
+
+- 6-module spine live on landing page
+- 4 new chapters published
+- 7 reframed chapters republished
+- 5 cuts removed; 1 fold merged; 10 demotions applied
+- Module 0 deleted with working redirect
+- `data/course_sequence.yaml` reflects new spine
+- All chapter pages pass `bin/hugo-build` and `bin/test`
+- Voice rubric pass on all new + reframed content
+- Manual feedback survey link in place at end of Module 6
+
+---
+
+## Next step (per brainstorming skill flow)
+
+After your file-level review of this spec, invoke `writing-plans` skill to produce the per-step implementation plan. Implementation plan converts each item above into specific agent dispatches with success criteria.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.10-sequence-decision-validate-vs-smoke-test.md b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.10-sequence-decision-validate-vs-smoke-test.md
new file mode 100644
index 000000000..526087924
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.10-sequence-decision-validate-vs-smoke-test.md
@@ -0,0 +1,177 @@
+# Sequence Decision: Module 2 (Smoke-Test) vs Module 3 (Validate) Order
+
+**Date**: 2026-05-20
+**Status**: ✅ **DECIDED — kept current order + applied $0-budget reframe + merged Module 1+2 into one Foundation module**
+**Driver**: ICP-E review (40.01, deleted 2026-05-20) flagged the current Module 2 → Module 3 order as backwards for the burned non-technical founder.
+
+---
+
+## Decision (added 2026-05-20, after Click chapter re-read)
+
+After user pushback and re-verification of the canonical sources, the decision is to **KEEP** the smoke-test-first sequence rather than swap. Two corrections invalidated the swap recommendation that follows below:
+
+**Correction 1 — Click's "Experiment" phase is landing-page-class, not prototype-class.** The earlier research synthesis (below) conflated Click's "Experiment" chapter with the heavier Design Sprint (5-day prototype + 5-user test). Sources confirm Foundation Sprint produces a hypothesis + lightweight experiment plan (landing page / fake door). The heavier Design Sprint is a separate, OLDER process. So Click's actual sequence is **Hypothesis → lightweight Experiment (landing page) → Design Sprint (prototype + 5-user test) → Build**. This matches our current spine exactly:
+
+```
+Module 1 (Hypothesis & Smoke-Test) = Foundation Sprint output
+Module 2 (Validate: Mom Test + AI persona + clickable prototype) = Design Sprint class
+Modules 3-5 (Brief → Build → First Customer)
+```
+
+**Correction 2 — the smoke-test chapter is a landing page used as positioning artifact, not strictly a paid-ads demand test.** The reviewer's argument ("don't ask burned founders to spend $300-500 on ads before talking to anyone") was anchored on the paid-ads layer. Per user feedback: drop the paid-ads requirement, use any free site builder (Neeto/Carrd/Framer free tier), share the landing page in interview invites — and the $0 reframe eliminates the burned-founder friction.
+
+**Action taken (commit `115c3236`)**:
+- Kept smoke-test-first sequence
+- Merged Module 1 (Hypothesis) + Module 2 (Smoke-Test) into a single 3-chapter Module 1 (Hypothesis & Smoke-Test) — eliminating the orphan 1-chapter Module 1
+- Renumbered downstream modules to 5-module spine
+- Added $0-budget callouts to Ch 1.2 (smoke-test), Ch 4.3 (self-serve-mvp-stack), Ch 5.5 (outbound)
+
+**The original research analysis below remains accurate as a research log, but its "Recommendation: Option A — Swap" conclusion is superseded by the decision above.**
+
+---
+
+---
+
+## The question
+
+Current spine puts smoke-test landing page + price hypothesis (Module 2) BEFORE problem-validation interviews + Mom Test + prototype (Module 3). Reviewer argues this is backwards for the ICP-E (burned non-technical founder).
+
+```
+CURRENT:
+1. Hypothesis  →  2. Smoke-test ($300-500 ads)  →  3. Validate (interviews)  →  4. Brief  →  5. Build  →  6. First customer
+
+PROPOSED (R1#1 swap):
+1. Hypothesis  →  2. Validate (interviews)  →  3. Smoke-test ($300-500 ads)  →  4. Brief  →  5. Build  →  6. First customer
+```
+
+---
+
+## Evidence from canonical CustDev sources
+
+| Source | Year | Explicit sequencing | Verdict |
+|---|---|---|---|
+| **Steve Blank — Customer Development** | 2005 | 4-step framework: Customer Discovery (problem interviews) → Customer Validation (smoke-test / early sales) → Customer Creation → Company Building. **Discovery comes BEFORE Validation.** | Swap-aligned |
+| **Eric Ries — Lean Startup** | 2011 | Built on Blank's Customer Development. MVP can be a landing page, but Discovery (interviews) precedes Validation (MVP/smoke-test). Build-Measure-Learn loop assumes a hypothesis grounded in customer conversations. | Swap-aligned |
+| **Rob Fitzpatrick — The Mom Test** | 2013/2024 | Direct quote: "Once you find consistent problems across multiple interviews, then (and only then) should you begin building solutions." The "build" prohibition includes landing pages with paid traffic. | Swap-aligned (strongly) |
+| **Y Combinator — How to Talk to Users** (Migicovsky, Alströmer) | 2018+ | "Talk to your users" mantra. User interviews start at problem-discovery stage, BEFORE significant build (which includes landing pages with paid traffic). | Swap-aligned |
+| **Sophia Matveeva — Tech for Non-Technical Founders** (HBR/Oxford/LBS) | 2024+ | "Validate hypotheses on a spreadsheet first." Customer-discovery work before any landing page or ad spend. | Swap-aligned |
+| **Knapp & Zeratsky — Click / Foundation Sprint** | 2025 | TOC: Customer → Competition → Differentiation → Principles → Options → Hypothesis → **Experiment** → System. "Experiment with tiny loops until your solution clicks. Then build." Foundation Sprint → Design Sprint (5-day prototype + 5-user test). Tests are user-interview-on-prototype, not paid-ads demand test. | Swap-aligned (implicit) |
+| **Founder Institute Vibecode Bootcamp** (Drew Falkman) | 2026 | Compressed 10-day sprint: idea → MVP → first customers. Combines interviews + smoke-test + early build in parallel. LESS prescriptive about strict order; doesn't argue smoke-test-first. | Neutral |
+| **Lenny Rachitsky** (cited "must-read" for Click) | 2025 | Endorses Foundation Sprint sequence — Hypothesis precedes Experiment. | Swap-aligned (implicit) |
+
+**Counter-argument sources searched**: no canonical CustDev source explicitly recommends paid smoke-test BEFORE customer interviews. The smoke-test-first pattern appears mostly in growth-marketing playbooks (where the assumption is the problem is already validated and you're testing demand for a specific solution). For pre-PMF founders, the literature is consistently interviews-first.
+
+---
+
+## ICP-E-specific argument (psychological / safety)
+
+Reviewer's case for the swap:
+- The ICP arrives skeptical of spending money on the wrong thing.
+- Module 2 says "build a landing page and spend $300-500 on ads" BEFORE Module 3 says "validate the problem with conversations."
+- For a burned founder, this reads as: *"You just lost money on the wrong thing. Now we're asking you to spend more money before you even talk to anyone."*
+- Interview cost: $0-50 (free Reddit DMs / coffee / time).
+- Smoke-test cost: $300-500 (ad spend) + landing page setup time.
+- For risk-averse burned founders, the lower-cost step should come first.
+
+---
+
+## Counter-argument (why current order might still be right)
+
+1. **Speed signal:** A $300 ad campaign can reach 10,000+ people in days; interviews can reach 10-20 in 1-2 weeks. Smoke-test gives a faster directional signal.
+2. **Practical parallelism:** In real founder execution, interviews and smoke-tests can run in parallel (Week 1-2 interviews + Week 1-3 landing page test). Strict sequential ordering isn't required.
+3. **Discovery-of-ICP value:** If the founder doesn't know who their ICP is, the smoke-test ad targeting can reveal which audience clicks — i.e., it can discover the ICP, not just validate demand. This is a less-discussed but real benefit.
+4. **Current course addresses this:** Chapter 2.2 (Price Hypothesis) explicitly says "validate the problem in Module 3 before scaling spend in Module 2." The course already acknowledges the sequence tension internally — so reordering may break narrative coherence within Module 2.
+
+---
+
+## Three options
+
+### Option A — Swap (matches reviewer recommendation + canonical CustDev)
+
+```
+1. Hypothesis  →  2. Validate (interviews + Mom Test + AI persona + prototype)  →  3. Smoke-test + price  →  4. Brief  →  5. Build  →  6. First customer
+```
+
+**Cascade cost (mechanical):**
+- Rename old 2.1, 2.2 → 3.1, 3.2 in:
+  - `data/course_sequence.yaml` (re-order entries + relabel)
+  - 2 chapter `title:` + `og_title:` (smoke-test, price-hypothesis)
+  - 2 chapter callouts (`Module 2 → Module 3`)
+  - All cross-refs to "Chapter 2.1", "Chapter 2.2" in OTHER chapters' body text + Mermaid + SVG
+- Rename old 3.1, 3.2, 3.3, 3.4 → 2.1, 2.2, 2.3, 2.4 in:
+  - YAML (4 entries reorder + relabel)
+  - 4 chapter `title:` + `og_title:` (ai-persona, find-10-people, mom-test, clickable-prototype)
+  - 4 chapter callouts (`Module 3 → Module 2`)
+  - All cross-refs in OTHER chapters
+- Update the routing block I added to Ch 1.1 on 2026-05-20 (Chapter 5.2 / 5.1 references unchanged)
+- Update the Magic Lenses Money skip-guidance line ("smoke test gives you real conversion data" — references Chapter 2.1 currently, needs to become Chapter 3.1)
+- Cover images: stay (Stitch covers don't show chapter numbers in their visible text)
+
+Estimated touch: 6 chapter files (heavy renames) + YAML + ~15-25 cross-ref edits in other chapters + 1 routing block. ~4-6 hours of careful work.
+
+**Risk:** SEO impact — slug stays (no URL change) but H1/title visible text changes. Internal-link existence stays correct (slugs unchanged). Mermaid diagrams that name "Module 3.2" etc. need to update.
+
+### Option B — Merge into single "Validate" module (radical restructure)
+
+```
+1. Hypothesis  →  2. Validate Bundle (interviews + smoke-test + prototype, all in parallel over 4-6 weeks)  →  3. Brief  →  4. Build  →  5. First customer
+```
+
+Drops one full module slot. 5-module spine instead of 6. Matches real-world founder execution (parallel tracks). But:
+- Larger cascade (rename Module 4→3, 5→4, 6→5)
+- Loses the "two distinct phases" framing that helps non-technical founders grasp the validation cycle
+- Risk: makes Module 2 too big (5 chapters: hypothesis, interviews, prototype, smoke-test, price)
+
+**Not recommended** — too radical for the marginal gain over Option A.
+
+### Option C — Keep current order, soften the bridge
+
+```
+1. Hypothesis  →  2. Smoke-test (UNCHANGED, but add warning)  →  3. Validate (UNCHANGED)  →  4. Brief  →  5. Build  →  6. First customer
+```
+
+Add a top-of-Module-2 warning callout:
+> **About this module's place in the sequence:** Most CustDev frameworks (Steve Blank, Rob Fitzpatrick's Mom Test, Y Combinator) recommend customer interviews BEFORE any paid spend. We put smoke-test first in this course because it gives you a faster directional signal (10,000 ad impressions in days vs. 10 interviews in 2 weeks). If you're a burned founder skeptical about spending more before talking to anyone, **skip Module 2 and start at Module 3 (Validate)**. Come back to Module 2 once you have problem signal from real conversations.
+
+Zero cascade. Acknowledges the canonical position. Routes the skeptical reader correctly.
+
+**Risk:** course still misaligns with canonical sequence on the default path. Founders who don't read the warning will follow the wrong order.
+
+---
+
+## Recommendation
+
+**Option A — Swap**, despite the cascade cost.
+
+Why:
+1. **Canonical alignment is high-value for a free educational course.** Every major CustDev framework (Blank, Fitzpatrick, YC, Matveeva, Lean Startup) puts interviews first. Misaligning with all of them creates credibility risk: a knowledgeable reader will spot the inversion and lose trust.
+2. **ICP-E psychological safety argument is strong.** The course pitches itself to burned founders who shouldn't be asked to spend more money before they've talked to a customer.
+3. **Cascade is mechanical, not intellectual.** It's slug-stable (URLs don't change), title/callout/cross-ref rename. ~4-6 hours of focused work, fully verifiable via Hugo build + a grep-for-stale-refs pass.
+4. **The "validate as discovery" argument** (smoke-test reveals the ICP) is real but rarely needed: most JT ICP-E founders already have a hypothesis about who their customer is — they need to verify the problem, not discover the segment.
+
+**Lower priority but worth considering:** add the Option C warning callout to Module 2 EVEN AFTER the swap, framed differently — "Why interviews come first in this course" — so the deliberate choice is visible to readers.
+
+---
+
+## What to do next (proposed flow)
+
+1. **Decision gate:** user approves Option A (or rejects in favor of B / C / status quo)
+2. **Cascade plan:** branch off `module-8-first-paying-customer`, do the rename in one focused commit (Release 9?)
+3. **Verification:**
+   - Hugo build clean
+   - `grep -rn 'Chapter [23]\.' content/blog/*/index.md` to confirm no stale numbering
+   - chrome-devtools spot-check on 6 affected chapters
+4. **PR #345 update:** the swap is an additive change (Release 9), not a history rewrite
+
+---
+
+## Sources
+
+- Steve Blank, *Four Steps to the Epiphany* (2005); steveblank.com Customer Development category
+- Eric Ries, *The Lean Startup* (2011)
+- Rob Fitzpatrick, *The Mom Test* (2013, 2024 reprint)
+- Eric Migicovsky / Gustaf Alströmer, YC Startup Library "How to Talk to Users"
+- Sophia Matveeva, *Tech for Non-Technical Founders* program (HBR / Oxford / LBS)
+- Jake Knapp & John Zeratsky, *Click* (Simon & Schuster, April 2025); character.vc/click; Lenny's Newsletter "Introducing the Foundation Sprint"
+- Drew Falkman, Founder Institute Vibecode Bootcamp (2026)
+- Internal: `docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.02-curriculum-sequence-synthesis.md`
diff --git a/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.11-course-migration-roadmap.md b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.11-course-migration-roadmap.md
new file mode 100644
index 000000000..6296d28e9
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.11-course-migration-roadmap.md
@@ -0,0 +1,218 @@
+# Strategic Roadmap: v2 Micro-Lesson Migration
+
+**Project**: PRD-2605-001 — Tech for Non-Technical Founders 2026
+**Date**: 2026-06-10
+**Format**: Now / Next / Later — dependency-aware
+**Source**: `.agent/tasks.json` + `TASK-TRACKER.md` "Course Migration Schedule"
+
+---
+
+## 1. Strategy Context
+
+### Business Goal
+Convert the v1 long-form course (5 modules, 18 chapters, 2,000-4,500 words each) into a v2 micro-learning course (24 core + 4 optional micro-lessons, 400-900 words each) following the 8-part template (30.03 §2). Ship module-by-module with each module independently live-able.
+
+### Customer Problem (Sam)
+Sam (first-time non-technical founder, 2-4 hr/week) can't consume 4,000-word long-form chapters. She needs 5-10 minute micro-lessons with immediate action steps, success checks, and error recovery. The 40.08 gap report confirms: 0 of 21 chapters pass the v2 template.
+
+### Constraints
+- **No hard deadline** — v2 is a quality improvement, not a fire drill
+- **Module-by-module shipping** — each module goes live independently; never block the whole release on the last module
+- **Atomic commits** — 1 lesson per commit, never batch
+- **Bridge chain integrity** — every lesson names the specific dependency the next lesson needs
+- **Phase 0 deferred** — mechanical quick wins (outcomes, success checks, Stuck? boxes) postponed until pilot lessons complete per user direction (2026-06-10)
+
+### Success Metrics
+| Metric | Current | Target |
+|---|---|---|
+| Median template score | 1.0/8 (all v1 chapters) | 7.0+/8 (all v2 lessons) |
+| Lessons with 8-part template | 2 (pilots only) | 24 (core path) |
+| Hugo build + validate-course | 3/4 validators pass | 4/4 pass |
+| Mobile viewport (375px) | manual | 100% verified |
+
+---
+
+## 2. Roadmap: Now / Next / Later
+
+### 🔵 NOW — Phase 2 Module 1 Migration (~2-3 days)
+
+**Epic hypothesis**: We believe that migrating Module 1 (highest conversion leverage — where Sam decides to stay or leave) to the 8-part template will validate the pilot pattern at scale and build momentum for M2-M5.
+
+| TASK | Initiative | Micro-Lessons | Est. Time | Dependencies | Outcome |
+|---|---|---|---|---|---|
+| TASK-1 | 🔧 Prerequisites verification | — | 10 min | — | Gate passed: Hugo green, validators running, specs accessible |
+| TASK-2 | M1.1 Founding Hypothesis | 2 (Mad Libs + 4-lens scoring) | ~90 min | TASK-1 | Hypothesis sentence artifact + Magic Lenses gate |
+| TASK-3 | M1.2b Smoke Test Run | 1 (channel + budget + go/iterate/kill) | ~45 min | TASK-1 | Conversion signal reading at ≥300 visits gate |
+| TASK-4 | M1.3 Price Hypothesis | 1 (Stripe button + price bands) | ~45 min | TASK-1 | Price number that travels to M5.2 + M5.4 |
+| TASK-5 | ✅ M1 exit gate | — (verification only) | ~30 min | TASK-2,3,4 | Bridge chain verified, Hugo clean, mobile check, M1 live |
+
+**M1 exit criteria**: All 6 micro-lessons (2 pilots + 4 new) follow 8-part template. Bridge chain 1.1a→1.1b→1.2a(pilot)→1.2b-run→1.2b-wire(pilot)→1.3 intact. 3 decision gates preserved (Magic Lenses ≥14/20, ≥300 visits, ≥5% Stripe-click).
+
+---
+
+### 🟡 NEXT — Phase 2 Module 2-3 Migration (~4-6 days)
+
+**Epic hypothesis**: We believe that migrating Modules 2-3 (the validation-to-design handoff) will establish bridge chain patterns for the higher-complexity modules and verify that the 300-word concept block constraint works for interview/synthesis/prototype content.
+
+#### Sprint 2a: M2 Validate the Problem (TASK-6→11)
+
+| TASK | Initiative | Micro-Lessons | Dependencies |
+|---|---|---|---|
+| TASK-6 | M2.1 Mom Test | 2 (5-question script + scoring/synthesis) | TASK-5 (M1 exit gate) |
+| TASK-8 | M2.3a Find People | 1 (ICP map + community discovery) | TASK-6 |
+| TASK-9 | M2.3b Outreach | 1 (templates + booking cadence) | TASK-8 |
+| TASK-10 | M2.4 Clickable Prototype | 1 (Lovable + 5-user test) | TASK-9 |
+| TASK-7 | M2.2 AI Personas [OPTIONAL] | 1 (skip-safe, standalone) | TASK-6 |
+| TASK-11 | ✅ M2 exit gate | — | TASK-6,7,8,9,10 |
+
+**M2 exit criteria**: Core path (2.1→2.3a→2.3b→2.4) produces Validated Problem Statement + vocabulary doc without touching optional 2.2. Bridge chain verified. ≥7/10 strong signals + 4-5/5 prototype passes gates preserved.
+
+#### Sprint 2b: M3 Design from Evidence (TASK-12→14)
+
+| TASK | Initiative | Micro-Lessons | Dependencies |
+|---|---|---|---|
+| TASK-12 | M3.1 Product Brief | 2 (problem statement → Vibe PRD rows) | TASK-11 (M2 exit gate) |
+| TASK-13 | M3.2 Outcomes Check | 1 (feature audit → outcome mapping) | TASK-12 |
+| TASK-14 | ✅ M3 exit gate | — | TASK-12,13 |
+
+**M3 exit criteria**: Brief-to-outcomes handoff tight — bridge from 3.1 names exactly which rows 3.2 audits. Peer-rubric gate preserved. AI-as-peer fallback functional.
+
+---
+
+### ⚪ LATER — Phase 2 M4-M5 + Phase 3 Polish (~3-5 weeks)
+
+#### Sprint 3a: M4 Build It Yourself (TASK-15→20) — HIGHEST technical complexity
+
+| TASK | Initiative | Micro-Lessons | Notes |
+|---|---|---|---|
+| TASK-15 | M4.1 Hire Decision | 1 | Decision tree → path selection |
+| TASK-16 | M4.2 Ownership Audit | 1 | 12-item binary checklist |
+| TASK-17 | M4.3a Stack Tools | 2 | Tool purpose overview + pre-flight rules |
+| TASK-18 | M4.3b Build Phases | 2 | Phases 1-2 (UI+auth) → 3-4 (Stripe+deploy) |
+| TASK-19 | M4.4 Ceiling Signals [OPTIONAL] | 1 | Standalone, skip-safe |
+| TASK-20 | ✅ M4 exit gate | — | RLS/webhook concepts ≤300 words, 5-green-lights gate |
+
+**Risk alert**: Supabase RLS, Stripe webhooks, SQL self-tests are the hardest to compress into 300-word concept blocks. Allow 400-word exceptions with explicit flagging per TASK-TRACKER migration schedule risk mitigation.
+
+#### Sprint 3b: M5 First Paying Customer (TASK-21→26) — HIGHEST emotional stakes
+
+| TASK | Initiative | Micro-Lessons | Notes |
+|---|---|---|---|
+| TASK-21 | M5.1 PMF Test | 1 | Sean Ellis 40% survey + segment hunt |
+| TASK-23 | M5.3 Personal Network | 1 | 8-name audit → outreach motion |
+| TASK-24 | M5.4 Paid Pilot | 2 | DPA template → Stripe deposit + kickoff |
+| TASK-22 | M5.2 Channel Selection [OPTIONAL] | 1 | Standalone, skip-safe |
+| TASK-25 | M5.5 Cold Outbound [OPTIONAL] | 1 | Standalone, skip-safe |
+| TASK-26 | ✅ M5 exit gate | — | DPA template split ≤300 words, core path produces all artifacts |
+
+**Risk alert**: DPA template is the hardest single block to compress. Asking-for-money terror is the highest emotional barrier per 40.06 Sam journey report.
+
+#### Phase 3: Cross-Cutting Polish (TASK-27→34, ~2-3 days)
+
+| TASK | Initiative | Dependencies |
+|---|---|---|
+| TASK-27 | Bridge audit — verify every bridge names a specific dependency | TASK-26 |
+| TASK-28 | Verify core path produces all 6 artifacts (no optional lessons) | TASK-26 |
+| TASK-29 | Verify emotional arc preserved (40.06 trust curve) | TASK-26 |
+| TASK-30 | Mobile viewport test (375px iPhone SE) on all 24+ lessons | TASK-26 |
+| TASK-31 | Full Hugo build + validate-course (4/4 pass target) + link checker | TASK-30 |
+| TASK-32 | Update landing page module maps | TASK-31 |
+| TASK-33 | Update Quickstart to reflect micro-lesson path | TASK-31 |
+| TASK-34 | Final code review + update TASK-TRACKER.md | TASK-32,33 |
+
+---
+
+## 3. Dependency Graph
+
+```
+TASK-1 (prereqs)
+├── TASK-2 (M1.1) ──┐
+├── TASK-3 (M1.2b) ─┤
+└── TASK-4 (M1.3) ──┘
+         ↓
+    TASK-5 (M1 gate)
+         ↓
+    TASK-6 (M2.1) ── TASK-7 (M2.2 [OPT])
+         │
+         ├── TASK-8 (M2.3a)
+         │        ↓
+         │   TASK-9 (M2.3b)
+         │        ↓
+         │   TASK-10 (M2.4)
+         │        ↓
+         └── TASK-11 (M2 gate)
+                  ↓
+            TASK-12 (M3.1)
+            └── TASK-13 (M3.2)
+                      ↓
+                TASK-14 (M3 gate)
+                      ↓
+                TASK-15 (M4.1)
+                ├── TASK-16 (M4.2)
+                ├── TASK-17 (M4.3a)
+                ├── TASK-18 (M4.3b)
+                └── TASK-19 (M4.4 [OPT])
+                          ↓
+                    TASK-20 (M4 gate)
+                          ↓
+                    TASK-21 (M5.1)
+                    ├── TASK-23 (M5.3)
+                    ├── TASK-22 (M5.2 [OPT])
+                    ├── TASK-24 (M5.4)
+                    └── TASK-25 (M5.5 [OPT])
+                              ↓
+                        TASK-26 (M5 gate)
+                              ↓
+                    TASK-27→34 (Phase 3 polish)
+```
+
+**Parallelization opportunities**:
+- TASK-2, TASK-3, TASK-4 can run in parallel within M1
+- TASK-7 [OPTIONAL] can run in parallel with the M2 core chain (TASK-6→TASK-8→TASK-9→TASK-10 — Outreach needs people list, Prototype needs interviewees, so these are sequential)
+- TASK-15, TASK-16, TASK-17 within M4 (after M3 gate)
+- TASK-21, TASK-23 within M5 core (after M4 gate)
+- Phase 3 tasks TASK-27→31 can run in parallel after M5 gate
+
+---
+
+## 4. Risks & Dependencies
+
+| Risk | Probability | Impact | Mitigation | Owner |
+|---|---|---|---|---|
+| Phase 2 stretches past 4 weeks | Medium | Medium | Ship module-by-module. Each module independently live-able. | Content team |
+| Bridge chain breaks during migration | High | Medium | TASK-5,11,14,20,26 verify bridges per module. Phase 3 audit (TASK-27) catches remaining. | Content team |
+| Technical chapters (M4.3) can't compress to 300 words | Medium | Medium | Allow 400-word exceptions for RLS/webhooks. Flag in rewrite notes. | Content team |
+| Phase 0 deferred too long | Low | Low | ~2-3 hours. Execute when pilot lessons stable. Deferred per user direction. | Content team |
+| Mobile viewport issues discovered late | Medium | Medium | TASK-30 is safety net, but test each module at exit gate (TASK-5,11,14,20,26). | Content team |
+| Pilot pattern diverge from 30.03 Appendix A | Low | Medium | 30.03 Appendix A is canonical. Update 30.03 with user approval if pattern needs refinement. | Content team |
+
+---
+
+## 5. What Is NOT on This Roadmap
+
+| Item | Why excluded |
+|---|---|
+| Phase 0 mechanical quick wins | **Deferred** per user direction (2026-06-10). Executed after pilot lessons complete. |
+| v1 surgical polish (Iter 17+) | **Stopped** (2026-06-07). Diminishing returns. Structural format gap solved by migration, not line edits. |
+| New chapters or module restructuring | **Out of scope.** v2 is format migration, not scope expansion. Same 6 artifacts, same emotional arc. |
+| Companion page covers regen (~30 covers) | **P3** — tracked in TASK-TRACKER. Not on migration critical path. |
+| Automated mobile testing (Playwright) | **Future enhancement** — recommended by PM health report (40.10). Not blocking v2 ship. |
+| Burned-founder (Alex) routing improvements | **Deferred** — Alex is website ICP, not course design target (Sam). |
+| AI-era posts refresh | **Q1 2027 trigger** — outside this roadmap's time horizon. |
+
+---
+
+## 6. Timeline Summary
+
+| Horizon | Scope | Lessons | Est. Effort | Cumulative |
+|---|---|---|---|---|
+| 🔵 NOW | Phase 2 M1 (Hypothesis & Smoke Test) | 6 total (2 pilots + 4 new) | ~2-3 days | 6 of 28 |
+| 🟡 NEXT | Phase 2 M2-M3 (Validate + Design) | 9 total (8 core + 1 opt) | ~4-6 days | 15 of 28 |
+| ⚪ LATER | Phase 2 M4-M5 (Build + First Customer) | 13 total (10 core + 3 opt) | ~4-6 days | 28 of 28 |
+| ⚪ LATER | Phase 3 cross-cutting polish | — (verification) | ~2-3 days | Ship-ready |
+
+**Total estimated effort**: ~2.5-4.5 weeks for Phase 2 + ~2-3 days for Phase 3 = **~3-5 weeks total**.
+
+---
+
+*Generated by roadmap-planning agent. Source: `.agent/tasks.json`, `TASK-TRACKER.md` "Course Migration Schedule", `30.03` format spec, `40.10` PM health report.*
diff --git a/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/_ARCHIVED_20.01-course-modules-8-module-spine.md b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/_ARCHIVED_20.01-course-modules-8-module-spine.md
new file mode 100644
index 000000000..49e720a5f
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/_ARCHIVED_20.01-course-modules-8-module-spine.md
@@ -0,0 +1,247 @@
+# Course Modules - Tech for Non-Technical Founders 2026
+
+**Project**: 2605-tech-for-non-technical-founders
+**Last updated**: 2026-05-12 (replaces previous `20.01-content-pillars.md`; pillars structure rejected by user, modules structure adopted)
+
+This document defines the **8-module course architecture**. Each module has:
+
+- **Input**: what the reader brings from the previous module
+- **Output**: the deliverable they walk away with
+- **Checkpoint**: how they know they can move on
+- **Artifact**: the template/worksheet they fill in
+- **Posts**: the individual chapters within the module
+
+The course is a **journey, not a topic list.** A reader who completes the course holds a **Founder OS**: a stack of filled artifacts that document their validated problem, Product Brief, build decision, live MVP, oversight rhythm, contingency plan, and AI interrogation kit.
+
+**Simplest-path doctrine** (memory ref: `feedback_kiss_simplest_solutions_only.md`): main path teaches the simplest method that already works for a solo non-tech founder. Structured frameworks (Foundation Sprint, JTBD Canvas, Shape Up, Continuous Discovery, Impact Mapping, User Story Mapping, Lean Inception, Empathy Mapping, Design Sprint) are demoted to optional "Advanced" sidebars at the bottom of Modules 1, 2, and 5.
+
+---
+
+## Module 0 - Where Are You?
+
+- **Input**: An idea, an instinct, or an ongoing project that feels stuck.
+- **Output**: A self-diagnosis: which module to start with.
+- **Checkpoint**: You know your starting module and can name the next deliverable you'll produce.
+- **Artifact**: Self-Assessment Worksheet (10 questions; outputs your entry module).
+- **Posts**: `0.1 Course Map + Self-Assessment` (net-new).
+
+### The 10 self-assessment questions + routing logic
+
+| # | Question | Answer routes to |
+|---|---|---|
+| 1 | Have you talked to 10+ potential customers about the problem you want to solve? | No → Module 1. Yes → Q2. |
+| 2 | Do you have a one-page written Product Brief (what you're building, for whom, why now)? | No → Module 2. Yes → Q3. |
+| 3 | Have you decided whether to ship self-serve or hire a team? | No → Module 3. Yes → Q4. |
+| 4 | Are you actively shipping software (you have a staging URL real users can click, OR a signed contract with a team)? | No → Module 4A (self-serve) or 4B (hire) based on Q3. Yes → Q5. |
+| 5 | Do you own the GitHub org, AWS root account, domain registrar, and database under your company email? | No → Module 5 (start with 5.5 Ownership Audit). Yes → Q6. |
+| 6 | Are you running a weekly oversight rhythm (Friday demo + standup with the 3 questions + plain-English weekly report)? | No → Module 5. Yes → Q7. |
+| 7 | In the last 30 days, has your team had a milestone slip, a runaway invoice, or a quality issue you can't diagnose? | Yes → Module 6. No → Q8. |
+| 8 | Does your product or team touch AI (Cursor, ChatGPT, vibe coding, AI agents, LLM calls in production)? | Yes → Module 7. No → Q9. |
+| 9 | Do you understand the AI token costs your team is passing through to your invoice? | No → Module 7.2. Yes → Q10. |
+| 10 | Have you ever asked your team to walk you through a real PR they reviewed last week? | No → Module 5.3. Yes → graduate; the curriculum is your reference library now. |
+
+**Routing summary**: most readers route to Module 1, 2, 3, 4A, or 4B at Q1-Q4. Burned founders skip ahead to Q5-Q7 and land in Module 5 or 6. AI-exposed founders branch to Module 7 at Q8.
+
+The artifact prints these 10 questions with checkboxes and a routing flowchart. Reader fills it in 5 minutes, writes their starting module at the top of a Notion doc, and works forward from there.
+
+---
+
+## Module 1 - Validate the Problem
+
+*Idea → Validated Problem*
+
+- **Input**: A hunch.
+- **Output**: A one-page validated problem statement backed by 10+ real conversations.
+- **Checkpoint**: 10 customer interviews complete · one-page problem statement signed by 2 peers/advisors.
+- **Artifact**: Module 1 Toolkit (Outreach Sequence Template + Mom Test Interview Script + Validated Problem Statement Template).
+- **Posts**:
+  - `1.1 Find 10 People with the Problem in 2026` (net-new) - outreach: Reddit / LinkedIn / Discord mining + Clay or Apollo for list building + Lindy AI agent for sequence + paid panels (User Interviews, Respondent) as backup + smoke-test landing page on Carrd/Framer with £100-200 of paid traffic.
+  - `1.2 The Mom Test - Ask About the Past, Not the Future` (net-new) - Rob Fitzpatrick's 5-question script; how to avoid leading questions; what emotional language to listen for.
+  - `1.3 Write Down What You Heard, Decide What's Next` (net-new) - one-page validated problem statement template; the "3 pre-orders = green light" rule.
+- **Advanced sidebar** (optional, for teams): Empathy Mapping (Dave Gray), JTBD Canvas 2 (Jim Kalbach, 2023), Customer Journey, Continuous Discovery (Teresa Torres) + Opportunity Solution Tree.
+
+---
+
+## Module 2 - Design the Solution
+
+*Validated Problem → Product Brief*
+
+- **Input**: Validated problem from Module 1.
+- **Output**: A one-page Product Brief (Vibe PRD) describing what you're building, for whom, why now.
+- **Checkpoint**: One-page Brief signed by 2 advisors/peers.
+- **Artifact**: Vibe PRD Template (Product Brief).
+- **Posts**:
+  - `2.1 Five Tech Words to Stop Nodding At` (drafted) - vocabulary you need to read the answers you'll get back.
+  - `2.2 The One-Page Product Brief (Vibe PRD)` (net-new) - the simplest format: who, what problem, what they currently do, what you'll build, what you won't build, how you'll know it worked.
+  - `2.3 Stop Specifying Features. Start Specifying Outcomes.` (net-new) - one technique that prevents over-engineering. Teaches the job-story format inside as a tactic, not as a framework name. References post 5.6 "Simple Admin Panel → Spaceship" as the cautionary tale. Renamed 2026-05-12 to remove framework leak per `feedback_kiss_simplest_solutions_only.md`.
+- **Advanced sidebar** (optional, for teams): Impact Mapping (Gojko Adzic), Foundation Sprint (Knapp/Zeratsky, *Click* April 2025), Design Sprint (Knapp 2016), Lean Inception (Paulo Caroli), User Story Mapping (Jeff Patton).
+
+---
+
+## Module 3 - Choose Your Build Path
+
+*Product Brief → Build Decision*
+
+- **Input**: Product Brief from Module 2.
+- **Output**: A decision (self-serve OR hire) + a budget for the chosen path.
+- **Checkpoint**: You've decided. Module 4A or Module 4B from here.
+- **Artifact**: Build Path Decision Worksheet.
+- **Posts**:
+  - `3.1 Should You Hire? The 2026 Decision Tree` (net-new) - the Airbnb test (validate without code); Rob Walling's "shed not skyscraper" warning; when DIY is enough.
+  - `3.2 The Fractional CTO Bridge - 5 Hours a Week Beats a Co-founder` (net-new) - the $0-equity alternative to a 50%-equity technical cofounder. **Positioned generically (any Fractional CTO), NOT as a JT offer.** Per pure-lead-magnet doctrine (`feedback_curriculum_is_pure_lead_magnet.md`).
+
+---
+
+## Module 4A - Ship Self-Serve *(branch)*
+
+*Build Decision → Live MVP (self-serve)*
+
+- **Input**: Product Brief + decision to ship self-serve.
+- **Output**: Live MVP at a staging URL real users can click.
+- **Checkpoint**: MVP live · first 5 users testing · 2026 stack working end-to-end.
+- **Artifact**: Self-Serve Stack Walkthrough PDF.
+- **Posts**:
+  - `4A.1 The Self-Serve Stack: Lovable + Supabase + Stripe` (net-new) - what each tool does in plain English, how they connect, what a real founder shipped on this stack. Communities (Lovable Discord, Indie Hackers, No Code Founders) referenced inline.
+  - `4A.2 Vibe Coding Done Right - The 5 Ceiling Signals` (net-new) - when AI builds hit the architectural ceiling. Trigger to route to Module 4B (hire to expand).
+
+---
+
+## Module 4B - Hire & Ship *(branch)*
+
+*Build Decision → Live MVP (hired team)*
+
+- **Input**: Product Brief + decision to hire OR Module 4A ceiling hit.
+- **Output**: Live MVP shipped by a hired team + signed contract that protects you + code in YOUR GitHub org.
+- **Checkpoint**: Contract signed · kickoff scheduled · GitHub org under your email.
+- **Artifact**: Hiring Kit (Where-to-Hire Map + Hiring Interview Script + SOW Reading Guide).
+- **Posts**:
+  - `4B.1 Who You're Hiring in 2026 and Where to Find Them` (net-new) - the AI-Augmented Developer profile ($85-120K Junior with Senior productivity); onshore vs nearshore vs Tier-2 offshore ($15-70/hr Indian cities, LATAM nearshore, US onshore reality).
+  - `4B.2 The Hiring Interview That Catches AI Theater` (net-new) - 7 questions extending the existing "We Use AI" lead magnet; how to verify the engineer can direct AI rather than type prompts.
+  - `4B.3 When Cheap Developers Get Expensive` (wrap: 2510 NEW-L) - the student-developer 20-hour-week trap, the freelancer 5-project trap.
+  - `4B.4 Reading the SOW Clause by Clause` (drafted) - 8 clauses agencies hope you skim.
+
+---
+
+## Module 5 - Manage Your Build
+
+*Hired Team → Working Software*
+
+- **Input**: A team in place + a signed SOW.
+- **Output**: A weekly oversight rhythm running. By month 3 you can tell whether your team is shipping or stalling without reading code.
+- **Checkpoint**: Friday demos running 4 weeks · ownership audit clean · weekly report arriving Mondays.
+- **Artifacts**: Founder Oversight Toolkit (Friday Demo Template + Ownership Checklist + Weekly Report Template + Org Chart Audit Template).
+- **Posts**:
+  - `5.1 The Org Chart Your Dev Shop Won't Draw For You` (drafted) - 6 questions that surface who's actually on your project.
+  - `5.2 The Friday Demo Rule` (wrap: 2510 NEW-J) - the 15-minute weekly ritual that catches fake progress.
+  - `5.3 Three Questions That Turn Standup Into Proof` (drafted) - daily catch-fake-progress script.
+  - `5.4 The Plain-English Weekly Dev Report` (wrap: 2510 NEW-A) - what a real weekly report looks like.
+  - `5.5 Who Owns Your GitHub, AWS, and Database?` (wrap: 2510 NEW-K) - the 12-item ownership audit.
+  - `5.6 You Asked for a Simple Admin Panel; You Got a Spaceship` (wrap: 2510 NEW-I) - Job Stories vs over-engineering; references back to post 2.3.
+- **Verification-layer requirement** (added 2026-05-12 per Alex/ICP-E review): posts 5.2, 5.3, 5.4 must include a "what you cross-check the team's answer against" sidebar. Alex's old shop ran perfectly-formatted standups for 7 months while lying - format was real, content was theater. Posts must teach not just the question but the verification: `git log` for actual commits, AWS billing dashboard for real cost, staging URL clicks by the founder during the call. "Ask the question + verify the answer," not just "ask the question."
+- **Advanced sidebar** (optional, for teams upgrading process): Shape Up (Basecamp - 6-week cycles + appetite + pitches), Continuous Discovery during build (Teresa Torres - weekly interviews continue), User Story Mapping for release planning (Jeff Patton).
+
+---
+
+## Module 6 - When Things Break
+
+*Failed Build → Recovery Decision*
+
+- **Input**: A failed Friday demo · a dropped milestone · a runaway invoice.
+- **Output**: A documented decision (salvage / freeze / rebuild) + a 30/60/90 day plan.
+- **Checkpoint**: Decision documented · recovery plan in flight · independent reviewer signed off.
+- **Artifact**: Salvage vs Rebuild Decision Tree (already drafted).
+- **Posts**:
+  - `6.1 Salvage or Rebuild: A 6-Question Decision Tree` (wrap: 2510 NEW-M) - the 30-minute structured decision.
+  - `6.2 How to Switch Dev Shops Without Losing the Codebase` (wrap: 2510 NEW-C) - the 30-day transition playbook + the "investor legend" trick.
+
+---
+
+## Module 7 - Manage AI-Era Risks
+
+*Running Product → Interrogation System*
+
+- **Input**: A product or team touching AI (most do in 2026).
+- **Output**: A system for interrogating any AI claim, predicting AI costs, and catching supply-chain attacks.
+- **Checkpoint**: You can interrogate any AI claim in 5 minutes · monthly AI cost predicted within ±20% · supply-chain defense agreed in contract.
+- **Artifacts**: AI 5-Question Script (already drafted) + AI Cost Worksheet (net-new).
+- **Posts**:
+  - `7.1 "We Use AI" - Five Follow-Up Questions` (wrap: 2510 NEW-E) - vendor or hire interrogation in 30 minutes; dual-purpose with Module 4B.2.
+  - `7.2 The AI Token Bill Your Agency Forgot to Mention` (wrap: 2510 NEW-D2) - predict and cap pass-through OpenAI/Anthropic charges.
+  - `7.3 Slopsquatting: The Supply Chain Attack Vibe Coding Created` (wrap: 2510 #20) - 2025 attack vector; what your shop must do before merge.
+
+---
+
+## How modules connect (the journey map)
+
+```
+Module 0: Where Are You?
+   │
+   ▼
+Module 1: Validate the Problem        ── advanced: Empathy / JTBD / Journey / Continuous Discovery
+   │
+   ▼
+Module 2: Design the Solution          ── advanced: Impact Mapping / Foundation Sprint / Design Sprint / Lean Inception / User Story Mapping
+   │
+   ▼
+Module 3: Choose Your Build Path
+   │
+   ┌─────────┴─────────┐
+   ▼                   ▼
+Module 4A:         Module 4B:
+Ship Self-Serve    Hire & Ship
+   │                   │
+   │  (ceiling hit?    │
+   │   route to 4B)    │
+   │                   │
+   └─────────┬─────────┘
+             ▼
+Module 5: Manage Your Build            ── advanced: Shape Up / Continuous Discovery / User Story Mapping
+             │
+             ▼
+   (if everything is fine: skip to 7)
+             │
+             ▼
+Module 6: When Things Break (triggered on signal, not always)
+             │
+             ▼
+Module 7: Manage AI-Era Risks (everyone using AI in build)
+```
+
+---
+
+## What this is NOT
+
+- **Not** a "how to learn to code" course. The 100 School / Codecademy / Coding for Entrepreneurs angle is well served by others.
+- **Not** a fundraising or operations course. YC Startup School and Sophia Matveeva own that.
+- **Not** a "build with no-code only" course. Lovable's own community + WeAreNoCode own that.
+- **Not** a cohort. No live sessions, no certificates, no graded assignments. Free, self-paced, readable on a phone at 9pm.
+
+**Primary reader (course ICP):** a non-technical founder going from idea (or a half-built MVP) to first paying customer. They mostly have NOT hired a team yet - the course exists to get them to validated demand and a live MVP before they ever write that check. This is the course ICP and it is distinct from the website lead-generation ICP in `90.10-icp-primary-website-target.md` ("Alex, the Burned Non-Technical Founder"), which targets founders already in a rescue situation.
+
+**Secondary readers (route, don't re-pitch):** founders who are about to hire, currently have a team, or have already been burned. They are routed at the entry point - the landing page "If Your Team Is Already Failing" fast path - to the management/rescue chapters (Modules 4-5 + continuation chapters). Course bodies address the primary idea-stage reader; burned-founder framing belongs on the landing-page fast path and inside the rescue chapters, NOT in the opening of validation chapters. (Per-chapter routing blocks were tried on Ch 1.1 and removed 2026-05-22 - they interrupted the primary reader and duplicated the landing-page router.) The course teaches the simplest path through the decision tree, with structured frameworks available as optional sophistication when team capacity allows.
+
+---
+
+## Pure-lead-magnet positioning (added 2026-05-12)
+
+The course **does NOT sell JT services**. Memory ref: `feedback_curriculum_is_pure_lead_magnet.md`.
+
+- **No service CTAs** anywhere in the 26 posts: no "book a Control Audit," no "schedule a consultation," no "we can help with this."
+- **Authorship credit stays** at the footer of every post: "Built by JetThoughts as part of the free Tech for Non-Technical Founders 2026 curriculum."
+- **Email-gated artifact downloads** are the lead-capture mechanism (standard lead-magnet mechanics).
+- **Module 3.2 Fractional CTO** is generic, not a JT offer.
+- **No "When you need a human" row** in the course-nav table - the nav stays pure module-progression.
+
+## Viral-shareability requirements (added 2026-05-12)
+
+Every post in the 26-post syllabus must include:
+
+1. **Contrarian hook** in the opening 80 words ("Stop looking for a technical co-founder," not "How to find a CTO").
+2. **One quote-tweetable insight** (single sentence, 140-280 chars, stands alone outside the post).
+3. **A specific tactic** the reader can execute this week (not abstract principles).
+4. **A free downloadable artifact** referenced inline.
+5. **A shareable headline structure** (Stop X / N things you get wrong / How X lost $Y / The thing your dev shop won't show you).
+
+Memory ref: `feedback_curriculum_viral_shareability.md`.
+
+The course's success metric is **share velocity + email captures + page-1 SEO ranks**, not consultation bookings.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/_ARCHIVED_20.07-content-plan-tnt-founders-2026.md b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/_ARCHIVED_20.07-content-plan-tnt-founders-2026.md
new file mode 100644
index 000000000..51f617d51
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/_ARCHIVED_20.07-content-plan-tnt-founders-2026.md
@@ -0,0 +1,238 @@
+> **SUPERSEDED (2026-05-20)**: This content plan documents the 26-post / 8-module structure from 2026-05-12. The course shipped as **18 chapters across 5 modules** (Module 1+2 merged into Hypothesis & Smoke-Test on 2026-05-20). See `../../data/course_sequence.yaml` for the current chapter order + per-chapter `goal:` field, and `../GOAL-AT-A-GLANCE.md` for the current strategy summary. This file is kept as a historical planning record.
+
+# Content Plan - Tech for Non-Technical Founders 2026 (26-post course)
+
+**Project**: 2605-tech-for-non-technical-founders
+**Parent plan**: `../../2510-seo-content-strategy/20-29-strategy/20.07-content-plan-icp-e-q2-2026.md`
+**Created**: 2026-05-12 (restructured from 14-post / 4-pillar to 26-post / 8-module)
+**Voice rules**: `../../../90-99-content-strategy/strategy-analysis/90.11-voice-guide.md`
+**Course modules**: `20.01-course-modules.md` (read first for input/output/checkpoint per module)
+
+---
+
+## ⚠️ INTEGRATION RULES - read first
+
+1. **No parallel slugs.** 10 of 26 posts wrap existing 2510 slugs. The 2605 course adds curriculum frame via callout; does NOT create new slugs for existing 2510 entries.
+2. **Course frame in every post.** Top callout `> **Module X · Step N**` after frontmatter + bottom `## Continue the course` 9-row module nav table with current module marked.
+3. **Simplest method on main path.** Structured frameworks (Foundation Sprint, JTBD Canvas, Shape Up, Impact Mapping, Continuous Discovery, User Story Mapping, Lean Inception, Empathy Mapping, Design Sprint) appear ONLY in "Advanced (optional)" sidebar at the bottom of Modules 1, 2, and 5. Memory: `feedback_kiss_simplest_solutions_only.md`.
+4. **All voice rules apply.** No length caps; cut test per section. Engagement first.
+5. **≥3 handmade infographics per post** (Mermaid + sketchy SVG mix; Excalidraw aesthetic). Memory: `feedback_infographics_required.md`.
+6. **Tech-stack defaults**: Rails/Django/Laravel + full-stack pattern. Memory: `feedback_jt_tech_stack_preferences.md`.
+7. **ZERO JT service CTAs.** Course is a pure lead magnet (Option C positioning, adopted 2026-05-12). No "book a Control Audit," no "schedule a consultation," no service offers. Authorship credit stays at the footer; that's signing the work, not selling. Memory: `feedback_curriculum_is_pure_lead_magnet.md`.
+8. **Every post engineered for viral sharing** on Reddit/Twitter/Facebook. Mandatory elements: (a) contrarian hook in opening 80 words, (b) one quote-tweetable insight 140-280 chars, (c) a specific tactic the reader can execute this week, (d) a free downloadable artifact, (e) a shareable headline structure. Memory: `feedback_curriculum_viral_shareability.md`.
+
+---
+
+## 26 posts in course order
+
+### Module 0 - Where Are You? *(1 post)*
+
+| Step | Slug | Status | Notes |
+|---|---|---|---|
+| 0.1 | `course-map-self-assessment-non-technical-founder-2026` | 🆕 net-new | Self-Assessment Worksheet artifact; 10 questions output the reader's entry module |
+
+### Module 1 - Validate the Problem *(3 posts)*
+
+| Step | Slug | Status | Notes |
+|---|---|---|---|
+| 1.1 | `find-10-people-with-problem-outreach-2026` | 🆕 net-new | Reddit/LinkedIn/Discord mining + Clay or Apollo + Lindy AI + paid panels + smoke-test landing page |
+| 1.2 | `mom-test-ask-about-past-not-future` | 🆕 net-new | Rob Fitzpatrick's 5-question script + interview transcript template |
+| 1.3 | `validated-problem-statement-decide-whats-next` | 🆕 net-new | One-page problem statement + "3 pre-orders = green light" rule |
+
+### Module 2 - Design the Solution *(3 posts)*
+
+| Step | Slug | Status | Notes |
+|---|---|---|---|
+| 2.1 | `five-tech-words-stop-nodding-at` | ✅ drafted | Existing post; nav table swaps from "Foundation pillar · post 1 of 14" to "Module 2 · Step 1 of 3" |
+| 2.2 | `one-page-product-brief-vibe-prd-template` | 🆕 net-new | The simplest brief format: who/what problem/current workaround/what you'll build/what you won't/how you'll know it worked |
+| 2.3 | `stop-specifying-features-start-outcomes` | 🆕 net-new | Title: "Stop Specifying Features. Start Specifying Outcomes." Teaches the job-story format as a TACTIC inside the post; never names "Job Stories" as a framework on main path. References 5.6 spaceship admin panel as cautionary tale. Renamed 2026-05-12 per KISS doctrine. |
+
+### Module 3 - Choose Your Build Path *(2 posts)*
+
+| Step | Slug | Status | Notes |
+|---|---|---|---|
+| 3.1 | `should-you-hire-2026-decision-tree` | 🆕 net-new | Airbnb test (validate without code) + Rob Walling shed warning + when DIY is enough |
+| 3.2 | `fractional-cto-bridge-5-hours-beats-cofounder` | 🆕 net-new | $0-equity alternative to 50%-equity technical cofounder |
+
+### Module 4A - Ship Self-Serve *(branch, 2 posts)*
+
+| Step | Slug | Status | Notes |
+|---|---|---|---|
+| 4A.1 | `self-serve-mvp-stack-lovable-supabase-stripe-2026` | 🆕 net-new | What each tool does in plain English + how they connect + Lovable Discord community reference |
+| 4A.2 | `vibe-coding-ceiling-signals-when-ai-builds-break` | 🆕 net-new | 5 ceiling signals; triggers route to 4B |
+
+### Module 4B - Hire & Ship *(branch, 4 posts)*
+
+| Step | Slug | Status | Notes |
+|---|---|---|---|
+| 4B.1 | `who-where-hire-developer-2026-ai-augmented-offshore` | 🆕 net-new | AI-Augmented Developer profile + onshore/nearshore/Tier-2 offshore map |
+| 4B.2 | `hiring-interview-catches-ai-theater-7-questions` | 🆕 net-new | 7-question script extending existing AI 5-question lead magnet |
+| 4B.3 | `cheap-developers-expensive-without-cto-review` | 🔁 wrap | 2510 NEW-L; LinkedIn validation 2026-05-24 |
+| 4B.4 | `reading-sow-clause-by-clause` | ✅ drafted | Existing post; nav table swap |
+
+### Module 5 - Manage Your Build *(6 posts)*
+
+| Step | Slug | Status | Notes |
+|---|---|---|---|
+| 5.1 | `engineering-org-chart-non-technical-founder` | ✅ drafted | Existing; nav swap |
+| 5.2 | `friday-demo-rule-founder-progress` | 🔁 wrap | 2510 NEW-J; LinkedIn 2026-05-13 |
+| 5.3 | `three-questions-turn-standup-into-proof` | ✅ drafted | Existing; nav swap |
+| 5.4 | `weekly-dev-report-template-founders` | 🔁 wrap | 2510 NEW-A |
+| 5.5 | `github-aws-database-ownership-checklist` | 🔁 wrap | 2510 NEW-K; LinkedIn 2026-05-17 |
+| 5.6 | `asked-simple-admin-panel-built-spaceship` | 🔁 wrap | 2510 NEW-I; LinkedIn 2026-05-20 |
+
+### Module 6 - When Things Break *(2 posts)*
+
+| Step | Slug | Status | Notes |
+|---|---|---|---|
+| 6.1 | `salvage-vs-rebuild-software-project` | 🔁 wrap | 2510 NEW-M; LinkedIn 2026-05-27 |
+| 6.2 | `switch-dev-shops-safely-transition-guide` | 🔁 wrap | 2510 NEW-C |
+
+### Module 7 - Manage AI-Era Risks *(3 posts)*
+
+| Step | Slug | Status | Notes |
+|---|---|---|---|
+| 7.1 | `agency-uses-ai-follow-up-questions` | 🔁 wrap | 2510 NEW-E; dual-purpose with 4B.2 |
+| 7.2 | `ai-token-bill-dev-shop-pass-through-cost` | 🔁 wrap | 2510 NEW-D2 |
+| 7.3 | `slopsquatting-ai-supply-chain-attack` | 🔁 wrap | 2510 #20 |
+
+**Totals**: 26 posts · 12 net-new · 4 drafted · 10 wraps
+
+---
+
+## Required course-frame in every post (mandatory)
+
+### Top callout (immediately after frontmatter)
+
+```
+> **Module X · Step N of M** · [Tech for Non-Technical Founders 2026](/blog/tech-for-non-technical-founders-2026/) free course.
+> Input: [what reader brings]. Output: [deliverable].
+```
+
+Example for `five-tech-words-stop-nodding-at` (Module 2 · Step 1 of 3):
+```
+> **Module 2 · Step 1 of 3** · [Tech for Non-Technical Founders 2026](/blog/tech-for-non-technical-founders-2026/) free course.
+> Input: validated problem from Module 1. Output: one-page Product Brief (Vibe PRD).
+```
+
+### Bottom course-nav section (last H2 before "Further reading")
+
+```markdown
+## Continue the course
+
+This is Step N of Module X in the free **[Tech for Non-Technical Founders 2026](/blog/tech-for-non-technical-founders-2026/)** course.
+
+| # | Module | Output you walk away with |
+|---|---|---|
+| 0 | Where Are You? | Self-assessment + your starting module |
+| 1 | Validate the Problem | One-page validated problem |
+| 2 | Design the Solution | One-page Product Brief (Vibe PRD) |
+| 3 | Choose Your Build Path | Build decision (self-serve or hire) |
+| 4A | Ship Self-Serve | Live MVP at staging URL |
+| 4B | Hire & Ship | Signed SOW, kickoff scheduled |
+| 5 | Manage Your Build | Weekly oversight rhythm |
+| 6 | When Things Break | Salvage / rebuild decision |
+| 7 | Manage AI-Era Risks | AI interrogation system |
+
+**In Module X**: [list this module's posts; current post marked `← you are here`].
+
+The full course landing page (with all artifacts) publishes after Module 5 ships. Until then, bookmark this post.
+```
+
+The 9-row table shows the full course arc. The `In Module X` line keeps the current chapter visible without bloating the nav.
+
+---
+
+## Advanced sidebar format *(for Modules 1, 2, 5 only)*
+
+A single callout near the bottom of each module's last post (or any post within the module that names a framework). Standard wording:
+
+```
+> **Going further (optional, for teams with capacity)**
+> Once you have a co-founder, a Fractional CTO, or a junior product hire, these structured workshops scale what this module covered:
+> - **[Framework name]** ([author / book]) - one-line summary
+> - **[Framework name]** ([author / book]) - one-line summary
+>
+> Free to read. None are required to ship your first product. The simple path in this module is enough.
+```
+
+**Module 1 sidebar**: Empathy Mapping (Dave Gray, XPLANE) · JTBD Canvas 2 (Jim Kalbach, 2023) · Customer Journey · Continuous Discovery (Teresa Torres, *Continuous Discovery Habits*) + Opportunity Solution Tree.
+
+**Module 2 sidebar**: Impact Mapping (Gojko Adzic) · Foundation Sprint (Knapp/Zeratsky, *Click*, April 2025) · Design Sprint (Knapp 2016) · Lean Inception (Paulo Caroli) · User Story Mapping (Jeff Patton).
+
+**Module 5 sidebar**: Shape Up (Basecamp / Ryan Singer) · Continuous Discovery during build (Teresa Torres) · User Story Mapping for release planning (Jeff Patton).
+
+---
+
+## Lead-magnet artifacts (11 total)
+
+| # | Artifact | Module | Status |
+|---|---|---|---|
+| 1 | Self-Assessment Worksheet | 0 | 🆕 net-new |
+| 2 | Module 1 Toolkit (Outreach Sequence + Mom Test Script + Validated Problem Statement) | 1 | 🆕 net-new |
+| 3 | Vibe PRD Template (Product Brief) | 2 | 🆕 net-new |
+| 4 | Build Path Decision Worksheet | 3 | 🆕 net-new |
+| 5 | Self-Serve Stack Walkthrough PDF | 4A | 🆕 net-new |
+| 6 | Hiring Kit (Where-to-Hire Map + Hiring Interview Script + SOW Reading Guide) | 4B | partial: SOW Reading Guide ✅; others 🆕 net-new |
+| 7 | Friday Demo Template | 5 | ✅ drafted |
+| 8 | Ownership Checklist | 5 | ✅ drafted |
+| 9 | Weekly Report Template | 5 | 🆕 net-new (referenced in NEW-A but template not yet shipped) |
+| 10 | Salvage vs Rebuild Decision Tree | 6 | ✅ drafted |
+| 11 | AI 5-Question Script + AI Cost Worksheet | 7 | partial: 5-Question Script ✅; Cost Worksheet 🆕 net-new |
+
+**Existing**: 5 (Friday Demo Template, Ownership Checklist, Salvage Decision Tree, AI 5-Question Script, SOW Reading Guide).
+**Net-new**: 6-7 (Self-Assessment, Module 1 Toolkit, Vibe PRD, Build Path Worksheet, Self-Serve Stack PDF, Where-to-Hire Map + Hiring Interview Script, AI Cost Worksheet, Weekly Report Template).
+
+---
+
+## Publish calendar (proposed)
+
+The 10 wrap posts ship per the existing 2510 LinkedIn validation sprint (May 13 - June 17, 2026). The 4 drafted posts (Five Tech Words, Org Chart, SOW Reading, Standup Questions) need cover images + multi-persona review before publishing - target Q3 2026.
+
+The 12 net-new posts (Modules 0-3 + Module 4A + Module 4B net-new) ship at ~2/week starting 2026-07-01, ahead of the curriculum landing page in Q4.
+
+| Window | What ships | Notes |
+|---|---|---|
+| 2026-05-13 → 2026-06-17 | 10 wrap posts via 2510 schedule | Curriculum frame added retroactively when each ships |
+| 2026-07-01 → 2026-08-15 | 4 drafted posts + 8 of 12 net-new | ~2/week cadence; Modules 0-4A complete |
+| 2026-08-15 → 2026-09-15 | Remaining 4 net-new (Module 4B + final Module 1-3 polish) | Module 4B kit shipping (Where-to-Hire Map + Hiring Interview Script + Hiring Kit lead magnet) |
+| 2026-09-30 | Curriculum landing page live at `/blog/tech-for-non-technical-founders-2026/` | After Module 5 wraps publish |
+| 2026-10 onwards | Quarterly refresh on Module 7 (AI-era posts decay fast) | Q1 2027 first refresh |
+
+---
+
+## Distinctness audit *(per `feedback_cross_post_signal_repetition.md`)*
+
+Each post leads with a distinct proof signal / anecdote. No two posts share the same dollar anchor or technical mechanic:
+
+| Step | Lead signal / anecdote |
+|---|---|
+| 1.1 | Outreach math: 10 interviews booked in 1 week via Clay + Lindy |
+| 1.2 | Mom Test: "tell me about the last time you did X" |
+| 1.3 | "3 pre-orders = green light" rule |
+| 2.1 | "Refactoring cost her $51K and a year of runway" (existing) |
+| 2.2 | One-page Vibe PRD that saved 4 weeks of scope creep |
+| 2.3 | $9K "checkout refactor" = single 3,800-line merge (referenced from existing post 2.1) |
+| 3.1 | Airbnb test - validate without code |
+| 3.2 | $400/week Fractional CTO beats 50% equity |
+| 4A.1 | Founder shipped Stripe checkout in 6 weeks on Lovable + Supabase |
+| 4A.2 | 5 architectural ceiling signals before total rewrite |
+| 4B.1 | $44K/month "team of 4" (existing 5.1 anecdote referenced from hiring angle) |
+| 4B.2 | $34K AI agency rescue (existing 7.1 anecdote referenced from hiring angle) |
+| 4B.3 | Student over-engineering trap (wrap NEW-L) |
+| 4B.4 | $78K milestone-acceptance failure (existing 4B.4 / SOW post) |
+| 5.1-5.6 | Existing post anecdotes (Org chart $44K, Friday demo $62K, Standup $25K/47 standups, etc.) |
+| 6.1 | $95K marketplace, 38K LOC, 0% test coverage |
+| 6.2 | "Investor legend" trick for repo transfer |
+| 7.1 | $34K AI agency with secrets in `database.yml` (existing AI 5-questions anecdote) |
+| 7.2 | $4,800 OpenAI bill nobody could explain |
+| 7.3 | Slopsquatting npm/Rubygems/PyPI hallucinated packages |
+
+---
+
+## Out of scope (explicit)
+
+- We do **not** write a "how to learn to code" curriculum.
+- We do **not** issue certificates, host cohorts, or charge for the course.
+- We do **not** refresh the course mid-quarter except for Module 7 (AI-era posts) which carry "last reviewed" stamps.
+- We do **not** include frameworks (Foundation Sprint, JTBD Canvas, Shape Up, etc.) on the main reading path - they live in Advanced sidebars only.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/_ARCHIVED_20.08-spine-2-audit-8-module.md b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/_ARCHIVED_20.08-spine-2-audit-8-module.md
new file mode 100644
index 000000000..6675cc332
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/_ARCHIVED_20.08-spine-2-audit-8-module.md
@@ -0,0 +1,175 @@
+# Spine-2 Audit and Chapter Mapping
+**Project**: 2605-tech-for-non-technical-founders
+**Phase**: 2 — Restructure audit
+**Date**: 2026-05-15
+**Branch**: module-8-first-paying-customer
+**Truth source**: `data/course_sequence.yaml` (34 entries, 9 modules numbered 0-9)
+**Target spine**: 8 modules (0-7) approved by user 2026-05-15
+
+---
+
+## Task A — Chapter Mapping Table
+
+All 34 entries from `data/course_sequence.yaml` classified against the approved 8-module spine.
+
+| Slug | Old module | NEW module (or disposition) | Action | Reframing notes |
+|---|---|---|---|---|
+| `course-map-self-assessment-non-technical-founder-2026` | Module 0 | Module 0 | **REFRAME** | Routing logic must map to 8 modules (0-7) instead of the old 10-module tree; the 12-Q self-assessment needs re-numbered routing table. |
+| `form-your-founding-hypothesis-90-minute-sprint` | Module 1.1 | Module 1 | **KEEP** | Fits as-is; one-sentence falsifiable hypothesis with price is the module output. |
+| `smoke-test-landing-page-300-dollar-validation` | Module 2.1 | Module 2 | **REFRAME** | Add price hypothesis section: the smoke-test page must carry a Stripe price button, not just a waitlist. Gate changes from "300 visits" to "≥5% click-to-payment-intent." |
+| `find-10-people-with-problem-outreach-2026` | Module 3.1 | Module 3 | **KEEP** | Outreach method fits Module 3 entry; no structural change needed. |
+| `mom-test-ask-about-past-not-future` | Module 3.2 | Module 3 | **KEEP** | Core interview methodology; fits as-is. |
+| `validated-problem-statement-decide-whats-next` | Module 3.3 | Module 3 | **FOLD** | Content overlaps heavily with `mom-test-ask-about-past-not-future`; merge the "decide what's next" decision logic as a closing section of the Mom Test chapter so Module 3 ends with a single decision gate. |
+| `market-type-existing-resegmented-new` | Module 3.4 | Appendix / OPEN QUESTION | **DEMOTE** | Too academic for greenfield-newbie ICP; surfaces as open question D-1 below. |
+| `one-page-product-brief-vibe-prd` | Module 4.1 | Module 4 | **KEEP** | Direct output of Module 4; no change needed. |
+| `stop-specifying-features-start-outcomes` | Module 4.2 | Module 4 | **KEEP** | Prevents over-engineering before build; fits Module 4 as the "what you won't build" discipline. |
+| `should-you-hire-2026-decision-tree` | Module 5 | Module 5 | **REFRAME** | Currently a parallel-branch decision; reframe as a ceiling-signal-triggered decision — self-serve is the DEFAULT path; hire only if solo vibe-coding can't cover the Product Brief scope. |
+| `github-aws-db-ownership-checklist` | Module 6.1 | Module 5 | **REFRAME** | Ownership audit is a Day-1 prerequisite for BOTH build paths, not mid-build oversight; move under Module 5 as the mandatory pre-build checklist before the founder picks a tool or signs a contract. |
+| `engineering-org-chart-non-technical-founder` | Module 6.2 | Module 7 ref sidebar | **DEMOTE** | Premature-management content; relevant after retention is measured. |
+| `friday-demo-rule-founder-progress` | Module 6.3 | Module 7 ref appendix | **DEMOTE** | Oversight rhythm is post-ship management; demote to Module 7 "if retention is solid and you need to scale" reference. |
+| `three-questions-turn-standup-into-proof` | Module 6.4 | Module 7 ref appendix | **DEMOTE** | Same as above — oversight management, post-retention context. |
+| `weekly-dev-report-template-founders` | Module 6.5 | Module 7 ref appendix | **DEMOTE** | Same as above. |
+| `asked-simple-admin-panel-built-spaceship` | Module 6.6 | CUT | **CUT** | Rescue framing; no greenfield-friendly rehoming possible. |
+| `self-serve-mvp-stack-lovable-supabase-stripe-2026` | Module 6A.1 | Module 5 | **REFRAME** | Currently positioned as "one of two build paths"; reframe as the DEFAULT path for all Module 5 entrants. Hire path becomes a conditional branch, not a parallel co-equal path. |
+| `vibe-coding-ceiling-signals` | Module 6A.2 | Module 5 | **REFRAME** | Remove rescue framing; reframe as proactive ceiling-signal monitoring the founder runs monthly — five signals to watch so they know when self-serve has outgrown its envelope before a crisis. |
+| `who-where-hire-developer-2026-ai-augmented-offshore` | Module 6B.1 | Module 7 ref sidebar | **DEMOTE** | Hire-a-team detail; relevant only after retention is proven and founder decides to scale. |
+| `fractional-cto-bridge-5-hours-week` | Module 6B.2 | Module 7 ref sidebar | **DEMOTE** | Same hire-track context. |
+| `hiring-interview-catches-ai-theater` | Module 6B.3 | Module 7 ref sidebar | **DEMOTE** | Same. |
+| `cheap-developers-expensive-without-cto-review` | Module 6B.4 | CUT | **CUT** | Rescue framing; no greenfield rehoming. |
+| `reading-sow-clause-by-clause` | Module 6B.5 | Module 7 ref sidebar | **DEMOTE** | Hire-track SOW detail; post-retention context. |
+| *(missing slug — yaml parse gap)* | Module 7.1 | Module 6 | **KEEP** | "First customer is not marketing" — fits Module 6 entry; channel-selection chapter is the new add that leads it. |
+| `first-ten-customers-personal-network` | Module 7.2 | Module 6 | **KEEP** | Network-first outreach fits Module 6 as-is. |
+| `paid-pilot-charge-before-ship` | Module 7.3 | Module 6 | **KEEP** | Core Module 6 mechanic; charge before ship is the gate. |
+| `outbound-without-sales-team` | Module 7.4 | Module 6 | **KEEP** | Post-channel-selection outbound; fits after new "channel selection" chapter. |
+| `customers-leaving-churn-triage-not-acquisition` | Module 7.5 | Module 7 | **KEEP** | Directly maps to Module 7 retention gate (measure churn, resolve top exit reason). |
+| `pivot-or-persevere-decision-framework` | Module 7.6 | Module 7 | **KEEP** | Post-retention decision; fits Module 7 as the "what if ≥60% / ≥80% isn't hit?" escalation. |
+| `salvage-vs-rebuild-software-project` | Module 8.1 | CUT | **CUT** | Rescue framing; no greenfield rehoming. |
+| `switch-dev-shops-safely-transition-guide` | Module 8.2 | CUT | **CUT** | Rescue framing; no greenfield rehoming. |
+| `agency-uses-ai-follow-up-questions` | Module 9.1 | Appendix | **DEMOTE** | AI-era hygiene; post-ship reference appendix. |
+| `ai-token-bill-dev-shop-pass-through-cost` | Module 9.2 | Appendix | **DEMOTE** | Same. |
+| `slopsquatting-ai-supply-chain-attack` | Module 9.3 | Appendix | **DEMOTE** | Same. |
+
+**Note on missing slug**: the yaml file has a parse gap at the Module 7.1 entry (title/mod keys present but slug key is absent). Verify raw file before Phase 3 begins.
+
+---
+
+## Task B — Briefs for the 4 New Chapters
+
+### NEW: Price Your Hypothesis on the Smoke-Test Page
+- **Slug proposal:** `price-hypothesis-smoke-test-stripe`
+- **Module:** 2
+- **Outcome:** Founder publishes a smoke-test landing page with a real Stripe price button (not a waitlist), collects click-to-payment-intent data, and has a go/iterate/kill threshold.
+- **Signal/gate:** ≥5% of cold-traffic visitors click the Stripe payment-intent button within 72 hours of the page going live.
+- **Required content:**
+  - Why waitlists lie and a price button reveals real intent
+  - How to pick a price point before you have a product (anchor to the closest existing alternative)
+  - Step-by-step: Carrd/Framer page + Stripe payment link in under 2 hours
+  - What to do when someone actually pays (refund script + follow-up call request)
+  - Interpreting results: <1% = kill, 1-4% = iterate hypothesis, ≥5% = validated
+  - Common error: price too high vs. copy unclear vs. audience wrong — how to tell which
+- **AI-augmented method:** Use Claude / ChatGPT to generate 5 price-point framings from the one-sentence hypothesis, then A/B test top 2 as page variants.
+- **Length:** 1,200-1,500 words
+- **Templates/artifacts:** Smoke-Test Page Brief (copy template for headline, sub, CTA, price anchor, objection line) + Stripe Payment Link Setup Checklist
+
+---
+
+### NEW: AI Persona Pre-Validation
+- **Slug proposal:** `ai-persona-pre-validation-before-mom-test`
+- **Module:** 3
+- **Outcome:** Founder runs a structured AI-persona session before booking real interviews, surfaces the 3 most likely objections, and enters Mom Test calls prepared to test - not discover - those objections.
+- **Signal/gate:** Founder writes down 3 predicted objections before the first call; post-interviews they check which ones appeared verbatim.
+- **Required content:**
+  - Why interviewing AI before humans saves your first 3 interviews from fishing-expedition mistakes
+  - The 5-prompt sequence: persona setup → job-to-be-done probe → objection surfacing → price sensitivity probe → status-quo defense
+  - How to read AI output critically (AI agrees too easily; treat every "yes" as a hypothesis to stress-test)
+  - Feeding AI insights back into your outreach copy and Mom Test script
+  - What this does NOT replace: the 10 real human conversations are still mandatory
+- **AI-augmented method:** Claude prompt sequence — system prompt sets persona as exact ICP description from the Product Brief; five structured interview turns; output is a list of predicted objections ranked by confidence.
+- **Length:** 900-1,200 words
+- **Templates/artifacts:** AI Pre-Validation Prompt Pack (5 copy-pasteable prompts + instructions for reading output) + Objection Tracker Worksheet
+
+---
+
+### NEW: Build a Clickable Prototype in an Afternoon
+- **Slug proposal:** `clickable-prototype-lovable-afternoon-validation`
+- **Module:** 3
+- **Outcome:** Founder has a clickable prototype (not wireframes, not a deck) built in Lovable in under 4 hours and shows it to 5 of the 10 Mom Test interviewees to validate flow, not just problem.
+- **Signal/gate:** ≥3 of 5 interview subjects can navigate the prototype's core flow without prompting AND articulate the problem the prototype solves unprompted.
+- **Required content:**
+  - The difference between a prototype and an MVP (prototype answers "can they use it?" not "does it work?")
+  - What to build in Lovable in one afternoon: 3 screens maximum, the core user action only
+  - How to run a prototype walkthrough (silent observation, note where they hesitate, ask "what did you expect?" not "was that clear?")
+  - What a "pass" looks like vs. a "pivot the design" result
+  - How prototype feedback shapes the Product Brief before Module 4
+  - Common trap: over-building the prototype (perfectionism kills the learning signal)
+- **AI-augmented method:** Paste the Product Brief into Lovable with the prompt "Build me a 3-screen prototype for [ICP] doing [job]"; use Lovable's AI to generate screens; founder navigates and edits, not codes.
+- **Length:** 1,000-1,400 words
+- **Templates/artifacts:** Prototype Session Script (observer checklist + 5 debrief questions + pass/fail scoring rubric) + Lovable Prompt Template
+
+---
+
+### NEW: Choose Your Channel Before You Send One Message
+- **Slug proposal:** `channel-selection-first-paying-customer-2026`
+- **Module:** 6
+- **Outcome:** Founder picks ONE acquisition channel for the first paying customer based on where the 10 Mom Test interviewees already gather, commits to it for 4 weeks before evaluating a second.
+- **Signal/gate:** Founder can name the channel, explain why (evidence from interviews), and has a 4-week outreach plan written down before sending any message.
+- **Required content:**
+  - Why channel-first prevents shotgun outreach and wasted time
+  - The 5 greenfield-founder channels: personal network, niche communities (Reddit/Slack/Discord), cold email, content (post where ICP reads), paid (last resort)
+  - How to read your interview notes for channel signal (where did they say they find tools? who do they trust for recommendations?)
+  - The 4-week commitment rule: one channel, one message format, consistent daily action — no pivoting until week 4 data is in
+  - How to define "working": a paying-customer conversion rate threshold per channel type
+  - The channel-market fit trap: great product, wrong channel
+- **AI-augmented method:** Feed the 10 interview transcripts to Claude with the prompt "Identify the 3 most common channels these people use to discover new tools. Quote the exact line from each transcript."
+- **Length:** 1,000-1,300 words
+- **Templates/artifacts:** Channel Selection Worksheet (5-channel scorecard with interview-evidence columns + 4-week outreach plan template)
+
+---
+
+## Task C — Reframing Notes for Chapters Needing Significant Editing
+
+**`should-you-hire-2026-decision-tree`** — Currently frames self-serve and hire as two co-equal parallel paths the founder weighs from the start. Reframe as: self-serve (Lovable + Supabase + Stripe) is the DEFAULT; hire is a conditional branch triggered only when the ceiling-signal chapter (`vibe-coding-ceiling-signals`) produces a positive signal OR when the Product Brief scope is objectively beyond a solo AI-assisted build. The decision tree logic stays but the opening framing changes from "which path?" to "you're starting on the self-serve path — here's when to exit it."
+
+**`self-serve-mvp-stack-lovable-supabase-stripe-2026`** — Currently positioned as one of two equal build paths ("6A" vs "6B"). Reframe as the default Module 5 chapter every reader enters first, regardless of their eventual build decision, because understanding the self-serve stack calibrates the hire-vs-build cost comparison. The "if you chose hire" fork becomes a sidebar at the end, not a co-equal opening.
+
+**`vibe-coding-ceiling-signals`** — Currently framed with rescue language ("when your AI build breaks"). Remove rescue framing entirely; reframe as a monthly monitoring habit the founder runs starting at Week 2 of building, not a post-crisis diagnostic. The five signals become leading indicators to watch, not symptoms to recognize after the damage is done.
+
+**`course-map-self-assessment-non-technical-founder-2026`** — Currently routes to the old 10-module structure (Modules 0-9 with 6A/6B branch). The routing table needs to be rebuilt for the 8-module spine (0-7) with the Module 5 self-serve/hire branch shown as a within-module decision, not a module split. The 12-Q self-assessment questions also need re-indexing to match the new module numbers.
+
+**`tech-for-non-technical-founders-2026`** (landing page) — Full restructure required from the new 8-module spine; flag for a separate task. The current landing likely lists the old module order, the old chapter count, and possibly the old positioning sentence. Do not touch in Phase 3 until all chapter rewrites are staged.
+
+---
+
+## Task D — Open Questions for the User
+
+**D-1. Does `market-type-existing-resegmented-new` survive?**
+This chapter (Module 3.4 in old structure) teaches existing / re-segmented / new-market framing from Steve Blank. It is theoretical and has no artifact. For a greenfield-newbie ICP it is likely too academic and may increase drop-off between the Mom Test and the Product Brief.
+*Recommendation: cut or demote to a reference appendix. Flag it as "advanced reading for founders who want to understand why their competitive positioning feels off."*
+
+**D-2. Should `validated-problem-statement-decide-whats-next` fold into `mom-test-ask-about-past-not-future`?**
+Both live in Module 3. The "decide what's next" chapter is essentially the debriefing and synthesis step after the Mom Test. Keeping them separate adds a chapter click with little standalone value; folding creates a cleaner Module 3 that has: (1) find 10 people, (2) run the interviews + synthesize the decision.
+*Recommendation: fold — merge the synthesis and go/iterate/kill decision logic as a 400-word closing section of the Mom Test chapter.*
+
+**D-3. Where does `five-tech-words-stop-nodding-at` live in the new 8-module structure?**
+The yaml marks it as out-of-linear-reading-order (course glossary). The approved spine has no explicit glossary slot. It could sit as a floating reference page linked from the course nav, or it could anchor Module 4 (Product Brief) as "vocabulary you need before you write the brief."
+*Recommendation: keep it as a standalone reference linked from the course-nav table in every post. No module assignment. Accessible from anywhere but not in the linear path.*
+
+**D-4. Are the Module 7 ref sidebar chapters (hire track) usable as standalone blog posts or only as reference?**
+`who-where-hire-developer-2026-ai-augmented-offshore`, `fractional-cto-bridge-5-hours-week`, `hiring-interview-catches-ai-theater`, `reading-sow-clause-by-clause` are demoted to a Module 7 reference sidebar per the approved cuts. The question is whether they remain fully-written chapter pages (with course nav) or are collapsed into a single "If You're Scaling: Hire Track" reference page.
+*Recommendation: keep as individual pages (they have SEO value and may rank for hire-related queries); strip the course-nav table and replace with a single "This is supplementary material — return to Module 7 when you're ready to scale" callout.*
+
+**D-5. Does `pivot-or-persevere-decision-framework` belong in Module 7 or should it anchor a Module 8?**
+The approved spine ends at Module 7 (Retain Before You Scale). The pivot-or-persevere framework is currently Module 7.6 but logically it triggers when retention targets are NOT met — making it a post-Module-7 decision. If the course is meant to end at Module 7, it fits as the Module 7 closing chapter. If the user wants a Module 8 for "what if nothing works," this is its anchor.
+*Recommendation: keep in Module 7 as the closing chapter — "if you hit ≥60%/≥80% retention, you graduate; if not, here's the pivot-or-persevere gate." No Module 8 needed; keeps the spine clean at 8 modules.*
+
+---
+
+## Surprises / Anomalies Found
+
+**Slug gap in yaml**: The yaml entry at Module 7.1 position is missing its `slug:` key entirely (title and mod are present). The chapter "Your First Customer Is Not Marketing" exists as a chapter in the strategy docs but cannot be served by Hugo without a slug. Requires a fix before Phase 3 build.
+
+**`github-aws-db-ownership-checklist` is misclassified**: In the old structure it was Module 6.1 (mid-build oversight). The approved cuts demote `engineering-org-chart`, `friday-demo-rule`, `three-questions`, and `weekly-dev-report` to appendix — but ownership is fundamentally different (it's a Day-1 setup task, not management). This chapter should NOT be demoted to the same appendix as the management posts; it belongs in Module 5 as a mandatory pre-build gate. If it lands in the management appendix by accident, greenfield founders will never read it.
+
+**Module 6A/6B split creates navigation confusion**: The old YAML has `6A.1`, `6A.2`, `6B.1`…`6B.5` as sibling entries in a flat list. In the new 8-module spine, these become either Module 5 chapters or Module 7 sidebar entries. The YAML will need renumbering (Phase 3 task) — but note that the branching logic currently visible to the reader in the course-nav table will disappear, which may disorient readers who arrived from Google on a 6A or 6B URL. Redirects needed.
+
+**`customers-leaving-churn-triage-not-acquisition`** is currently Module 7.5 (old), which was the "First Paying Customer" module. In the new spine it maps cleanly to Module 7 (Retain Before You Scale) — but its title still implies the founder already has customers leaving, which presupposes a flow problem that new Module 7 readers haven't yet experienced. The title may need softening for greenfield ICP before it goes live.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.01-adr-course-url-migration.md b/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.01-adr-course-url-migration.md
new file mode 100644
index 000000000..674bba498
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.01-adr-course-url-migration.md
@@ -0,0 +1,397 @@
+# ADR: Migrate Course Content to `/course/` URL Path
+
+**ADR-ID:** 2026-07-01-001  
+**Date:** 2026-07-01  
+**Status:** Proposed  
+**Author:** JetThoughts Course Team  
+
+---
+
+## Title
+
+Migrate course content from `/blog/:slug/` to `/course/:slug/` with multi-course architecture support.
+
+---
+
+## Status
+
+Proposed
+
+---
+
+## Context
+
+### Current State
+
+43 course chapters of the "Tech for Non-Technical Founders 2026" curriculum are stored as blog posts in `content/blog/`, identified via `course_chapter: true` frontmatter. They share the `/blog/:slug/` URL namespace with 598 regular blog posts.
+
+| Metric | Value |
+|--------|-------|
+| Total blog posts in `content/blog/` | 641 |
+| Course chapters (marked `course_chapter: true`) | 43 |
+| Course chapters NOT in blog directory | 0 |
+| Internal `/blog/course-*` links in content | ~382 |
+| Separate course listing/layout templates | 0 |
+| URL path | `/blog/:slug/` for all |
+
+### Problems
+
+1. **Mixed namespace** — Course chapters and blog posts share `/blog/` URLs, preventing course-specific URL patterns, breadcrumbs, and schema markup.
+2. **Template ambiguity** — No `blog/single.html` exists; course chapters render through general Hugo fallthrough. A course chapter needs different layout, navigation, and structured data than a blog post.
+3. **No multi-course support** — The current architecture cannot host a second course without further mixing into `/blog/` or requiring another migration.
+4. **Editor UX** — 43 course files buried among 598 blog files make content management harder than necessary.
+5. **SEO granularity** — Google treats `/blog/` as a single content vertical. Separating courses onto `/course/` allows independent sitemap priority, crawl budget targeting, and course-specific rich results (Course, CourseInstance schema).
+
+### Decision Drivers
+
+| Driver | Weight | Description |
+|--------|--------|-------------|
+| Clean URL scheme | High | Course content should live at `/course/`, not `/blog/` |
+| Multi-course future | High | Architecture must support N courses without repeated migration |
+| SEO preservation | High | Existing indexed URLs must 301 redirect to new paths |
+| Editorial simplicity | High | Course editors should work in a `content/course/` directory |
+| Template isolation | Medium | Course chapters need different layouts than blog posts |
+| Developer clarity | Medium | Content type boundaries should be obvious from file structure |
+
+---
+
+## Decision
+
+**Migrate course content from `content/blog/` to `content/course/` with URL path `/course/:slug/`.**
+
+Do NOT maintain the old `/blog/:slug/` URLs as canonical. Serve 301 redirects for the old paths for 90 days, then retire them.
+
+### What Changes
+
+```
+BEFORE:                          AFTER:
+/content/blog/                   /content/blog/           ← 598 blog posts only
+  ├── form-your-founding.../       ├── (all regular posts stay)
+  ├── smoke-test-landing.../      /content/course/        ← NEW: course content
+  ├── price-hypothesis.../          ├── tech-for-non-technical-founders-2026/
+  ├── ...                          │   └── index.md        ← course landing page (moved)
+  └── tech-for-non-technical.../   ├── form-your-founding-hypothesis-90-minute-sprint/
+                                   │   └── index.md
+                                   ├── smoke-test-landing-page-300-dollar-validation/
+                                   │   └── index.md
+                                   └── ... (41 more chapters)
+```
+
+**URL examples:**
+
+| Page | Old URL | New URL | Redirect |
+|------|---------|---------|----------|
+| Founding Hypothesis | `/blog/form-your-founding-hypothesis-90-minute-sprint/` | `/course/form-your-founding-hypothesis-90-minute-sprint/` | 301 |
+| Smoke Test | `/blog/smoke-test-landing-page-300-dollar-validation/` | `/course/smoke-test-landing-page-300-dollar-validation/` | 301 |
+| Course Landing | `/blog/tech-for-non-technical-founders-2026/` | `/course/tech-for-non-technical-founders-2026/` | 301 |
+| Regular blog post | `/blog/ruby-on-rails-performance-patterns-2026/` | (unchanged) | — |
+
+### Hugo Configuration
+
+**1. Section permalink** — `config/_default/hugo.toml`:
+
+```toml
+[permalinks]
+  blog = "/blog/:slug/"
+  course = "/course/:slug/"     # ← NEW: course section pattern
+```
+
+**2. Content mount** (if `content/course/` needs mapping):
+
+```toml
+[[module.mounts]]
+  source = "content/course"
+  target = "content/course"
+```
+
+(The mount is default behavior for Hugo sections; explicit mount config is only needed if the source/target paths differ.)
+
+**3. 301 redirects** — `config/_default/hugo.toml` (one per course chapter + landing page):
+
+```toml
+# Course chapter redirects: /blog/slug/ → /course/slug/
+# 43 entries total. Retain for 90 days post-migration.
+[[redirects]]
+  from = "/blog/form-your-founding-hypothesis-90-minute-sprint/"
+  to = "/course/form-your-founding-hypothesis-90-minute-sprint/"
+  status = 301
+
+[[redirects]]
+  from = "/blog/smoke-test-landing-page-300-dollar-validation/"
+  to = "/course/smoke-test-landing-page-300-dollar-validation/"
+  status = 301
+
+# ... (41 more entries)
+```
+
+**4. Template selection** — Hugo's built-in section template lookup:
+
+| Template path | Renders | Purpose |
+|---------------|---------|---------|
+| `layouts/course/single.html` | Course chapter pages | Chapter layout, course nav, schema |
+| `layouts/course/list.html` | `/course/` index page | Course listing (optional; landing page may live at `/course/tech-for-non-technical-founders-2026/` instead) |
+| `layouts/blog/single.html` | Regular blog posts | Blog post layout (should also be created — currently missing) |
+
+**5. Blog list filter update** — `themes/beaver/layouts/blog/list.html`:
+
+```go
+{{/* BEFORE: fragile frontmatter filter */}}
+{{ range (.Paginate (where .Pages "Params.course_chapter" "!=" true) ...).Pages }}
+
+{{/* AFTER: section-based filter (course pages naturally excluded) */}}
+{{ range (.Paginate .Pages ...).Pages }}
+```
+
+Since course pages now live in a different section, the `where` filter is no longer needed — they're automatically excluded from the blog list.
+
+**6. Menu update** — `config/_default/hugo.toml`:
+
+```toml
+[[menu.main]]
+  identifier = "course"
+  name = "Course"
+  pageRef = "course/tech-for-non-technical-founders-2026/"  # ← updated path
+  weight = 28
+```
+
+**7. Course navigation partial** — `course-prev-next.html`:
+
+The partial currently reads from `data/course_sequence.yaml` and constructs `/blog/:slug/` links. This must be updated to construct `/course/:slug/` links:
+
+```go
+{{- $prevUrl := printf "/course/%s/" $prev.slug }}
+```
+
+Alternatively, make it data-driven by reading the section permalink pattern from `.Site.BaseURL` + section. But since course is the only section using this partial, a hardcoded `/course/` prefix is simplest.
+
+---
+
+## Consequences
+
+### Positive
+
+| Benefit | Detail |
+|---------|--------|
+| **Clean URLs** | Course content under `/course/` — obvious, semantic, crawlable |
+| **Multi-course ready** | Add `content/course//` → auto-routes to `/course//` |
+| **Template isolation** | Course chapters render through `layouts/course/single.html` without conditionals |
+| **Editor UX** | Course editors work in `content/course/` — 43 files, not 641 |
+| **Blog filter simplified** | No more `Params.course_chapter` filter — sections auto-separate |
+| **SEO** | Independent sitemap section, Course-structured-data compatibility |
+| **Blog single.html** | Forces creation of a proper blog single template (currently missing) |
+
+### Negative
+
+| Impact | Detail |
+|--------|--------|
+| **382 internal link updates** | Every `/blog/chapter-slug/` reference in course chapter bodies must become `/course/chapter-slug/` |
+| **43 301 redirects** | Required for SEO preservation; redirects must be maintained for 90 days |
+| **External link breakage** | Anyone who linked to `/blog/form-your-founding-hypothesis-.../` gets a redirect (soft) |
+| **Build-time check** | Must verify no hardcoded `/blog/` course links slip through in PR review |
+
+### Risks and Mitigations
+
+| Risk | Likelihood | Mitigation |
+|------|-----------|------------|
+| Missing redirect | Medium | Generate redirect list from `data/course_sequence.yaml` — automate, don't hand-write |
+| Orphaned internal links | Medium | grep for `/blog//` patterns after migration; fail CI build if any survive |
+| Old blog list filter breaks | Low | After migration, `course_chapter: true` no longer exists in blog — test blog list rendering |
+| Can't find course chapters | Low | Create `content/course/` with symlink or README for editors |
+| Course nav links broken | Low | `course-prev-next.html` must update `/blog/` → `/course/` in generated URLs |
+
+---
+
+## Multi-Course Architecture
+
+The migration is designed to support multiple independent courses under `/course/`.
+
+### Directory Structure
+
+```
+content/course/
+├── tech-for-non-technical-founders-2026/        ← Course 1 (existing)
+│   └── index.md                                 ← Course landing page
+├── from-mvp-to-market-2026/                     ← Course 2 (future)
+│   └── index.md                                 ← Landing page
+├── validate-before-you-build/                   ← Course 3 (future)
+│   └── index.md                                 ← Landing page
+└── _index.md                                    ← Optional: `/course/` index page listing all courses
+```
+
+### How It Works
+
+| Aspect | Mechanism |
+|--------|-----------|
+| **URL pattern** | `/course/:slug/` applies to ALL content in `content/course/` |
+| **Landing pages** | Each course has an `index.md` in its own subdirectory — URL is `/course//` |
+| **Course chapters** | Each chapter is a leaf page bundle within its parent course directory, or standalone at `content/course//` |
+| **Template** | All course content uses `layouts/course/single.html` — conditional logic inside the template can differentiate courses via `.Params.course_id` or `.CurrentSection` |
+| **Data files** | Each course can have its own data file: `data/course-sequence-.yaml` |
+| **Navigation** | `course-prev-next.html` reads from the appropriate data file based on the course |
+| **Filtering** | Blog list needs no changes — course content is inherently excluded |
+
+### Example: Two Courses
+
+```
+/course/tech-for-non-technical-founders-2026/          ← Course 1 landing
+/course/form-your-founding-hypothesis-90-minute-sprint/ ← Course 1 chapter
+/course/smoke-test-landing-page-300-dollar-validation/  ← Course 1 chapter
+/course/from-mvp-to-market-2026/                        ← Course 2 landing
+/course/lean-market-sizing-in-one-afternoon/             ← Course 2 chapter
+/course/unit-economics-for-solo-founders/               ← Course 2 chapter
+```
+
+No Hugo config changes needed to add Course 2 — just create `content/course/from-mvp-to-market-2026/` and add its data file.
+
+### Course-Specific Schema
+
+Each course can emit distinct `Course` structured data (JSON-LD) based on `course_id` in frontmatter:
+
+```yaml
+# content/course//index.md
+course_id: "tech-non-tech-founders-2026"
+course_name: "Tech for Non-Technical Founders 2026"
+module: "Chapter 2.3"
+course_chapter: true
+```
+
+The `course/single.html` template reads `course_id` to emit the correct `hasCourseInstance` JSON-LD.
+
+---
+
+## Migration Plan
+
+### Phase 1: Content Move + Config (1 session)
+
+| Step | Action | Files |
+|------|--------|-------|
+| 1 | Create `content/course/` directory | 1 mkdir |
+| 2 | Move 43 course chapter page bundles | `mv content/blog/{slug}/ content/course/{slug}/` × 43 |
+| 3 | Move course landing page | `mv content/blog/tech-for-non-technical-founders-2026/ content/course/` |
+| 4 | **Decide fate of 7 supplementary posts** (Friday Demo Rule, 3 Standup Qs, Weekly Dev Report, Org Chart, 3 AI-era posts). Options: move to `content/course/` (they're curriculum content) or leave in `content/blog/` with cross-links. | 1 decision, 0-7 file moves |
+| 5 | Add `[permalinks.course]` to `hugo.toml` | 1 line |
+| 6 | Update menu `pageRef` to `/course/...` | 1 line |
+| 7 | Generate 43 `[[redirects]]` entries from `course_sequence.yaml` via script: `yq '.sequence[] | "[[redirects]]\n  from = \"/blog/" + .slug + "/\"\n  to = \"/course/" + .slug + "/\"\n  status = 301"' data/course_sequence.yaml` | 1 script, 43 entries in `hugo.toml` |
+| 8 | Update `course-prev-next.html`: `/blog/` prefix → `/course/` prefix in generated link URLs | 1 file edit |
+
+### Phase 2: Template + Filter Updates (1 session)
+
+| Step | Action | Files |
+|------|--------|-------|
+| 9 | Create `layouts/course/single.html` with proper course layout (article schema, course nav, module banner) | 1 new file |
+| 10 | Update blog list filter — keep `where "Params.course_chapter" "!=" true` as safety net with comment `// course chapters moved to /course/ section`; remove after production verification | 1 file edit |
+| 11 | Bulk-update `canonical_url` in all 43 chapter frontmatter blocks: `https://jetthoughts.com/blog/...` → `https://jetthoughts.com/course/...` | 43 files (sed or yq) |
+| 12 | Update ~382 internal `/blog//` links → `/course//` across all chapter bodies | Bulk sed across 43 files |
+
+**Internal link update command** (dry-run first):
+```bash
+# Extract slug list from course_sequence.yaml
+SLUGS=$(yq '.sequence[].slug' data/course_sequence.yaml)
+
+# For each slug, replace /blog/slug/ with /course/slug/ in all course chapter bodies
+for slug in $SLUGS; do
+  find content/course -name 'index.md' -exec sed -i '' "s|/blog/$slug/|/course/$slug/|g" {} +
+done
+```
+
+> **Note:** The 7 supplementary posts (Friday Demo Rule, Three Standup Questions, Weekly Dev Report, Engineering Org Chart, Agency AI Questions, AI Token Bill, Slopsquatting) also contain cross-links to course chapters. If they stay in `content/blog/`, those links must be updated too: `find content/blog/ -name 'index.md' -exec sed -i '' 's|/blog//|/course//|g' {} +` each one.
+
+### Phase 3: Validation + Launch (1 session)
+
+| Step | Action |
+|------|--------|
+| 13 | Run `bin/hugo-build` — verify zero errors |
+| 14 | Verify 301 redirects with `curl -I https://jetthoughts.com/blog/old-slug/` → 301 to `/course/...` |
+| 15 | Run test suite |
+| 16 | Spot-check 5-10 course pages render correctly with course nav, schema, module banner |
+| 17 | Verify blog list no longer shows course chapters |
+| 18 | Check breadcrumbs, course nav, schema output |
+| 19 | Verify landing page alias (`/blog/course-map-self-assessment-...`) still resolves (Hugo alias system handles this automatically) |
+
+### Phase 3: Validation + Launch (1 session)
+
+| Step | Action |
+|------|--------|
+| 12 | Run `bin/hugo-build` — verify zero errors |
+| 13 | Verify 301 redirects with `curl -I /blog/old-slug/` |
+| 14 | Run test suite |
+| 15 | Spot-check 5-10 course pages render correctly |
+| 16 | Verify blog list no longer shows course chapters |
+| 17 | Check breadcrumbs, course nav, schema output |
+
+### Redirect Retirement
+
+After 90 days from launch:
+
+```bash
+# Remove all [[redirects]] entries for course slugs from hugo.toml
+grep -v "redirects.*course-\|redirects.*form-your-founding\|redirects.*smoke-test\|..." config/_default/hugo.toml > tmp && mv tmp config/_default/hugo.toml
+```
+
+---
+
+## Alternatives Considered
+
+### Option A: Keep in `/blog/` with Taxonomy Filter
+
+Keep all content in `content/blog/`, use Hugo taxonomy or frontmatter filter to separate.
+
+**Rejected because:** Does not solve multi-course problem; keeps template ambiguity; no clean URL separation.
+
+### Option B: Hugo Content Mounts (Map `/course/` files to `/blog/` URLs)
+
+Use `[[module.mounts]]` so `content/course/` maps to `/blog/` URL path.
+
+**Rejected because:** User explicitly requested `/course/` URLs without supporting `/blog/` paths. Mounts would keep the old URL namespace alive.
+
+### Option C: Subdomain (`course.jetthoughts.com`)
+
+Host course content on a separate subdomain with independent Hugo build.
+
+**Rejected because:** Overkill for current scale; loses domain authority for SEO; adds deployment complexity; complicating for future courses.
+
+### Option D: Site-Wide Hard Redirect with No `/blog/` Support
+
+Move to `/course/` without 301 redirects from old URLs.
+
+**Rejected because:** 43 course chapters likely have indexed URLs and backlinks. 301 redirects are inexpensive and preserve ranking. The cost of generating redirects from `course_sequence.yaml` is near-zero.
+
+---
+
+## Validation
+
+### Post-Migration Checks
+
+| Check | Method | Pass Criteria |
+|-------|--------|---------------|
+| Build success | `bin/hugo-build` | Exit code 0, zero errors |
+| Redirect working | `curl -I https://jetthoughts.com/blog/form-your-founding-hypothesis-90-minute-sprint/` | HTTP 301 to `/course/...` |
+| Blog list clean | View `/blog/` | No course chapters appear |
+| Course page renders | View `/course/form-your-founding-hypothesis-90-minute-sprint/` | Course nav, schema, layout correct |
+| Course landing renders | View `/course/tech-for-non-technical-founders-2026/` | Full module table, links valid |
+| Course nav works | Click "Next →" on any chapter page | Navigates to `/course/next-slug/` |
+| No broken internal links | `grep` for hardcoded `/blog/chapter-slug/` in content | 0 matches |
+| Test suite | `bin/test` | All pass |
+
+### Success Criteria
+
+| Criteria | Target | Timeline |
+|----------|--------|----------|
+| All course URLs resolve at `/course/` | 100% | Launch day |
+| Old `/blog/` URLs redirect to `/course/` | 100% (301) | Launch day |
+| Internal links updated | 100% | Launch day |
+| Blog list excludes courses | Confirmed | Launch day |
+| Future course can be added | No config changes needed | Architecture review |
+| Redirects removed | After 90 days | Q4 2026 |
+
+---
+
+## References
+
+- Hugo docs: [Section Permalinks](https://gohugo.io/content-management/urls/#permalinks)
+- Hugo docs: [Content Mounts](https://gohugo.io/hugo-modules/configuration/#module-configuration)
+- Hugo docs: [Redirects](https://gohugo.io/content-management/urls/#redirects)
+- Hugo docs: [Template Lookup Order](https://gohugo.io/templates/lookup-order/)
+- Current data: [`data/course_sequence.yaml`](/data/course_sequence.yaml) — chapter list for redirect generation
+- Project doc: [`GOAL-AT-A-GLANCE.md`](/docs/projects/2605-tech-for-non-technical-founders/GOAL-AT-A-GLANCE.md)
+- Feedback report: [`40.01-icp-e-course-feedback-report.md`](/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.01-icp-e-course-feedback-report.md)
diff --git a/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.02-adr-content-execution-readiness.md b/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.02-adr-content-execution-readiness.md
new file mode 100644
index 000000000..b06980511
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.02-adr-content-execution-readiness.md
@@ -0,0 +1,198 @@
+# ADR: Content Execution-Readiness Policy + Threshold Anchors
+
+**ADR-ID:** 2026-06-02-002
+**Date:** 2026-06-02
+**Status:** Accepted
+**Author:** JetThoughts Course Team
+
+---
+
+## Title
+
+Course content policy: avoid speculative time/money estimations; preserve numeric thresholds at every decision gate; enforce binary execution-readiness criteria.
+
+---
+
+## Status
+
+Accepted (applied to the 18-chapter spine on 2026-06-01 to 2026-06-02).
+
+---
+
+## Context
+
+### Problem observed
+
+After the 4-persona cold-eyes panel completed on 2026-06-01, three convergent patterns emerged across the 18-chapter course "From Idea to First Paying Customer" (slug `tech-for-non-technical-founders-2026`):
+
+1. **Speculative time/money estimations created Sam-effort incoherence.** "90-minute sprint", "2-hour build", "4-week ship", "$87/4-week", "$30-80K/mo hire path" appeared as confident projections that did not match the 2-4 hr/week ~$20K-savings ICP. They also lacked sources.
+2. **Decision gates were qualitative where Sam needed binary anchors.** "Listener nods on the first pass", "single focused build", "exhausted network", "one side of paper", "ship before scope creep" - each one was a vague trigger Sam could not test against her own state.
+3. **The artifact chain (hypothesis → smoke-test → interviews → brief → MVP → first customer) lacked explicit carry-forward.** Three downstream chapters required Sam's tested price from Ch 1.3 but did not say "use that number here."
+
+### Drivers
+
+| Driver | Weight | Description |
+|---|---|---|
+| ICP-fit for Sam | High | Idea-stage non-technical founder, 2-4 hr/week, ~$20K savings, no engineering background. Speculative ranges she can't meet damage trust. |
+| Execution readiness | High | Sam must be able to act on every chapter without leaving the page or guessing. |
+| Voice integrity | High | JT voice guide rejects unsourced claims; speculative ranges violate the rule. |
+| Threshold preservation | High | Numeric pass/fail gates (300 visits, 5%, 7-of-10, 40%, ≥9/12) are the spine of the validation method. Cannot be sacrificed in the sweep. |
+| URL stability | Medium | Anchor URLs are referenced by 6+ cross-chapter and template links; structural moves must preserve them. |
+
+---
+
+## Decision
+
+### 1. Time-and-money content policy
+
+**REMOVE** from chapter bodies, titles, frontmatter, YAML, and landing page:
+
+- Sam-effort time estimations: "90-min sprint", "2-hour build", "4-week ship", "12-week cadence", "7-day demand test", Mon/Tue/Wed/Fri compressed sequencing, Week 1/2/3/4 calendar pacing.
+- Speculative cost projections: "$87 / 4-week ship", "$30-80K/mo hire path", "$1,200-$3,000 fractional CTO" without source link.
+- Per-module reading-time annotations on the landing page ("(2 hr)", "9 hours total").
+
+**KEEP** in chapter bodies:
+
+- Factual external constraints: Stripe verification 1-3 business days, ICANN 14-day domain transfer lock, AWS support recovery 3-5 days, vendor free-tier limits (Loom 25 videos, Apollo 50 contacts/month, Claude free-tier daily limit).
+- Named-case rescue dollars with attribution: Priya $38,400 / 4 months / $420 Meta; Maya $62K / 9 months / $380 Meta / 48 emails; Marcus $480 / $260 lesson; B2B fintech $180K / 8 months / 4,200 users Q1 2026; HealthTech $4,200 Meta / 0.4% conversion; HealthTech $1,200 paid pilot.
+- Cited statistics with source link: Veracode 2025 (45%), Lasso April 2025 (200+ packages), OpenHunts 2024 (PH 3.1% vs IH 23.1%), Lenny 2021 (60% / 35% / 5%).
+- Vendor-published pricing facts: Lovable $0 free / $25 Pro / $100 Scale; Supabase $0 free / $25 Pro; Stripe 2.9% + $0.30; Mixo $7/mo; Carrd Pro $9-49/yr; Sales Navigator $99/mo; Apollo Pro $49/mo; Smartlead $37/mo; Resend $20/mo; Sentry $26/mo; Porkbun $14/yr; Perplexity Pro / Gemini Advanced $20/mo.
+
+**Rule of thumb**: if a number is attached to a NAMED case (person, month, quarter) or a SOURCED stat, keep it. If it's a generic "you'll spend X" projection, remove it.
+
+### 2. Binary threshold anchors at every decision gate
+
+Every chapter that asks Sam to decide must publish a NUMERIC pass/fail rule. The anchors below are now considered canonical and must not be diluted:
+
+| Chapter | Decision | Anchor |
+|---|---|---|
+| M1.1 | Hypothesis ready to test? | Magic Lenses score **≥14/20**, no individual lens below 2. Pre-revenue founders skipping Money lens: **≥11/15** of the other three. |
+| M1.2 | Smoke test conversion read | **≥300 paid visits** before reading. **<3%** kill, **3-5%** iterate, **6-10%** go, **10-20%** strong, **>20%** verify. |
+| M1.3 | Hypothesis price | Default band before research: **$49-$99/mo** typical, **$49-$299/mo** SaaS sweet spot. Stripe-click threshold: **≥5%** visit-to-click. |
+| M2.1 | Build / pivot / kill | 10 interviews scored 1-10. **≥7** strong signals = build; **4-6** = pivot; **<4** = kill. A 7 requires Q4 ≥7 with comparison AND ≥3 emotional-language flags. |
+| M2.4 | Prototype scope cap | **Stop at 3 screens**; **~10 Lovable exchanges** budget before sharpening prompt or hypothesis. |
+| M2.4 | Prototype shape gate | 5 sessions. **4-5/5** pass = advance to M3; **2-3** = revise + 2 replacements; **0-1** = shape wrong, return to M2.1. |
+| M3.1 | Brief length | **≤ 250 words** on one side of A4 at 11pt. **2-4 sentences/section**, **5-8 lines** for no-go list. |
+| M3.2 | Brief peer QA | Peer answer must stay inside Section 3 scope AND no-go list. ANY feature not in Section 3, OR mention of cut items, OR 2+ items outside scope = FAIL. **AI-as-peer fallback**: paste Section 3 + Section 5 into Claude/ChatGPT; prompt: "name 5 things you would build that are NOT in the no-go list"; ≥2 items outside no-go list = FAIL (same signal as human peer). |
+| M4.1 | Build path routing | 5-question matrix routing Sam to validate / self-serve / fractional CTO / hire. Q3 runway thresholds + Q5 budget anchor cross-linked to M4.4 ($200/hr fractional, $8-15K/mo). |
+| M4.2 | Ownership audit | 12-item binary checklist. Any FAIL = block contractor kickoff. |
+| M4.3 | MVP "done" | 5 lights green: Stripe LIVE mode, custom domain, ≥1 outside-cohort ICP click-through, zero JS Console errors, weekly demo recording. |
+| M4.4 | Ceiling-signal graduation | Monthly scoreboard, 5 signals (data model, real-time, auth, AI cost, compliance). Date first/last observed PER signal required. **≥2 signals RED for ≥4 weeks** OR **YELLOW for ≥6 weeks** = graduate. |
+| M5.1 | Sean Ellis 40% | **≥40%** must-have = advance; **25-40%** with one segment >40% = target segment; **<25%** = product problem. |
+| M5.2 | Channel commit | 12-point scorecard. **≥9/12** commit; **7-8/12** pilot top 2 first; **≤6/12** revisit interviews. |
+| M5.3 | Warm-to-cold handoff | All 50 contacted + ≥10 replies + (<3 demos OR last-10 reply rate <10%) = move to M5.5. |
+| M5.4 | Deposit | Year-one ACV = Ch 1.3 tested price × billing period. Deposit = 10-30% of year-one ACV; floor **$500**; ceiling ~**$10K** before procurement window. Pick **midpoint of smallest applicable band** by default. |
+| M5.5 | Reply-rate decision | **<5%** STOP + diagnose; **5-10%** continue + rotate one element; **>10%** accelerate same-shape. |
+
+### 3. Module 2 two-pass framing (no structural split)
+
+M2.1 retains its current slug AND its synthesis section anchor `#synthesis-write-down-what-you-heard-decide-whats-next`. Six cross-references (validated-problem-statement-template, vibe-prd-template, one-page-product-brief-vibe-prd, must-have-segment-pmf-test, should-you-hire-2026-decision-tree, pivot-or-persevere-decision-framework) depend on it.
+
+Rather than split M2.1 into a technique chapter + post-M2.3 synthesis closer (which would have renumbered M2.4, renamed slugs, broken anchor URLs), we added **two-pass framing callouts** at:
+- Top of M2.1 (declaring Pass 1 = technique, Pass 2 = post-M2.3 synthesis)
+- Top of the Synthesis section (declaring "You are now on Pass 2")
+- M2.3 "What happens after the 10 calls" section (declaring "You are now on Pass 2 of Ch 2.1")
+
+This is the KISS resolution to the Tutorial-Engineer critic's loop-back finding.
+
+### 4. Title resync from 3 sources of truth
+
+The chapter display title lives in three places: chapter `index.md` frontmatter (`title` + `og_title`), `data/course_sequence.yaml`, and `content/course/tech-for-non-technical-founders-2026/_index.md` (landing page module index).
+
+When a title changes, all three must be updated in the same commit. The `bin/validate-course title-yaml-match` validator catches drift between frontmatter and YAML; the landing page must be manually re-synced. **Chapter slugs are immutable** (URL stability).
+
+### 5. Decision-gate canonical list maintained in this ADR
+
+When a chapter gate changes (threshold tightens, new anchor added), this ADR is updated. The chapters reference the ADR by URL: `docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.02-adr-content-execution-readiness.md`.
+
+### 6. 4-persona cold-eyes panel as BLOCKING gate before content ships
+
+For any voice-sensitive content edit (course chapter, blog post, marketing copy), spawn ≥3 of these critics BEFORE marking work done:
+- **AI-feel detector** (content-marketer)
+- **Voice guide enforcer** (banned patterns, "who" / "show" / "practitioner" tests)
+- **ICP reader** (course = "Sam" idea-stage non-technical first-timer; website = "Alex" burned founder)
+- **Cold-eyes reader** (no context, fresh perspective)
+
+Convergence ≥2 critics = high-confidence fix needed. Single critic = judgment call. Voice quality verdict alone is necessary but not sufficient - structural / execution / decision-readiness lenses are mandatory.
+
+### 7. Tier 1 / 2 / 3 punch list shape
+
+Critic findings synthesized into three tiers:
+- **Tier 1 BLOCKING** = convergent ≥2 critics, ship-blocking
+- **Tier 2 judgment** = single-critic but high-impact decision-gate gap
+- **Tier 3 polish** = link/price hygiene, cross-references
+
+Tier 1 applied without further approval; Tier 2 + 3 surfaced to user before applying.
+
+### 8. Reader-navigation callout pattern (Pass 7, 2026-06-02)
+
+Six chapters received **reader-navigation / anti-bounce callouts** — brief boxes placed before dense sections that serve one of three purposes:
+
+1. **Anti-bounce**: name the cost/commitment upfront before the reader invests reading time (Ch 1.2 budget anchor, Ch 2.4 Lovable pricing onramp)
+2. **Fast-path exit**: give skim-first readers a destination to jump to (Ch 2.3 "skim instinct," Ch 4.2 5-minute self-check)
+3. **Reading guide**: distinguish blocking rules from reference material (Ch 4.3 "3 load-bearing pre-flight rules")
+
+Pattern is emerging as a deliberate content technique for the course's ICP (time-poor, skim-first, execution-anxious). Future chapters should consider adding a navigation callout before any section that (a) requires a financial commitment, (b) has a skip-eligible audience, or (c) lists >8 rules without distinguishing load-bearing from reference.
+
+### 9. Tool-input traceability policy
+
+Every chapter that names a tool MUST also tell Sam:
+1. **WHAT artifact to PASTE INTO the tool** (e.g., "use your Founding Hypothesis [customer] blank as the [ICP] placeholder")
+2. **WHERE the tool's OUTPUT goes** (e.g., "save Apollo's 50-contact export to a 'Module 5 cold seed' tab; you will reuse this filter in Ch 5.5")
+3. **WHICH downstream chapter or artifact consumes that output**
+
+This forms the **artifact chain**: Hypothesis (Ch 1.1) → smoke-test page (Ch 1.2) → price hypothesis (Ch 1.3) → sharpened questions (Ch 2.2) → 10 transcripts (Ch 2.3) → Validated Problem Statement (Ch 2.1 synthesis) → vocabulary doc (Ch 2.4) → one-page brief (Ch 3.1) → outcome-shaped feature list (Ch 3.2) → live MVP (Ch 4.3) → 40% segment + verbatims (Ch 5.1) → 50-name list (Ch 5.3) → DPA + deposit (Ch 5.4).
+
+**Highest-leverage paste in the course**: Ch 2.4 vocabulary → Ch 4.3 Lovable Phase 1 prompt. This is the single chain where the user-tested language directly affects production button labels and column headers.
+
+**Critic-tested gap rule**: when a tool prompt has a placeholder like `[your ICP]` or `[PRODUCT CATEGORY]`, the chapter MUST name the source artifact and field in the same callout. Sam should never have to re-derive what she already wrote.
+
+### 10. AI-as-peer quality-gate fallback (Pass 7, 2026-06-02)
+
+When a chapter's quality gate requires a human peer (Ch 3.2 brief QA, Ch 2.1 Magic Lenses scoring), the chapter MUST provide an AI-as-peer fallback with:
+1. The exact prompt to paste (including the scope constraints)
+2. The same pass/fail rule as the human peer would use
+3. The same consequence (FAIL = revise and re-run)
+
+This ensures the solo founder — the course's primary ICP — can execute every quality gate without calendar-coordinating a peer. The Ch 3.2 Claude/ChatGPT fallback (Pass 7) is the canonical example.
+
+---
+
+## Consequences
+
+### Positive
+
+- Every decision gate has a binary anchor Sam can test against her state.
+- No content is ship-blocked by a speculative range that proves wrong six months later.
+- Price carry-forward chain (M1.3 → M5.2 → M5.4) is explicit; Sam doesn't have to re-derive numbers.
+- Lovable price drift ($20 vs $25) resolved at $25 canonical.
+- Module 2 loop-back signposted instead of hidden.
+- Six anchor URLs preserved across the recent structural pass.
+- The artifact map is one canonical table per ADR; future chapter edits can cross-reference rather than redefine.
+
+### Negative / accepted tradeoffs
+
+- The course gives up the "12-22 weeks elapsed at 2-4 hr/week" elevator-pitch line for an honest "length is a byproduct of effective delivery" framing. This may hurt initial-glance landing-page conversion vs courses that promise a 12-week sprint.
+- Magic Lenses ≥14/20 is a strong claim that requires Sam to score lenses she may not understand intuitively. We've reduced the risk by lowering the pre-revenue bar to ≥11/15.
+- Module 2 two-pass framing requires Sam to keep two tabs open during her post-M2.3 synthesis pass. This is a UX compromise vs the cleaner chapter-split alternative.
+
+### Future revisits
+
+- The Lovable canonical price ($25/mo) must be re-verified annually against the vendor's published pricing.
+- Vendor pricing facts (Sales Navigator, Apollo, Smartlead, etc.) need a periodic refresh pass.
+- The artifact carry-forward chain may add a new artifact (e.g., M5 customer-segment language); the ADR table is the place to record it.
+- If a 6th critic lens (e.g., decision-readiness, tool-traceability) becomes standing practice, this ADR is updated to add it to the panel.
+
+---
+
+## Related decisions
+
+- ADR 30.01 — Course URL migration to `/course/` namespace
+- M1-M3 audit 2026-05-28 (`40-49-review/40.01-m1-m3-audit-2026-05-28.md`)
+- ICP-Sam walkthrough (`10-19-research/10.07-icp-sam-persona-course-walkthrough.md`)
+- SIPOC course-logic validation (`40-49-review/40.03-sipoc-course-logic.md`)
+
+## Related commits
+
+- `c0718981` — 4-persona critic sweep (time/money removal + M4.1 jargon gloss + Module 2 two-pass framing)
+- `c9adbaee` — Execution-readiness sweep (13 critic-flagged gap closures)
diff --git a/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.03-course-format-requirements-for-creators.md b/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.03-course-format-requirements-for-creators.md
new file mode 100644
index 000000000..6252fb793
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.03-course-format-requirements-for-creators.md
@@ -0,0 +1,940 @@
+# 30.03 — Course Format Requirements for Creators
+
+**Status:** Canonical requirements document
+**Date:** 2026-06-07
+**Author:** Buffy (AI agent)
+**Type:** Architecture decision — course format design
+**Supersedes:** Implicit conventions in GOAL-AT-A-GLANCE.md and course-chapter-pipeline.md
+**Based on:**
+- **Action Mapping** (Cathy Moore) — backward design from measurable goals, prioritize behaviors over information
+- **Minimalist Instruction Theory** (John M. Carroll) — error recovery, self-contained units, minimal reading
+- **BJ Fogg's Behavior Model (B=MAP)** — Motivation + Ability + Prompt; when motivation is low, increase Ability
+- **Zeigarnik Effect** — unfinished tasks create cognitive tension that drives completion
+- **Dual Coding Theory** (Allan Paivio) + **Cognitive Load Theory** (John Sweller) — visual+verbal channels expand working memory
+- **NN/g eyetracking research** — F-pattern scanning, 79% scan vs 16% read word-for-word
+- Online course design research (onlinetrainingconcepts.com, teaching-resources.delta.ncsu.edu)
+- Gap analysis of current 18-chapter course against micro-learning spec
+- Sam ICP profile (idea-stage non-technical first-timer, low time, problem-motivated)
+- 40.06 Sam Customer Journey Report, 40.07 Sam Experience Improvement Report
+- GOAL-AT-A-GLANCE.md, course-chapter-pipeline.md
+- US DOL "Make America AI-Ready" 2026 text-message course initiative (precedent for text-based microlearning at national scale)
+
+---
+
+## Executive Summary
+
+**Target student:** Sam — a non-professional, low-time-availability, low-intrinsic-interest founder who is highly problem-motivated. He has ~$20K savings, works on lunch breaks and nights/weekends, and has never hired a developer. He wants the minimum effective dose to get results without any help.
+
+**The format that works for Sam:** A tightly scoped, micro-learning style course with ultra-short, repeatable lesson units. Each lesson drives ONE tiny, visible result with minimal reading and immediate application. Text-only with small graphs and images. No video.
+
+**Current state:** The course ships 18 long-form chapters (~2,000-4,500 words each, ~50,000+ words total). Each chapter is a comprehensive article — orientation callout → narrative opener → multi-section body → "What to do tomorrow" → further reading. This format is excellent for deep reference but too long for the micro-learning spec.
+
+**Target state:** 5 modules × 4-6 micro-lessons each (20-25 total lessons), each lesson 400-600 words (5-10 min read + 5-15 min do). Total reading time: ≤2-3 hours. Same 6 artifacts. Same emotional arc. Radical compression, not scope reduction.
+
+**This document is the non-negotiable spec for course creators.** Use it to audit existing chapters and design future ones.
+
+---
+
+## 1. Overall Course Design Principles
+
+> **This section describes the TARGET format.** The current course uses a different structure (long-form chapters, ~2,000-4,500 words each). For current state conventions, see `course-chapter-pipeline.md`. For the migration path from current → target, see §8.
+
+### 1.1 Single Outcome
+
+The entire course must promise and deliver **one** clearly defined, concrete outcome.
+
+**Current (correct):** "From idea to first paying customer in the most effective way for 2026. You walk away with: validated hypothesis, live smoke-test landing page, signed validated problem statement, Product Brief, build decision, live MVP, and one signed paid pilot."
+
+**Requirement:** This promise is the right scope. Every lesson must trace back to this single outcome. If a lesson's content does not directly advance the student toward this outcome, it must be removed or moved to an optional appendix.
+
+### 1.2 Time Cap
+
+**Total reading time:** ≤2-3 hours, split into 5-15 minute units.
+
+**Current (gap):** ~50,000+ words, estimated 4-6 hours of reading across 18 long-form chapters.
+
+**Requirement:**
+- Each lesson: 400-600 words (5-10 minutes read) + 5-15 minutes doing
+- Total course: 20-25 lessons × ~500 words = ~10,000-12,500 words of instructional content
+- Structural content (module maps, quickstart, FAQ): ~2,000 additional words
+- Total reading: ≤2-3 hours for the core path
+
+**Research basis:** Micro-learning sees 80-90% completion rates vs 30-45% for traditional long-form courses. The 5-15 minute unit maps to the attention span of a phone-commuting, time-poor adult learner. Free text-based courses average 1-15% completion; micro-learning structure pushes toward the high end.
+
+### 1.3 Microlearning Structure
+
+**Rule:** 1 problem → 1 micro-skill per lesson. No "nice to know" content. No theory without immediate application.
+
+**Current (gap):** Chapters contain multiple concepts, rich narratives, "Advanced" sidebars, and "Further reading" sections. Example: Chapter 4.3 (Self-Serve Stack) covers tool selection, 12 rules, 4 build phases, SQL self-test, and community resources — all in one chapter.
+
+**Requirement:**
+- One lesson = one micro-result ("you leave with a finished X / a decision Y / a configured Z")
+- Theory/concept appears ONLY as setup for the immediate action
+- "Advanced" and "Further reading" content moves to appendices or companion pages
+- Sidebars become separate optional lessons or are removed
+
+**Framework: Action Mapping (Cathy Moore)**
+
+Action Mapping is a visual, backward-design approach that violently rejects the "information dump" methodology. The process:
+
+1. **Identify the measurable goal** — the exact result the student wants to achieve
+2. **Map the specific, observable behaviors** required to reach that goal — what the learner needs to DO, not what they need to KNOW
+3. **Design practice activities** for each behavior — realistic scenarios, not passive reading
+4. **Include ONLY information that directly supports the behavior** — excise everything "nice to know"
+
+> **Critical rule:** If a piece of information does not directly dictate how the learner executes the required behavior, it must be removed. Traditional subject matter experts believe learners need deep theoretical foundations before acting. Action Mapping explicitly prohibits this. The resulting course consists of realistic practice activities, not passive reading assignments.
+
+**Framework: Minimalist Instruction Theory (John M. Carroll)**
+
+Carroll's empirical studies revealed that adult learners almost never read instructional materials sequentially. Instead, they attempt real-world tasks immediately and only consult documentation when they encounter an error. Key principles:
+
+1. **Minimize passive reading** — allow users to fill in gaps through action
+2. **Integrate error recognition and recovery** — anticipate failures explicitly in the instruction
+3. **Make all learning activities self-contained** — never require the learner to recall a concept from 5 days ago
+4. **Start with meaningful, real tasks immediately** — not with foundational theory
+
+> **Critical rule:** Every lesson must include explicit troubleshooting: "If your result looks like X, you did Y. Here's exactly how to recover." Traditional courses present a sanitized path to success; when the student inevitably deviates, they lack the knowledge to self-correct and abandon the effort.
+
+### 1.4 Asynchronous, Self-Paced
+
+**Current (correct):** No live sessions. Everything works in short, irregular time slots. ✓
+
+**Requirement:** Maintain this. Never introduce live sessions, cohorts, or synchronous elements.
+
+### 1.5 Mobile-Friendly Text
+
+**Current (partial):** Content uses short paragraphs and subheadings but several chapters have wide tables (builder comparison, channel-fit scoring, 12-item audit) that require horizontal scrolling on mobile.
+
+**Requirement:**
+- Single-column layout. No tables wider than 3 columns. No horizontal scrolling.
+- Paragraphs: 2-3 sentences max. Aim for 40-60 characters per line.
+- Every lesson must pass a 375px viewport test (iPhone SE).
+- Front-load: most important information in the first 2-3 sentences.
+
+### 1.6 Word Count Bands
+
+Different lesson types demand different word counts. These bands are based on analysis of micro-learning best practices and mobile reading behavior:
+
+| Lesson Type | Optimal Word Count | Rationale |
+|---|---|---|
+| **Micro-tips** (quick reference, checklists) | 50-125 words | Enough for one insight + one action. Zero fatigue. |
+| **Standard lessons** (core path, pure concept) | 400-600 words | ~2-5 minute read. Fits a problem, scenario, and detailed solution with formatting. |
+| **Tool-walkthrough lessons** (action-heavy with tool-agnostic framing + Sam-glossing) | 600-900 words | ~5-8 minute read + 15-45 minute do. Accommodates: 3-tool agnostic framing (Mixo/Manus AI/Durable named) + 3-5 first-mention glosses (CTA, hero image, incognito, head-tag, snippet, pixel, etc.) + AI-augmented sub-steps (regenerate prompts, AI image generation, ChatGPT/Claude assist). |
+| **Deep-dive syntheses** (optional companion pages) | 700-1,200 words | Requires aggressive use of headers, bullets, and bolding to remain digestible. |
+
+**For this course:** Pure-concept lessons (hypothesis sentence, Mom Test scoring) hit the 400-600 band. Tool-walkthrough lessons (AI builder, tracking install, Stripe setup, MVP deploy) need 600-900 because Sam is a true non-technical first-timer and tool-pinning is forbidden (see `feedback_course_lessons_tool_agnostic`) — agnostic framing requires naming 2-3 tools + glossing each technical term Sam encounters. Companion reference pages (derived from v1 long-form chapters) can be longer (500-800 words) since the reader has chosen to visit.
+
+**Pilot validation (2026-06-08 → 2026-06-11):**
+- Lesson 1.2a (smoke-test-build-page): 935w. Tool-walkthrough band confirmed. Adding the 600-900 band formalizes what the pilot proved was necessary.
+- Lesson 1.2b (smoke-test-wire-tracking): 680w. Borderline standard/tool-walkthrough — heavy glossing pass (snippet, head tag, heatmap, session recording, Meta Pixel, LinkedIn Insight Tag, Reddit Pixel, GA4, incognito, B2B/B2C) pushed it over the 600 line.
+
+> **Future consideration — push-based delivery:** An email sequence version (5-7 day intensive per module) could be added as a companion delivery channel in a future iteration, with the web page remaining the canonical reference. Research precedent: the US DOL's 2026 "Make America AI-Ready" SMS-based text course achieved 80-90% completion rates with push delivery vs 12-15% for pull-based LMS courses. This is noted here so the idea is not lost, but it is out of scope for the current web-based course build.
+
+---
+
+## 2. Standard Lesson Template (Non-Negotiable)
+
+> **Critical rule — template labels are writer-only.** The 8-part labels ("1. Hook," "2. One-sentence outcome," "3. Minimal concept block," etc.) are internal scaffolding for creators and QA reviewers. They MUST NOT appear in published content. A reader who sees "1. Hook (3 sentences)" on a lesson page will assume the content is an unfinished draft and leave. The template shape must be followed structurally, but the labels are never visible to the student.
+
+Every lesson follows this exact 8-part template (7 mandatory + 1 optional). Students learn the pattern once and trust it for the entire course. Think: "unit tests for learning."
+
+### 2.1 Hook (1-3 sentences)
+
+Start with a very specific pain sentence plus the immediate win.
+
+> **Example:** "Right now you're wasting 30-60 minutes a week on manual Stripe reconciliation. In this lesson you'll set up a one-click export that eliminates it completely."
+
+**Current (gap):** Openers are narrative vignettes (named-founder stories, stat-anchored hooks) that run 2-5 paragraphs. These are effective for deep reading but too long for micro-learning.
+
+**Requirement:** Maximum 3 sentences. Must contain: (a) the pain in the student's language, (b) the immediate win from completing this lesson.
+
+### 2.2 One-Sentence Outcome
+
+> "After this lesson you will be able to: [single, observable action]."
+
+**Requirement:** The outcome must be observable and verifiable. Not "understand X" but "create X" or "configure X" or "decide X."
+
+**Requirement: The outcome is a human result, not a grading rubric.** The student just opened this page. They don't yet know what "14/20" or "GA4 pixel" mean. Front-loading scoring criteria, tool names, or internal mechanics overwhelms before the lesson has earned the right to introduce them. Write the outcome as the change that matters to the student in their world — not the deliverable checklist the creator uses to grade the result.
+
+| ❌ OUTPUT (deliverable spec — avoid) | ✅ OUTCOME (human result — preferred) |
+|---|---|
+| "write a Founding Hypothesis scored ≥14/20 across four lenses, with no blank below 2" | "write a single sentence about your idea that a stranger reads and either says 'that's my problem' or 'not me' — instead of 'sounds great'" |
+| "install GA4 + Google Ads tag, or your platform's pixel, plus Clarity — and name the 3 conversion numbers" | "install tracking on your landing page so you can see who visits and what they click — before you spend a dollar on ads" |
+
+**The scoring criteria and tool details stay in the success check (§2.5) and concept block (§2.3) where they belong as quality gates, not first impressions.** The outcome line answers the student's first question: "why should I keep reading?"
+
+### 2.3 Minimal Concept Block (150-300 words)
+
+Only what is needed to execute the step. Nothing more.
+
+**Constraints:**
+- Max 3 new terms per lesson; each defined in one sentence
+- Use bullets instead of long paragraphs where possible
+- No abstract theory. Extremely concrete language
+- If a concept needs more than 300 words, it's two concepts → split into two lessons
+
+**Current (gap):** Body sections in current chapters run 500-1,500 words with rich narrative, case studies, and multiple concepts interleaved.
+
+### 2.4 Visual Micro-Aid (Optional but Recommended)
+
+One compact diagram, tiny flow, or before/after example image.
+
+**Rule:** If explaining takes more than 4-5 sentences, consider a small graph or schematic.
+
+**Current (correct):** Mermaid diagrams and SVG illustrations are used. These should be preserved but simplified for the micro-lesson format — each visual should illustrate ONE concept, not the full chapter argument.
+
+**Framework: Dual Coding Theory (Allan Paivio) + Cognitive Load Theory (John Sweller)**
+
+The brain has two separate processing channels: verbal (text/speech) and visual (images). Working memory is limited to ~5-9 elements. When complex text overloads the verbal channel, the student abandons the lesson. By presenting information through both channels simultaneously, cognitive load is distributed across both channels, functionally expanding working memory capacity. The brain processes images 60,000 times faster than text.
+
+**Visual discipline rules:**
+1. **Eradicate decorative graphics** — stock photos, abstract backgrounds, and non-informational images force the student to waste mental energy determining if the image contains relevant information. They must be removed.
+2. **Prioritize informational visuals** — simple flowcharts, timelines, before/after comparisons, conceptual diagrams. One concept per visual.
+3. **Design for mobile dimensions** — visuals must be legible on a smartphone without zooming. Use max 3 colors, minimal text, high contrast.
+4. **Avoid complex infographics** — multi-layered infographics with 5+ fonts, 10+ colors, and tiny text overwhelm the visual channel and induce extraneous cognitive load.
+5. **One visual per lesson** — in micro-learning, more than one visual per 400-word lesson adds cognitive load rather than reducing it.
+
+### 2.5 Step-by-Step "Do This Now"
+
+Numbered list, 3-7 steps. Each step must be executable in under 3 minutes and written as an imperative action.
+
+**Include "success check" after the last step:** "You know it worked if you see X / have Y / can do Z."
+
+**Current (partial):** "What to do tomorrow" sections exist in every chapter but (a) appear at the end after long bodies, (b) sometimes have 5+ steps, (c) don't always include success checks.
+
+**Requirement:**
+- 3-7 imperative steps
+- Each ≤3 minutes to execute
+- Success check on the final step
+- Steps use active voice, direct address ("Open your Stripe dashboard. Click Products. Create a new product called...")
+
+### 2.6 Error Anticipation (Minimalist Instruction)
+
+After the numbered steps, include explicit error recovery for the most common failure mode. This is a direct application of Carroll's Minimalist Instruction Theory — students will make mistakes, and without recovery guidance they abandon the effort.
+
+**Format:**
+
+> **If this fails:** [most common symptom]. **Why:** [root cause in one sentence]. **Fix:** [recovery action in 1-2 steps].
+
+**Example:**
+
+> **If this fails:** Your Stripe Payment Link shows "Account pending — verification required." **Why:** Stripe verification takes 1-3 business days for first-time accounts. **Fix:** Submit your business details now. While waiting, complete the next lesson (you don't need the live link to continue).
+
+**Requirement:** Every lesson must include at least one error anticipation block. Lessons that can fail in multiple ways should include the single most common failure mode. This replaces the traditional "sanitized path to success" with honest error recovery that empowers autonomous progress.
+
+### 2.7 Case Study Narrative (ONE per MODULE, not per lesson)
+
+**Updated 2026-06-08:** case studies live at the **END OF EACH MODULE** as a single coherent walkthrough page, NOT inside every lesson. One founder per module (Tomas OR Mia), picked by module-level ICP-fit.
+
+**Why module-level, not per-lesson:**
+
+Earlier drafts placed a case study at the end of every lesson. Three problems:
+1. **Fragmented narrative** — Mia's full journey through Module 1 was scattered across 4 lesson-end snippets, each having to re-establish her context.
+2. **Word-count drag** — per-lesson case studies added ~130 words to each lesson, pushing the 400-600 budget into 700-900.
+3. **Repetition** — each lesson had to introduce the character, restate the hypothesis, repeat the setup.
+
+Module-end case studies fix all three. The reader follows ONE founder through ALL the module's lessons as a continuous story. Each lesson body stays tightly focused on its single algorithm.
+
+**Module-level ICP-fit picking:**
+
+Pick the founder whose situation most viscerally demonstrates THAT MODULE'S central work for an idea-stage Sam.
+
+- Module 1 (Hypothesis + Smoke Test) — visualization-heavy work → **Mia** (B2C; broken WordPress screenshot, parent-voice copy)
+- Module 2 (Validate via Interviews) — structured 5-question Mom Test → **Tomas** (B2B; ICP discipline, scored transcripts)
+- Module 3 (Product Brief) — small-scope brief example → either, pick by which lands sharper
+- Module 4 (Build MVP) — Supabase + Stripe + RLS depth → **Tomas** (B2B; technical concepts)
+- Module 5 (First Paying Customer) — DPA + deposit → either; if Tomas was M4, Mia gives variety
+
+**Do NOT** put case studies inside individual lessons. They live ONLY at the module-end walkthrough page.
+
+**Module case-study page format:**
+
+Each module gets a dedicated slug: `module-N-walkthrough-` (e.g. `module-1-walkthrough-mia`). The page covers ALL of that module's lessons as ONE continuous arc.
+
+Page structure:
+
+```markdown
+> **Module N walkthrough · [Tomas/Mia]** · From Idea to First Paying Customer
+>
+> *Illustrative composite based on patterns from real founder builds, not a single client story.*
+
+[Brief intro: 2-3 sentences naming the founder + their idea]
+
+## Lesson N.1: [Title]
+
+[3-5 paragraphs following the 4-beat arc: input → challenge → action → result]
+
+## Lesson N.2: [Title]
+
+[Same arc, picking up the artifact from N.1]
+
+[...one section per lesson in the module...]
+
+## What Mia/Tomas walked away with at the end of Module N
+
+[Bullet list of the module's artifacts the founder now has]
+[Bridge sentence: "Next: Module N+1, where she/he..."]
+```
+
+**4-beat arc per lesson section (same as before):**
+
+1. **Input:** What artifact did they bring from the previous lesson?
+2. **Challenge:** What went wrong when they applied the lesson's algorithm?
+3. **Action:** What exact fix did they apply, following the lesson's steps?
+4. **Result:** What observable outcome did the fix produce?
+
+**Anti-pattern — do not write fact-list case studies:**
+- ❌ "Tomas: Opens Mixo, pastes hypothesis, gets page in 30 seconds. Headline: 'Reconcile Stripe & QuickBooks in 90 seconds.'"
+- ✅ "Tomas opens Mixo, pastes his hypothesis. The first page has a generic headline... so he tightens the prompt and regenerates. The second page reads..."
+
+The difference: the first is a list of facts. The second is a story the reader can see themselves in — with friction, a fix, and a result.
+
+**Discoverability:** **WHEN the module's walkthrough page exists**, lessons in that module add a third footer line at the END: `> **See it in action:** [Module N walkthrough · Tomas/Mia](/course/.../module-N-walkthrough-X/)`. **Do NOT** add this line before the walkthrough page is published - a footer pointing at a placeholder URL or "coming soon" text reads as a broken promise and undermines lesson trust. The line is added in the SAME commit that publishes the walkthrough page.
+
+**When to write the module case study:** AFTER all of that module's lessons are migrated to v2. Writing it mid-migration creates handoff drift; the walkthrough's "Lesson N.3" section depends on what N.3 actually says.
+
+### 2.8 Micro-Reflection (60-90 seconds)
+
+### 2.9 Closure Block (Done / You have now / Next / If blocked)
+
+The lesson ends with four labeled slots in a single blockquote — students learn the pattern once and trust it for every lesson.
+
+```markdown
+> **Done:** [the action criterion - what's literally completed]
+>
+> **You have now:** [cumulative artifacts from this lesson + prior lessons in module] + [the validated state]. [What's NOT yet validated, and which lesson tests it next.]
+>
+> **Next:** [link to next lesson] - [what this lesson's artifact feeds INTO the next lesson — name the specific dependency]
+>
+> **If blocked:** see "If this fails" above.
+```
+
+**Example (Lesson 1.2a, locked 2026-06-11):**
+
+```markdown
+> **Done:** your URL is live and one stranger named who it's for and what it does in 3 seconds.
+>
+> **You have now:** Founding Hypothesis (1.1) + a clear landing page (1.2a). Demand is the next test.
+>
+> **Next:** [1.2b · Wire Tracking Before You Spend a Dollar](...) - installs tracking on the URL you just built, so you can see what visitors do once traffic starts.
+>
+> **If blocked:** see "If this fails" above.
+```
+
+**Why four slots, not one paragraph:** dense single-sentence closures collapse three different reader concerns ("did I finish?" / "what do I have?" / "what's next?") and force re-reading. Labeled slots let Sam scan to the slot he needs.
+
+**Requirements:**
+- `Done` line states the literal completion criterion (observable action result).
+- `You have now` line enumerates cumulative artifacts ("Founding Hypothesis (1.1) + clear landing page (1.2a) + tracking (1.2b)") AND names the validated state. When relevant, also names what's NOT yet validated and which lesson tests it ("Demand is the next test" / "Demand starts in 1.2c").
+- `Next` link must name the specific dependency: what artifact from THIS lesson the next lesson consumes ("installs tracking on the URL you just built").
+- `If blocked` always points back to the lesson's `If this fails:` error blocks.
+
+**Voice rules for the closure block:**
+- Sam-voice, not Paul-voice. Use binary observable behavior ("either say 'that's me' or scroll past") not abstractions ("resonate with ICP").
+- No budget mentions in Done/You-have-now/Next prose. The lesson title may include budget framing if it's an established title.
+
+**Current (legacy):** v1 long-form chapters use a single `Done when: X. Next click: Y. If blocked: Z.` block. Phase 2 migration replaces with the 4-slot structure above.
+
+---
+
+## 3. Chapter / Module Level Requirements
+
+Modules are "milestones" in the learner's journey from pain to solved state.
+
+### 3.1 Structure
+
+- 3-7 modules per course (current: 5 ✓)
+- 3-7 lessons per module (current: 3-5 chapters per module, but chapters are long-form not micro-lessons)
+- Each module has one milestone outcome: "By the end of this module you will have [X asset / configuration / decision] in place."
+
+### 3.2 Module Entry/Exit
+
+**Clear entry condition:**
+> "You are ready for this module if you already have X and Y done."
+
+**Clear success definition:**
+> "You have finished this module when you can show [screenshot/result/number/decision] without help."
+
+**Current (partial):** Input/Output callouts exist and are well-structured. The entry/exit is clear. What's missing: the explicit "without help" framing and the observable success definition.
+
+### 3.3 Short "Map" at Module Start
+
+Bullet list of lessons with one line per lesson: "L1 — Do X → get Y."
+
+**Current (gap):** Module index on landing page lists chapter titles but not as a micro-map with one-line outcomes per lesson.
+
+### 3.4 "Minimum Viable Path"
+
+Mark lessons as **core** vs **optional** so time-starved learners can skip extras without losing the main result.
+
+**Current (gap):** The course has a linear 18-chapter path. Chapter 2.2 (AI Personas) is identified as the most skippable chapter (3/10 trust score per 40.06) but remains in the numbered sequence. No formal core/optional tagging exists.
+
+**Requirement:**
+- Every lesson tagged `[CORE]` or `[OPTIONAL]` in the module map
+- Core path alone must produce the module's milestone outcome
+- Optional lessons must not be prerequisites for core lessons in later modules
+- Max 2 optional lessons per module
+
+**Current course core/optional mapping (proposed):**
+
+> **This mapping applies to the CURRENT long-form chapters during the Option C migration.** The target v2 structure will have 20-25 micro-lessons following the 8-part template, not this chapter list. This table helps identify which existing chapters to tag as core/optional now.
+
+| Module | Core Lessons | Optional |
+|---|---|---|
+| M1 (Hypothesis & Smoke Test) | 1.1 Hypothesis, 1.2a Build page, 1.2b Run test, 1.3 Price test | Validation tools field guide |
+| M2 (Validate) | 2.1 Mom Test, 2.3a Find people, 2.3b Outreach, 2.4 Prototype | 2.2 AI Personas |
+| M3 (Design) | 3.1 Product Brief, 3.2 Outcomes check | — |
+| M4 (Build) | 4.1 Hire decision, 4.2 Ownership, 4.3a Stack setup, 4.3b Build phases | 4.4 Ceiling signals |
+| M5 (First Customer) | 5.1 PMF test, 5.3 Personal network, 5.4 Paid pilot | 5.2 Channel selection, 5.5 Cold outbound |
+
+---
+
+## 4. Engagement for Low-Motivation, Short-Attention Learners
+
+We assume low initial motivation and frequent distractions. We rely on structure, not willpower.
+
+### 4.1 Immediate Win in First 10 Minutes
+
+Lesson 1 must deliver a visible micro-result (a small automation, decision, clarity, or quick configuration) so the learner feels it was worth starting.
+
+**Current (gap):** Module 1.1 is a 90-minute sprint with 6 steps. The first tangible output (a filled hypothesis sentence) comes after ~30 minutes of reading and framework setup.
+
+**Requirement:** Lesson 1.1 must produce a visible result (a hypothesis sentence, even a rough one) within 10 minutes of starting to read.
+
+### 4.2 "Attention Cycle" in Each Lesson
+
+Hook → short input → active doing → quick reflection.
+
+**Current (partial):** The current chapters have hook + long input + action at the end. The attention cycle is too stretched.
+
+**Requirement:** The 8-part template (sections 2.1-2.8 above) enforces this cycle. No lesson skips the active-doing, error-recovery, or reflection steps.
+
+### 4.3 BJ Fogg's Behavior Model (B=MAP)
+
+Relying on student motivation is an architectural flaw. Motivation is volatile — it spikes when the student enrolls and plummets the moment they encounter friction. To guarantee completion, the course must function independently of motivation levels.
+
+**Fogg's model:** Behavior = Motivation + Ability + Prompt. All three must converge simultaneously for any behavior (e.g., opening the next lesson) to occur. When Motivation is low, the only mathematical way to ensure the behavior is to drastically increase Ability — make the task incredibly easy.
+
+**Application to this course:**
+- **Increase Ability:** Reduce each lesson to a scannable page that takes 2-5 minutes to read. The student completes it even on their worst, most unmotivated day.
+- **External Prompt:** The browser bookmark or habit anchor is the prompt — the student opens the next lesson at a consistent time, requiring zero initiative.
+- **Tiny Habits anchoring:** Instruct students to tie opening the next lesson to an existing unbreakable routine ("Open it while the coffee is brewing" or "During the first 5 minutes of your train commute").
+- **Require seconds, not minutes:** The first action in every lesson must be completable in under 1 minute. The student builds momentum from the first click.
+
+### 4.4 Zeigarnik Effect and Cognitive Cliffhangers
+
+The human brain remembers unfinished tasks significantly better than completed ones (Zeigarnik, 1927). Unfinished tasks create cognitive burden — they weigh on the mind and demand resolution, often creating intrusive thoughts until the loop is closed.
+
+**Application to this course:**
+- **Deliberate interruption:** Every lesson ends with an unfinished element — a pending question, a delayed solution, or a teaser for the next step. This "cognitive cliffhanger" drives the student to open the next lesson to relieve the tension.
+- **Curiosity Loops (4-step pattern):**
+  1. **Immediate Initiation:** Open the loop in the first 3-5 seconds (hook sentence or page title)
+  2. **Strategic Delay:** Withhold the full resolution until later in the lesson or the next lesson
+  3. **Continuous Chaining:** As one loop closes, immediately open another — creating a psychological slip-and-slide that draws the reader forward without conscious effort
+  4. **Final Satisfaction:** At module end, all major loops must be emphatically closed to provide a profound sense of completion
+
+> **Example:** Lesson 2 ends with: "Next, you'll learn the outreach technique that turned a 3% reply rate into 30% — and it's not what you think." The student's brain cannot let this go. They open Lesson 3 to close the loop.
+
+### 4.5 Progress Visibility
+
+Always show progress as "X of Y lessons done, Z concrete results achieved" rather than % completion.
+
+**Current (gap):** No progress visibility mechanism exists. The student reads chapters linearly with no tracking.
+
+**Requirement:**
+- Module-level: "You have completed 4 of 5 Module 1 lessons. Results so far: hypothesis sentence, landing page, Stripe link, conversion data."
+- Course-level: "You have completed 12 of 22 core lessons. 4 of 6 artifacts built."
+- Implementation: can be static text at the top of each lesson page (updated by the creator), not requiring dynamic tracking.
+
+### 4.6 Language
+
+Direct, friendly, non-academic. No jargon unless absolutely necessary, and then defined in one line.
+
+**Current (correct):** The voice guide (90.11) already enforces this. The course uses plain English, glosses all technical terms, and avoids academic language. ✓
+
+**Additional constraint:** The Nielsen Norman Group found that eliminating boastful, subjective "marketese" and exaggerated claims improved usability and comprehension by 27%. Students did not have to waste cognitive resources filtering out hyperbole to find the underlying facts. The JT voice guide already bans promotional language; this research confirms the rationale.
+
+### 4.7 Frictionless Navigation
+
+Same structure and layout for every lesson. Zero guessing where to find "Do this now" or "What you'll get."
+
+**Current (partial):** Chapter structure is consistent (orientation → input/output → opener → body → what to do → further reading) but the micro-learning template (sections 2.1-2.8) is not yet implemented.
+
+**Requirement:** After migration to the 8-part template, every lesson uses identical structure. The student always knows: section 1 is the hook, section 5 is the action, section 6 is error recovery, section 7 is the check.
+
+### 4.8 No Heavy Assessments
+
+Replace quizzes with "can you perform this exact action?" checks and simple self-verification.
+
+> "If you see [X] on your screen, you're done."
+
+**Current (partial):** Success checks exist implicitly in some chapters ("the PASS bar: ≥14/20") but are not standardized.
+
+**Requirement:** Every lesson's "Do this now" section (2.5) must include an explicit success check as the final step.
+
+---
+
+## 5. Elements Creators Must Include (Content Spec)
+
+### 5.1 At Course Level
+
+**One-page "Quickstart":**
+- Problem statement: 2-3 lines describing the pain in the learner's language
+- Promise: single sentence, measurable result and time expectation
+- Minimal path: list of modules and core lessons only (for those with very little time)
+- "Start here" button routing to Lesson 1.1
+
+**"What not to learn" section:**
+- Explicitly states what topics are intentionally excluded to save time
+- Example: "We do not cover: how to code, how to hire a CTO, how to raise venture capital, how to manage a 20-person engineering team. You don't need them for the promised result."
+
+**FAQ / self-help page:**
+- 10-15 short Q&A focused on typical blockers and common misunderstandings
+- Enables learners to progress without external help
+- Examples: "What if my Stripe account takes 3+ days to verify?" "What if I can't find 10 people to interview?" "What if all my Mom Test scores are below 7?"
+
+**Current (gap):** None of these three elements exist.
+
+### 5.2 Per Lesson
+
+- Fill the standard 8-part lesson template exactly (hook, outcome, concept, visual, steps, error recovery, reflection, bridge)
+- Use realistic examples (avoid synthetic or toy examples)
+- Include at least: 1 concrete example of "good" result + 1 example of a typical mistake and how to fix it
+
+#### 5.2.1 Sam's assumed toolset (added 2026-06-11)
+
+Before any course lesson, Sam is assumed to have:
+
+- A **web browser** (Chrome, Safari, Edge, or Firefox — any modern one). Lessons that name keyboard shortcuts cover all four.
+- A **personal email account** (Gmail or equivalent) for service signups.
+- A **smartphone** for testing mobile responsiveness when relevant.
+- **One AI chat tool** of his choice — ChatGPT, Claude, or Gemini (any free tier). This is the corrected Sam profile assumption per `feedback_course_icp_sam_profile.md` ("AI-augmented at every step"). Lessons may prompt Sam to use AI for: image generation (Lesson 1.2a hero image), regenerate-with-better-prompt loops (Mixo/Lovable workflows), interview rehearsal personas (Lesson 2.2), code review (Lesson 4.3), channel mapping (Lesson 5.2). The lesson should NAME 2-3 tool options ("ChatGPT, Claude, or Gemini") so Sam isn't forced into one vendor.
+
+Sam is NOT assumed to have:
+
+- A paid software subscription (every tool the course recommends has a free tier).
+- A custom domain (Mixo / Lovable / Carrd free-tier subdomains are sufficient for the entire smoke-test → MVP → first-customer arc).
+- A credit card on file (Stripe and ad-platform setup are taught when needed; smoke-test lessons explicitly avoid requiring one).
+- Existing accounts on Notion, Figma, GitHub, Slack, or any developer/PM tool (lessons that reference these provide an inline signup hint).
+
+**Implication for lesson authors:** before writing a step that says "open [tool] and do X," verify the tool is either (a) on Sam's assumed-toolset list above, or (b) explicitly introduced in the same lesson with a free-tier signup hint. Never assume Sam already has the tool just because it's "obvious" to a developer/PM.
+
+### 5.3 Micro-Copy Constraints
+
+**Sentences:** Mostly short (under 20 words), active voice.
+**Instructions:** Avoid multi-step instructions in one sentence; always split into separate numbered steps.
+**Paragraphs:** No more than one idea per paragraph.
+
+**Current (partial):** The voice guide (90.11) enforces conversational, direct language but does not enforce the <20-words-per-sentence micro-copy constraint.
+
+**First-occurrence linking rule:** Every externally-referenced service, tool, or platform must be linked on its FIRST occurrence on the page. Subsequent mentions do not need links. A reader who encounters "Reddit" for the first time on a lesson page must be able to click through immediately — not scroll down hoping for a link later.
+
+| ❌ Delayed or missing link | ✅ First-occurrence link |
+|---|---|
+| First mention: "find a real quote from Reddit or G2 reviews" (no link). Later: no link at all. | First mention: "find a real quote from [Reddit](https://reddit.com) or [G2 reviews](https://g2.com)" |
+
+This applies to: AI tools (ChatGPT, Claude, Gemini), research platforms (Reddit, G2, Quora), page builders (Mixo, Carrd, Manus AI, Durable), analytics (GA4, Clarity, Meta Pixel), payment processors (Stripe), ad platforms (Meta Ads, Google Ads, LinkedIn Ads, Reddit Ads), and any other external service the student must visit.
+
+**Exception:** Extremely well-known general web services (Google, Gmail, YouTube) do not require links unless used in a specific product context (e.g., "Google Ads" is linked; "Google" as a search engine is not).
+
+**NN/g Scanning Patterns:** Nielsen Norman Group eyetracking research (25+ years of studies) demonstrates that 79% of users scan digital text rather than reading word-for-word. Only 16% attempt linear reading. Key patterns:
+- **F-pattern:** Users read the top horizontal line, scan down the left margin, read a shorter horizontal line, then scan vertically — entirely ignoring the right side of the screen
+- **Lawn-mower pattern:** Eyes sweep methodically side to side across distinct visual blocks
+- **Pinball pattern:** Gaze bounces erratically between highly structured visual elements
+
+**Text formatting rules derived from NN/g research:**
+1. **Inverted Pyramid Architecture:** Start with the conclusion and most critical actionable advice at the absolute top. If the user stops scanning after 3 seconds, they must still walk away with the primary behavioral directive.
+2. **Meaningful Subheadings:** Use literal, descriptive subheadings (not "clever" or cryptic). The user must understand the section's contents in a fraction of a second from the heading alone.
+3. **Highlighted Keywords:** Bold important concepts and actionable steps to catch the scanner's attention. **Critical constraint: bolding must not exceed 20-30% of total text.** If overused, it loses emphasis and creates visual clutter that hinders reading. The current voice guide already enforces this as the "Christmas tree" rule.
+4. **Bulleted Lists:** Break up dense paragraphs to provide the eye with a clear, comfortable vertical path.
+5. **One Idea Per Paragraph:** Secondary ideas in the same paragraph will almost certainly be skipped by the scanning user.
+6. **Objective Tone:** Eliminate boastful, subjective "marketese" and exaggerated claims. NN/g found this improves usability by 27% (the same finding that underpins the voice guide's ban on promotional language).
+
+---
+
+## 6. Motivation, Stickiness, and Shareability
+
+### 6.1 Emotional Acknowledgment
+
+Each module intro acknowledges the learner's constraints:
+
+> "You're busy and probably tired of this problem. This module focuses only on what moves the needle now."
+
+**Current (partial):** The course has strong emotional honesty (Ch 5.4: "Asking your customer for money feels like joining the side that hurt you") but these moments are scattered in chapter bodies, not standardized at module intros.
+
+**Requirement:** Every module's first lesson must include an emotional acknowledgment in the hook or concept block.
+
+### 6.2 Story of Progress
+
+Use small narrative touches to reinforce advancement without fluff:
+
+> "At this point, you're ahead of most people who never even configure X."
+
+**Current (gap):** No progress narrative exists across the course. Each chapter is a self-contained unit.
+
+**Requirement:** Add one progress-reinforcement sentence per module in the bridge from the last lesson.
+
+### 6.3 Built-In Celebrations
+
+At the end of each module, add a 2-3 sentence "win recap" plus a share suggestion:
+
+> "You now have [artifact]. If this module saved you at least an hour, you probably know someone else wrestling with this — send them this free course page."
+
+**Current (gap):** No win recaps or share prompts exist.
+
+### 6.4 Viral Loop Architecture
+
+To scale without marketing spend, the course must contain an engineered viral loop — a self-fulfilling process where existing students are incentivized to share, bringing in new students who are in turn incentivized to share.
+
+The most successful model (2024-2026) is the **milestone referral model**, proven by Morning Brew and The Hustle:
+
+1. **Personalized tracking link:** Every student gets a unique referral URL (generated client-side on first visit, stored in localStorage), persistently displayed at the bottom of every lesson
+2. **Frictionless sharing:** Pre-written, one-click sharing buttons for social media and email — the system auto-generates an optimized message ("I'm taking this free course on validating startup ideas. Each lesson takes 5-10 minutes. Join me: [unique link]")
+3. **Tiered milestone rewards:**
+   - 1 referral → Bonus resource (checklist, cheat sheet, printable template)
+   - 3 referrals → Exclusive content (video breakdown, Q&A archive, discount code)
+   - 10+ referrals → High-value reward (1-on-1 consultation, branded merchandise, free premium course access)
+4. **Gamified CTAs:** Use open loops and progress language — "You're only 2 referrals away from unlocking the Ultimate Blueprint!" — not generic "Share this course"
+5. **Superfan identification:** Actively identify students who complete every lesson and the full sequence. Invite them to a higher-tier affiliate program with cash commissions (20-40% of sales).
+
+**Implementation:** Requires referral software (Viral Loops, Partnero) connected to the course platform via API/Zapier. This automates link injection, tracking, and reward delivery.
+
+### 6.5 Social Proof Prompts
+
+Summon referrals practically, not as a plea:
+
+> "If this module saved you at least an hour, you probably know someone else wrestling with this — send them this free course page."
+
+**Current (gap):** No referral prompts exist.
+
+### 6.6 Completion Reward
+
+A final "toolkit" or checklist the student can keep using after the course — ideally a printable one-pager or compact text template.
+
+**Current (partial):** The 6 Founder OS artifacts exist but are scattered across chapters, not bundled as a final completion reward.
+
+**Requirement:** Bundle all 6 artifacts into a single downloadable "Founder OS Completion Toolkit" referenced from the final lesson.
+
+---
+
+## 7. Quality Assurance Checklist (for Course Owner)
+
+Before accepting a module or lesson from a creator, run this checklist:
+
+### Per Lesson
+
+- [ ] Does the lesson have exactly one clearly stated outcome? (Section 2.2)
+- [ ] Does it end with an observable success check? (Section 2.5, final step)
+- [ ] Total reading: ≤10 minutes (~400-600 words)?
+- [ ] Total implementation: ≤15 minutes for an average non-professional?
+- [ ] Is there any theory/content that does not directly support a concrete action?
+  - If yes → must be removed or moved to an optional appendix.
+- [ ] Can a learner with almost no interest but strong problem-pain:
+  - See a tangible benefit within the first 10 minutes?
+  - Progress without asking anyone for help, using only the course FAQ and the instructions?
+- [ ] Is the 8-part template followed exactly and in order? (Hook → Outcome → Concept → Visual → Do This Now → Error Anticipation → Micro-Reflection → Bridge) — visual is optional but all other sections are mandatory
+
+### Per Module
+
+- [ ] Does the module have exactly one milestone outcome?
+- [ ] Are entry conditions and success definitions clear?
+- [ ] Is the module map present with core/optional tags?
+- [ ] Does the core path alone produce the milestone outcome?
+- [ ] Is there an emotional acknowledgment?
+- [ ] Is there a win recap + share prompt at module end?
+
+### Per Course
+
+- [ ] Does the Quickstart page exist?
+- [ ] Does the "What not to learn" section exist?
+- [ ] Does the FAQ page exist with 10-15 Q&A?
+- [ ] When skim-reading the course, does the learner always know:
+  - "What do I get from this?"
+  - "What exactly do I do now?"
+  - "How do I know I'm done and it worked?"
+- [ ] Is the navigation and structure identical across all lessons?
+- [ ] Are tables ≤3 columns and mobile-friendly?
+- [ ] Do all pages pass the 375px viewport test?
+
+---
+
+## 8. Current State → Target State Migration Guide
+
+### 8.1 What to Preserve
+
+The current course has several design achievements that must survive migration:
+
+1. **Voice:** The JT voice (90.11) — direct, opinionated, plain English, specific numbers, emotional honesty. This is the course's strongest asset.
+2. **Artifact chain:** Input → Output handoffs between chapters. The 6-artifact Founder OS concept. These compound and give the student a sense of progress.
+3. **Emotional arc:** Recognition → confidence → endurance → clarity → accomplishment → courage. The trust curve from 40.06.
+4. **Failure-mode catalog:** Every chapter names a specific, expensive failure the student can recognize. This earns trust.
+5. **Numbers for every decision:** PASS bars, conversion thresholds, reply-rate bands. The student never has to guess.
+6. **Jargon glosses:** First-use definitions for every technical term. Critical for Sam.
+7. **Case studies:** Tomas & Mia examples that carry through all 5 modules. **Updated 2026-06-08 (revised):** case studies live at the END OF EACH MODULE as a single coherent walkthrough page (slug: `module-N-walkthrough-`), ONE founder per module picked by module-level ICP-fit per §2.7. NOT inside individual lessons. Earlier patterns (per-lesson case studies; dedicated case-study micro-lesson with both founders) are both superseded. Each lesson body stays tightly focused on its single algorithm; the walkthrough page tells the full module narrative.
+
+### 8.2 What to Change
+
+> **Note on Mermaid diagrams:** Current flowcharts (decision trees, build phases, pipeline diagrams) must be simplified to single-concept illustrations or removed. Each visual in the micro-lesson format illustrates ONE concept (§2.4), not the full chapter argument. Multi-node Mermaid flowcharts (5+ nodes) become multiple simple diagrams across lessons or are replaced with 2-3 sentence prose.
+
+> **Note on glossary policy:** The current course glosses 10-15 terms per chapter (course-chapter-pipeline.md §7). The micro-learning §2.3 caps at 3 new terms per lesson. Excess terms move to a per-module "Terms you'll need" sidebar referenced from the lesson. The 3-term cap takes precedence for micro-lessons; the generous glossing policy remains for long-form companion/reference pages.
+
+| Current | Target |
+|---|---|
+| 18 long-form chapters (2,000-4,500 words each) | 20-25 micro-lessons (400-600 words each) |
+| Narrative openers (2-5 paragraphs) | 1-3 sentence hooks |
+| Multi-section body with interleaved concepts | Single-concept block (150-300 words) |
+| "What to do tomorrow" at chapter end | "Do this now" with 3-7 imperative steps in every lesson |
+| No reflection mechanism | 60-90 second micro-reflection in every lesson |
+| No progress visibility | "X of Y lessons done, Z results achieved" |
+| No core/optional tagging | Every lesson tagged [CORE] or [OPTIONAL] |
+| No Quickstart, FAQ, or "What not to learn" | All three created |
+| No win recaps or share prompts | Added per module |
+| Scattered artifacts | Bundled into final Completion Toolkit |
+
+### 8.3 Migration Approach
+
+**Option A: Full migration (recommended for new course instances)**
+Rewrite all 18 chapters as 20-25 micro-lessons following the 8-part template. Deliverable: entirely new lesson files, each 400-600 words, with the 8-part template. This is ~2-4 weeks of focused work and produces the ideal format for Sam. Existing long-form chapters become companion reference pages.
+
+**Option B: Dual-format (maintenance-heavy, not recommended)**
+Keep the current long-form chapters AND create a parallel "Quick Path" with anchor links. This creates two versions of the same content with ongoing sync burden. Use only if the long-form chapters have significant SEO value that would be lost in migration.
+
+**Option C: Hybrid / pragmatic first step (recommended for immediate shipping)**
+Apply targeted improvements to the existing long-form chapters WITHOUT rewriting them as micro-lessons. Deliverable: 6 surgical fixes from 40.07 + 3 new pages (Quickstart, FAQ, "What not to learn"). This does NOT achieve the 400-600 word micro-lesson format — it improves the current long-form experience. ~2-3 days of work.
+
+### 8.4 Recommended Path
+
+**Option C is complete** (shipped 2026-06-07). Quickstart, FAQ, and "What not to learn" are live. The 6 Sam recommendations from 40.07 are applied. The v1 long-form chapters are now the starting point for the micro-lesson migration.
+
+**Next: Option A as a phased rollout** (see §8.5 below). The micro-learning format is the north star. The TASK-TRACKER "Course Migration Schedule" section has the detailed phase-by-phase plan.
+
+---
+
+### 8.5 Web Delivery Roadmap
+
+This section describes how the course is delivered as a **web-based, self-paced, asynchronous course** on the Hugo static site — the current delivery mechanism. The detailed phase schedule lives in `TASK-TRACKER.md` "Course Migration Schedule"; this section distills the delivery architecture.
+
+#### Delivery Infrastructure
+
+| Component | Implementation |
+|---|---|
+| **Platform** | Hugo static site generator |
+| **Content location** | `content/course/tech-for-non-technical-founders-2026/` |
+| **Landing page** | `_index.md` — course overview, module map, fast-path routing |
+| **Lesson pages** | One Hugo page bundle per lesson (`index.md` + images) |
+| **Course frame** | Every lesson carries a top callout (Module X · Lesson N of M) + bottom course-nav table |
+| **Navigation** | Hugo `course-prev-next.html` partial auto-renders prev/next from `data/course_sequence.yaml` |
+| **Chapter order** | `data/course_sequence.yaml` (single source of truth) |
+| **Validation** | `bin/validate-course` + `bin/hugo-build` — pre-flight checks on every change |
+
+#### Student Flow (Web)
+
+1. **Landing page** — student arrives, reads the promise, sees module map. Two routing options: "New founder, no team" → Chapter 1.1, or "Team already failing" → rescue chapters.
+2. **Quickstart** — one-page minimal path for time-starved students: core lessons only, gate thresholds, start button.
+3. **Lesson pages** — student reads hook → concept → does the steps → checks success → reflects → clicks bridge to next lesson. Repeat.
+4. **Module gates** — at module end: win recap, progress visibility, share prompt, bridge to next module.
+5. **FAQ** — 15 Q&A for common blockers (Stripe verification, Mom Test scores <7, builder paralysis, asking for money).
+6. **Completion** — final lesson bundles all 6 artifacts into "Founder OS Completion Toolkit." Viral share prompt.
+
+#### Current State & Phased Rollout
+
+> **Phase naming note:** This document uses "Option C" for the completed surgical-improvements phase. The TASK-TRACKER's "Course Migration Schedule" uses a different numbering: Phase 0 = mechanical quick wins (outcome sentences, success checks, Stuck? boxes on remaining chapters — not yet started, ~2-3 hours), Phase 1 = pilot, Phase 2 = module-by-module, Phase 3 = polish. The phases below correspond to the TASK-TRACKER schedule; the mechanical quick wins (TASK-TRACKER Phase 0) can run in parallel with the Pilot.
+
+**🟢 Option C — COMPLETE (2026-06-07)**
+
+| Deliverable | Status |
+|---|---|
+| 18 v1 long-form chapters live at `/course/` | ✅ Shipped |
+| Landing page with module map + fast-path routing | ✅ Shipped |
+| Quickstart page | ✅ Shipped |
+| FAQ page (15 Q&A) | ✅ Shipped |
+| "What not to learn" section (7 exclusions) | ✅ Shipped |
+| 6 Sam-first surgical fixes from 40.07 | ✅ Shipped |
+
+All 21 v1 chapters scored 1.0-1.5/8 against the 8-part template (per 40.08 gap report). The course is functional and live but not yet in micro-learning format.
+
+**v1/v2 coexistence during migration:** Existing v1 long-form chapters remain live while micro-lessons are written. As each module's micro-lessons ship, the corresponding v1 long-form chapters are removed from the course spine and converted to companion reference pages (linked from the micro-lesson as "Deeper reference" sidebars). The landing page module map is updated after each module cutover. At no point does the student see both formats for the same content.
+
+**🟡 Phase 1 — Pilot Micro-Lesson Rewrite (~4 hours)**
+
+| Step | Action |
+|---|---|
+| 1.1 | Select pilot chapter (recommended: 1.2a Smoke Test Build, or 2.1 Mom Test) |
+| 1.2 | Split chapter into 2-3 micro-lessons at concept boundaries |
+| 1.3 | Write all 8 parts of the template for each micro-lesson |
+| 1.4 | Hugo build + mobile viewport check + validate-course |
+| 1.5 | Code review + polish |
+| 1.6 | Document real time-per-lesson, template refinements, surprises |
+
+**Gate:** One chapter fully migrated. Real time-per-lesson measured. Only then proceed to Phase 2.
+
+**📋 Phase 2 — Module-by-Module Full Migration (~2-4 weeks)**
+
+Rewrite all 18 chapters as 20-25 micro-lessons, module by module. Each module is independently shippable — Module 1 can go live while Module 2 is still being written.
+
+| Module | Chapters | → Micro-lessons | Est. time | Complexity |
+|---|---|---|---|---|
+| M1: Hypothesis & Smoke Test | 4 | ~5 | ~3-4 days | Low — hypothesis, landing page, Stripe link |
+| M2: Validate the Problem | 5 | ~6 | ~4-5 days | Medium — interview scripts, outreach, prototype |
+| M3: Design from Evidence | 2 | ~3 | ~2-3 days | Low — product brief, outcomes check |
+| M4: Build It Yourself | 5 | ~6 | ~4-5 days | **High** — Supabase RLS, Stripe webhooks, 12 rules |
+| M5: First Paying Customer | 5 | ~6 | ~4-5 days | **High** — DPA template, cold outreach, PMF test |
+
+**Per-module exit gates:**
+- All lessons follow 8-part template ✓
+- Hugo build + validate-course ✓
+- Mobile viewport (375px) ✓
+- Bridge chain integrity verified ✓
+- Core path produces module milestone without optional lessons ✓
+
+**📋 Phase 3 — Cross-Cutting Polish (~2-3 days)**
+
+| Step | Action |
+|---|---|
+| 3.1 | Verify every bridge names a specific dependency |
+| 3.2 | Verify core path produces all 6 artifacts |
+| 3.3 | Verify emotional arc (40.06 trust curve) preserved |
+| 3.4 | Bundle all 6 artifacts into Completion Toolkit reference |
+| 3.5 | Full mobile viewport audit (all lessons at 375px) |
+| 3.6 | Full Hugo build + validate-course + link checker |
+| 3.7 | Update landing page module maps for new lesson structure |
+| 3.8 | Update Quickstart for micro-lesson path |
+| 3.9 | Final code review |
+
+**Phase 3 exit gate:** All lessons pass QA checklist (§7). Emotional arc preserved. Core path produces all artifacts.
+
+#### Post-Migration Delivery
+
+After Phase 3, the course is fully in micro-learning format on the web. Ongoing delivery work:
+
+1. **Distribution** — Promote via JT newsletter, LinkedIn (Paul Keen voice), Reddit r/startups, Twitter founder threads, Facebook groups. See `distribution-prep.md` for channel-specific share copy.
+2. **Viral sharing** — Every lesson carries social proof prompts. Milestone referral program (Phase 3+ consideration — §6.4).
+3. **SEO** — Page-1 rankings on founder-focused keywords ("validate startup idea," "first paying customer," "non-technical founder course").
+4. **Analytics** — Track course completion signals (readers who hit ≥3 modules), email captures from artifact downloads, share velocity.
+5. **Maintenance** — Quarterly AI-era post refresh (Q1 2027 first trigger). Date-stamp every AI-era post.
+6. **Future: push-based companion** — Email sequence version (5-7 day intensive per module) considered as a future companion channel. See §1.6 note. Not in current scope.
+
+#### Risk Mitigation
+
+| Risk | Mitigation |
+|---|---|
+| Phase 2 stretches past 4 weeks | Ship module-by-module. Each module is independently shippable. Never block release on the last module. |
+| Technical chapters (M4) can't compress to 300 words | Allow 400-word concept blocks with documented exceptions. Spirit is "no bloat," not strict 300-word ceiling. |
+| Bridges break when upstream lesson changes | Phase 3 bridge audit catches these. Expect bridges to need adjustment after full chain is visible. |
+| Pilot diverges from Appendix A pattern | Appendix A is the canonical pattern. Update this doc (with approval) if pilot discovers needed refinements. |
+| Mobile viewport issues discovered late | Test each module's lessons on mobile at module exit gate. Don't defer all mobile testing to Phase 3. |
+
+**Total estimated effort: ~3-5 weeks** from Phase 1 through Phase 3. The detailed schedule with per-step timeboxes is in `TASK-TRACKER.md` "Course Migration Schedule."
+
+---
+
+## 9. Integration with Existing Project Docs
+
+### 9.1 Relationship to Other Docs
+
+| Doc | Relationship |
+|---|---|
+| `GOAL-AT-A-GLANCE.md` | This doc refines the delivery principles into concrete spec. GOAL-AT-A-GLANCE is the executive summary; this doc is the operator manual. |
+| `course-chapter-pipeline.md` | The pipeline doc describes how to write chapters in the CURRENT format. This doc describes the TARGET format. During migration, both apply — the pipeline for existing chapters, this doc for new micro-lessons. |
+| `90.11-voice-guide.md` | Voice rules remain 100% in effect. The micro-copy constraints (Section 5.3) are additive, not replacement. |
+| `90.10-icp-primary-website-target.md` | Sam is the course ICP. Alex (burned founder) is the website ICP. This doc's requirements target Sam exclusively. |
+| `40.06-sam-customer-journey-report.md` | The trust curve, emotional arcs, and friction points from 40.06 inform lesson sequencing and emotional acknowledgment placement. |
+| `40.07-sam-experience-improvement-report.md` | The 6 recommendations in 40.07 are the Option C migration path. This doc provides the full north-star spec. |
+| `TASK-TRACKER.md` | The 40.07 recommendations are already tracked. New items from this doc (Quickstart, FAQ, "What not to learn") should be added as P2 items. |
+
+### 9.2 Authority
+
+This document is the **canonical requirements spec** for course format design. When a creator asks "how should I structure this lesson?" — the answer is in Section 2, not in the pipeline doc. The pipeline doc (course-chapter-pipeline.md) remains authoritative for the current long-form format until migration is complete.
+
+---
+
+## 10. References
+
+**Instructional Design Frameworks:**
+- [Cathy Moore — Action Mapping](https://blog.cathy-moore.com/action-mapping-a-visual-approach-to-training-design/) — Backward design, prioritize behaviors over information, excise "nice to know"
+- [InstructionalDesign.org — Minimalism (J. Carroll)](https://www.instructionaldesign.org/theories/minimalism/) — Error recovery, self-contained units, minimal reading
+- [BJ Fogg's Behavior Model](https://behaviordesign.stanford.edu/resources/fogg-behavior-model) — B=MAP: Motivation + Ability + Prompt
+- [Tiny Habits by BJ Fogg](https://brain.health/tiny-habits/) — Anchor new behaviors to existing routines
+
+**Cognitive Psychology:**
+- [Zeigarnik Effect — Wikipedia](https://en.wikipedia.org/wiki/Zeigarnik_effect) — Unfinished tasks create cognitive tension driving completion
+- [Dual Coding Theory — Wikipedia](https://en.wikipedia.org/wiki/Dual-coding_theory) — Visual + verbal channels expand working memory
+- [Dual Coding and Cognitive Load — The Learning Scientists](https://www.learningscientists.org/blog/2025/5/29) — Practical application of dual coding
+
+**Reading Behavior & Usability:**
+- [NN/g — How Users Read on the Web](https://www.nngroup.com/articles/how-users-read-on-the-web/) — F-pattern, 79% scan vs 16% read, inverted pyramid, bolding discipline
+- [NN/g — F-Shaped Pattern for Reading Web Content](https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content-discovered/) — Original F-pattern eyetracking research
+
+**Microlearning & Delivery:**
+- [Engageli — 20 Microlearning Statistics 2026](https://www.engageli.com/blog/20-microlearning-statistics-in-2026) — 80-90% completion rates, 50% cheaper development, 300% faster deployment
+
+**Course Design:**
+- [onlinetrainingconcepts.com](https://onlinetrainingconcepts.com/designing-effective-online-training/how-to-design-an-effective-online-training-course/) — Micro-learning structure + lesson template design
+- [teaching-resources.delta.ncsu.edu](https://teaching-resources.delta.ncsu.edu/online-course-best-practices/) — Online course best practices, mobile-friendly design, progress visibility
+- [kpcrossacademy.ua.edu](https://kpcrossacademy.ua.edu/engaging-online-course-design/) — Visual aids + engagement design
+- [resilienteducator.com](https://resilienteducator.com/classroom-resources/short-attention-span-class-structure/) — Short attention span class structure + micro-reflection
+- [commlabindia.com](https://www.commlabindia.com/blog/online-learning-formats-simple-guide) — Asynchronous self-paced format guide
+
+**Viral Growth:**
+- [Viral Loops — Referral Program Architecture](https://viral-loops.com/blog/newsletter-referral-program/) — Milestone referral model architecture
+- [Viral Loops — Online Course Referral Program](https://viral-loops.com/blog/online-course-referral-program/) — Superfan identification + affiliate integration
+- [ViralRef — The Viral Loop](https://viralref.com/blog/the-viral-loop-how-every-customer-becomes-your-marketer) — Viral loop mechanics for course creators
+
+**Voice & AI Detection:**
+- [Wikipedia: Signs of AI writing](https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing) — AI-pattern detection (already enforced via voice guide 90.11)
+- [Autofaceless — Online Course Creation Statistics 2026](https://autofaceless.ai/blog/online-course-creation-statistics-2026) — Market size, revenue, completion rate data
+
+**Visual Design:**
+- [eLearning Industry — Beyond Text: Using Infographics](https://elearningindustry.com/beyond-text-using-infographics-to-simplify-complex-concepts) — Visual integration for complex concepts
+- [Venngage — Infographic Size Guide](https://venngage.com/blog/infographic-size-guide-web-social-print/) — Mobile-first visual dimensions
+
+---
+
+## Appendix A: Complete Micro-Lesson Example
+
+This is a worked example of the 8-part template applied to course content. It rewrites the opening of Module 1, Lesson 1.1 ("Form Your Founding Hypothesis") in the target micro-learning format.
+
+### Lesson 1.1 — Write Your Founding Hypothesis Sentence
+
+You have an idea. You've told five people about it. They all said "that sounds great" — which told you nothing. In this lesson you'll turn that idea into a single sentence you can actually test.
+
+After this lesson you will be able to: **write a one-sentence Founding Hypothesis with five specific blanks filled in.**
+
+A Founding Hypothesis is a Mad Libs sentence:
+
+> *"If we help [customer] solve [problem] with [approach], they'll choose it over [competition] because [differentiation]."*
+
+Five blanks. One sentence. No vagueness allowed.
+
+**Why this works:** A vague sentence produces polite nods. A specific sentence produces pushback — and pushback is the signal. Example:
+
+- ❌ *"We help small businesses save time with automation."* — Nobody can argue with this. Nobody can validate it either.
+- ✅ *"If we help solo chiropractors solve insurance-claim resubmission with a one-click resubmit, they pick it over billing services that take 14 days and charge 8% of recovered claims."* — A chiropractor will either say "I dealt with exactly this last Tuesday" or "that's not my problem." Both are useful.
+
+**The blanks map to concrete things you already know or can research:**
+- **[customer]**: the specific person, not "small businesses" — "solo chiropractors"
+- **[problem]**: what they tried and failed at in the last 30 days
+- **[approach]**: the shape of your solution — "one-click resubmit" not "AI-powered workflow"
+- **[competition]**: what they currently use (a billing service, a spreadsheet, a person)
+- **[differentiation]**: why they'd switch — faster, cheaper, or both, with numbers
+
+**Common mistake:** Filling blanks with market-research language instead of customer language. If your chiropractor says "I spent 40 minutes re-entering claim codes from a PDF," your [problem] blank says "manual claim-code re-entry from PDFs" — not "streamlining healthcare administration workflows."
+
+![5 blanks of the Mad Libs hypothesis sentence with a filled example below](hypothesis-mad-libs.svg)
+
+1. Open a blank note. Write the Mad Libs frame at the top: *"If we help [customer] solve [problem] with [approach], they'll choose it over [competition] because [differentiation]."*
+2. Fill the [customer] blank with one specific role + industry. Not "small business owners" — "solo chiropractors" or "pre-seed B2B SaaS founders."
+3. Fill the [problem] blank with one thing that person tried and failed at in the last 30 days. Use their words, not yours.
+4. Fill the [competition] blank with what they currently use. If it's a spreadsheet, write "manual spreadsheet reconciliation." If it's a $200/month tool they hate, name the tool.
+5. Read your sentence aloud to yourself. **Success check:** Can a stranger picture the product from the sentence alone? If not, your blanks are too vague. Tighten the [problem] or [differentiation] blank until the answer is yes.
+
+**If this fails:** Your sentence sounds generic even after tightening. **Why:** You're writing in market-research language instead of customer language. **Fix:** Find a verbatim quote from a real person complaining about this problem (Reddit, G2 reviews, or a conversation you had). Replace your [problem] blank with their exact words. If you don't have a quote yet, leave the [problem] blank as a placeholder and complete the next lesson — you'll fill it after Module 2 interviews.
+
+- Write one sentence: what is the weakest blank in your hypothesis right now?
+- Save your hypothesis sentence. You'll use it in the next lesson to stress-test it against 4 lenses.
+
+Next: you'll score your hypothesis against 4 lenses (Customer, Pragmatic, Growth, Money) and find out whether it passes the ≥14/20 bar — or needs another draft.
+
+---
+
+*Built by Buffy (AI agent) as part of the 2605 Tech for Non-Technical Founders project architecture.*
diff --git a/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.04-m1-assessment-rubric.md b/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.04-m1-assessment-rubric.md
new file mode 100644
index 000000000..cae2122e8
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.04-m1-assessment-rubric.md
@@ -0,0 +1,126 @@
+# Module 1 — Hypothesis & Smoke Test: Assessment Rubric
+
+**Purpose**: Self-assessment rubric for M1 micro-lessons (5 lessons, 708-896w each).
+Matches quality gates from 30.02 ADR and 30.03 course format spec.
+Use after completing each lesson's success check.
+
+**Companion references**: Deep methodology lives in 3 reference pages under
+`reference/` — hypothesis-sprint-full, smoke-test-channel-guide, stripe-price-test-full.
+Micro-lessons link to them as "Deeper reference."
+
+---
+
+## Per-Lesson Rubric
+
+### Lesson 1.1: Form Your Founding Hypothesis (708w)
+
+**Goal**: Write a Founding Hypothesis scored ≥14/20 across four lenses — one sentence,
+five specific blanks, falsifiable in five interviews.
+
+| Criteria | Excellent (4) | Good (3) | Needs Work (2) |
+|---|---|---|---|
+| **Customer specificity** | Names one role + industry ("solo chiropractors") | Names a role but vague industry ("small business owners") | "Small businesses" or "people who..." |
+| **Problem clarity** | Uses customer's verbatim words from Reddit/G2/interview | Describes real problem in your own words | "Streamlining workflows" or market-research language |
+| **Approach concreteness** | Names the mechanism ("one-click resubmit") | Names the outcome ("faster resubmission") | "AI-powered solution" or vague approach |
+| **Differentiation** | Specific competitor named with why they'd switch | Names competitor category ("billing services") | "Better" or "cheaper" without specifics |
+| **Falsifiability** | A stranger can picture the product from the sentence alone | A stranger understands the problem but not the product | Nobody can tell what the product does |
+
+**Gate**: Magic Lenses ≥14/20 (or ≥11/15 pre-revenue). No individual lens below 2.
+**Deeper reference**: [Full 6-step Click sprint + AI prompts](/course/.../reference/hypothesis-sprint-full/)
+
+---
+
+### Lesson 1.2a: Build the Page (859w)
+
+**Goal**: Publish a smoke-test page from your hypothesis in under an hour, then
+run a one-stranger clarity test.
+
+| Criteria | Excellent (4) | Good (3) | Needs Work (2) |
+|---|---|---|---|
+| **Headline clarity** | Stranger names who it's for AND what it does in <3s | Stranger names one of two within 3s | Stranger can't name either |
+| **Headline format** | Names specific person + outcome ("Solo chiropractors: resubmit denied claims in 30s") | Names outcome but vague customer | Generic headline ("Smart Solutions") |
+| **CTA correctness** | "Get on the waitlist" + "Coming soon. Email reserves your spot at launch." footer | CTA present but no footer disclaimer | "Buy now" or CTA missing |
+| **Extras stripped** | No Pricing, FAQ, Testimonials, or "How it works" blocks | One leftover block | Multiple leftover distraction blocks |
+| **Hero image** | Customer pain-scenario image OR image deleted (headline carries page) | Relevant stock image | Product mockup of unbuilt product |
+
+**Gate**: URL live + one stranger passes the 3-second clarity test.
+
+---
+
+### Lesson 1.2b: Wire Tracking (896w)
+
+**Goal**: Install the right tracking for your ad channel — GA4 + Google Ads tag,
+or platform pixel + GA4, plus Clarity — and name the 3 conversion numbers.
+
+| Criteria | Excellent (4) | Good (3) | Needs Work (2) |
+|---|---|---|---|
+| **Channel-dependent choice** | Correct tracking path picked: Google Ads → GA4 (no separate pixel) OR Meta/LinkedIn/Reddit → platform pixel + GA4 | Right path picked but GA4 skipped | No tracking installed |
+| **GA4 installed** | Measurement ID in head-tag; Real-Time report shows test visit | GA4 property created but snippet not in head-tag | No GA4 |
+| **Ad-platform pixel** | Pixel snippet in head-tag for correct B2B/B2C channel; status "Active"/"Receiving data" | Pixel installed but wrong channel for ICP | No pixel |
+| **Clarity installed** | Own visit appears as session recording within 60s | Clarity installed but no recording yet | "No data yet" after 5+ min |
+| **Snippet placement** | All snippets in head-tag field (not body) | One in head, one misplaced | Both in body |
+
+**Gate**: Any one confirmation proves snippet landed — GA4 Real-Time report,
+pixel "Active," or Clarity recording.
+**Deeper reference**: [Full channel budgets + ad setup timing](/course/.../reference/smoke-test-channel-guide/)
+
+---
+
+### Lesson 1.2c: Run the Smoke Test (741w)
+
+**Goal**: Run 300 cold visitors against your page and make a go/iterate/kill
+decision from the conversion rate.
+
+| Criteria | Excellent (4) | Good (3) | Needs Work (2) |
+|---|---|---|---|
+| **Channel selection** | Channel matches ICP (B2C→Meta, B2B→LinkedIn/Google, dev→Reddit) | Channel works but suboptimal for ICP | Channel picked "because I use it" |
+| **Volume** | ≥300 visits before reading rate | 200-299 visits | <200 visits |
+| **Test discipline** | No mid-test optimizations (headline, bid, audience unchanged) | One minor adjustment | Multiple mid-test changes |
+| **Decision quality** | Decision matches the conversion band from the table | Decision correct but no second-channel verification for >20% | Ignores the conversion band ("feels right") |
+| **Second-channel verification** | For >20%: ran second channel (LinkedIn + Reddit divergence confirms targeting variable) | Aware of need but didn't run | Didn't verify |
+
+**Gate**: ≥300 visits + conversion rate read against go/iterate/kill table.
+**Deeper reference**: [Full channel budgets + ad account timing](/course/.../reference/smoke-test-channel-guide/)
+
+---
+
+### Lesson 1.3: Price Hypothesis (783w)
+
+**Goal**: Add a Stripe Payment Link and measure whether strangers will pay —
+not just leave an email.
+
+| Criteria | Excellent (4) | Good (3) | Needs Work (2) |
+|---|---|---|---|
+| **Stripe setup** | Payment Link live, live-mode verified, thank-you page working | Payment Link created but not verified | No Payment Link |
+| **Price format** | All 3 parts present: specific number + unit + framing ("Founding member — $49/month for life") | Number + unit, no framing | Just a number ("$49") |
+| **Button copy** | One pattern picked (outcome framing OR risk-reduction); no A/B test | Pattern picked but tempted to A/B test | Plain "Get access" button |
+| **Price anchor** | Price grounded in customer's current spend (what they pay today) | Price based on competitor research | Price pulled from "what feels right" |
+| **Click-vs-completion tracked** | Both click rate AND completion rate measured; divergence diagnosed | Only click rate tracked | Neither tracked |
+
+**Gate**: Stripe Payment Link live. Click-to-payment rate measured. Decision: advance (≥5%) / iterate (2-4%) / verify (10%+).
+**Deeper reference**: [Full Stripe setup + threshold bands + button copy patterns](/course/.../reference/stripe-price-test-full/)
+
+---
+
+## Module 1 Exit Rubric
+
+**Milestone outcome**: Founding Hypothesis + live landing page with tracking +
+conversion data + Stripe price signal. All 5 artifacts saved in Founder OS folder.
+
+| Criteria | Excellent (4) | Good (3) | Needs Work (2) |
+|---|---|---|---|
+| **All 5 lessons complete** | All success checks passed, all artifacts saved | 4 of 5 complete, one pending | 3 or fewer complete |
+| **Hypothesis passes Magic Lenses** | ≥14/20 | 11-13/20 (pre-revenue acceptable) | <11/20 |
+| **Smoke-test signal** | ≥6% email conversion OR ≥5% Stripe-click | 3-5% (iterate band — will iterate in M2) | <3% (kill/pivot — restart M1) |
+| **Artifact chain intact** | All 5 artifacts saved in Founder OS folder; inputs match outputs across lessons | 4 of 5 artifacts saved | Artifacts scattered or missing |
+| **Bridge ready for M2** | Landing page URL + conversion data + price signal saved; hypothesis tightened per data | Hypothesis not yet tightened | No hypothesis written |
+
+**M1 exit gate**: Hypothesis ≥14/20. Live landing page + tracking. Conversion signal ≥3%.
+Price signal measured. Founder OS folder contains all 5 lesson outputs. Ready for
+Module 2 interviews.
+
+---
+
+*Generated from 30.02 ADR quality gates + 30.03 course format spec.
+Updated 2026-06-11 to reflect compressed 8-part template micro-lessons (708-896w)
+with companion reference pages.*
diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.01-m1-m3-audit-2026-05-28.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.01-m1-m3-audit-2026-05-28.md
new file mode 100644
index 000000000..3c4497dde
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.01-m1-m3-audit-2026-05-28.md
@@ -0,0 +1,101 @@
+# M1-M3 Voice Regression Audit — 2026-05-28
+
+> **PERMANENT GATES**: The 6 banned patterns and 2 permanent gates documented below now live in `CLAUDE.md` and `docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md` as canonical rules. This file is the historical record of the audit that discovered them.
+
+**Created**: 2026-05-29
+**Project**: 2605-tech-for-non-technical-founders
+**Method**: 4-persona audit (M1-M3 chapters reviewed by multiple persona agents)
+**Source**: Findings extracted from `CLAUDE.md` §"Slop detector + shape-tell critic" (2026-05-28 additions block)
+**Status**: ✅ Findings recorded — sweep rules integrated into `CLAUDE.md` as permanent gates
+
+---
+
+## Why This Exists
+
+On 2026-05-28, a 4-persona M1-M3 audit caught voice regressions that the slop detector (≤25/100) had passed as clean. The patterns had been previously removed from the codebase but regressed under time pressure. This document preserves the findings as a project record and informs the permanent gate rules now living in `CLAUDE.md`.
+
+---
+
+## Patterns Caught by the Audit
+
+### 1. Slogany Reveal-Twist Flip
+
+Textbook AI-pattern: the sentence builds a false expectation, then reveals the opposite. Multiple variants found:
+
+- *"X hadn't been Y — Z had been"*
+- *"It's not about X. It's about Y."*
+- *"X wasn't Y — it was Z"*
+
+**Fix**: Use direct declarative sentences. State the finding without the dramatic reveal structure.
+
+### 2. Cost-Stacked Tri-List Opener
+
+Openers that front-load three cost dimensions in a single sentence:
+
+- *"$X-$Y in A, N B, one of M C"*
+
+**Fix**: Reads as a workshop slide, not narrative. Spread the cost dimensions across the opening paragraph.
+
+### 3. Cute Aphoristic Flourish Closer
+
+Closing lines that sound clever but add no information:
+
+- *"polite noise"*
+- *"the kind smile that costs you a year"*
+- *"the helpful answer is the trap"*
+- *"Everything else is your mom being nice"*
+
+**Fix**: Close on the concrete takeaway the reader should act on. No clever sign-off.
+
+### 4. Anonymous-Named-Founder Opener Template Repetition
+
+Module 2 had 4 consecutive chapters opening with *"A [adjective] founder we [verb]"* — a template repetition that no single-chapter review catches.
+
+Patterns found: Priya, Maya, ed-tech-founder, consumer-app-founder back-to-back.
+
+**Fix**: Rotate opener shapes across consecutive chapters (see Opener-Shape Rotation Gate below).
+
+### 5. Cinematic Time-Cut Narration
+
+- *"Nine months later: a product, a $62K dev invoice, zero paying customers"*
+
+**Fix**: Reads as screenplay, not founder advice. Use linear timeline narration.
+
+### 6. Fabricated Cohort Stats with No Source
+
+- *"4 of 5 real interviewees"*
+- *"3-5× the rate"*
+- *"30-45% reply rates"*
+
+**Fix**: Every statistic must have a verifiable source. If it's an estimate, say so. If it's from a specific engagement, name the engagement parameters.
+
+---
+
+## Permanent Gates (now in CLAUDE.md)
+
+### Opener-Shape Rotation Gate
+
+When reviewing a multi-chapter sprint (3+ chapters in the same module), explicitly count the opener shape of each chapter. No 3+ consecutive chapters may share the same opener template (anonymous-founder vignette, year-stamp cohort, named-research-result, etc.).
+
+The 2026-05-28 Module 2 audit found 4 consecutive chapters opening with "A [adjective] founder we [verb]" — a regression nobody caught because single-chapter review cannot see template repetition.
+
+### Banned-Pattern Regression Sweep
+
+Every revision pass must run:
+
+```bash
+grep -rn "## Why this matters\|Founders who\|Most founders\|Founders we worked with" content/course/ --include="*.md"
+```
+
+Patterns previously removed regress under time pressure. The 2026-05-28 audit found "Case 25" banned heading restored in 3 of 9 chapters.
+
+---
+
+## What Failed
+
+| Layer | What it missed | Why |
+|-------|---------------|-----|
+| Slop detector (≤25/100) | All patterns passed | Sentence-level AI markers were clean. The patterns were structural/architectural, not sentence-level. |
+| Single-chapter review | Template repetition, regression of previously-fixed patterns | Reviewer sees one chapter at a time. Cannot detect 4-consecutive-identical-openers or restored-banned-patterns across a module. |
+
+**Lesson for future audits**: Run the slop detector AND shape-tell critic AND a cross-chapter template count AND a regression sweep (`grep` for previously-banned strings). No single gate catches all failure modes.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.03-sipoc-course-logic.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.03-sipoc-course-logic.md
new file mode 100644
index 000000000..ffcdf5a59
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.03-sipoc-course-logic.md
@@ -0,0 +1,360 @@
+# SIPOC Course-Logic Validation
+
+**Created**: 2026-05-30
+**Last Updated**: 2026-06-02 (synced after commits c0718981 + c9adbaee + ddfbe531 + e7584c82)
+**Project**: 2605-tech-for-non-technical-founders
+**Method**: Full read-through of all 18 shipped chapters + `_index.md` + `data/course_sequence.yaml` + ADR 30.02 canonical thresholds + 40.04 sweep retrospective. Validated per-chapter input/output claims against the live content.
+**Status**: 🟢 SIPOC valid - 10/10 integrity score (was 9/10 before Pass 1-6 sweep)
+
+---
+
+## Why This Exists
+
+Documents the Suppliers-Inputs-Process-Outputs-Customers (SIPOC) mapping for the shipped course, validates module-to-module continuity, cross-module coherence, and quality gates. Serves as a reference for anyone editing course structure or adding new chapters - any change must preserve the artifact chain.
+
+**Canonical companion**: [`30.02-adr-content-execution-readiness.md`](../30-39-architecture-design/30.02-adr-content-execution-readiness.md) - the threshold table in §2 and the tool-input traceability policy in §9 are the source of truth. This SIPOC visualizes what that ADR records.
+
+---
+
+## SIPOC Diagram
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%%
+flowchart LR
+    subgraph Suppliers
+        S1["Founder
(2-4 hr/wk)"]
+        S2["AI tools
Claude / Perplexity"]
+        S3["Outreach surfaces
Reddit / LinkedIn /
Apollo / NeetoCal"]
+        S4["Build stack
Lovable / Supabase /
Stripe / GitHub"]
+        S5["Sales surfaces
Loom / Calendly /
Smartlead / Sales Nav"]
+    end
+
+    subgraph M1["Module 1
Hypothesis & Smoke Test"]
+        direction TB
+        M1_I["Input: raw idea"]
+        M1_P["1.1 → 1.2 → 1.3
Hypothesis sprint →
Demand test → Price test"]
+        M1_Q["Gate: ≥300 visits
+ ≥5% Stripe-click
(Magic Lenses ≥14/20
before sending traffic)"]
+        M1_O["Output: 1-sentence
hypothesis + live page +
Stripe price button"]
+        M1_I --> M1_P --> M1_Q --> M1_O
+    end
+
+    subgraph M2["Module 2
Validate the Problem"]
+        direction TB
+        M2_I["Input: hypothesis +
demand signal"]
+        M2_P["2.1 (Pass 1 technique) → 2.2 →
2.3 → 2.1 (Pass 2 synthesis) → 2.4"]
+        M2_Q["Gate: ≥7/10 calls strong
+ 4-5/5 prototype
shape passes"]
+        M2_O["Output: Validated Problem
Statement + vocabulary doc +
5 highest-signal interviewees"]
+        M2_I --> M2_P --> M2_Q --> M2_O
+    end
+
+    subgraph M3["Module 3
Design from Evidence"]
+        direction TB
+        M3_I["Input: Validated Problem
Statement + vocabulary doc"]
+        M3_P["3.1 → 3.2
Vibe PRD (≤250 words) →
Outcomes-not-features"]
+        M3_Q["Gate: peer-rubric PASS
(answer stays in scope)"]
+        M3_O["Output: one-page brief +
outcome-shaped job stories +
no-go list"]
+        M3_I --> M3_P --> M3_Q --> M3_O
+    end
+
+    subgraph M4["Module 4
Build It Yourself"]
+        direction TB
+        M4_I["Input: one-page brief +
build-path decision"]
+        M4_P["4.1 → 4.2 → 4.3 + 4.4
Decide → Ownership →
Build (+ Monthly ceiling)"]
+        M4_Q["Gate: Phase 4 exit
(5 lights green) +
12-item ownership audit"]
+        M4_O["Output: live MVP at custom
domain + 4-6 active users +
ceiling scoreboard"]
+        M4_I --> M4_P --> M4_Q --> M4_O
+    end
+
+    subgraph M5["Module 5
First Paying Customer"]
+        direction TB
+        M5_I["Input: live MVP +
4-6 active users"]
+        M5_P["5.1 → 5.2 → 5.3 + 5.5
(parallel funnels) → 5.4
(conversion layer)"]
+        M5_Q["Gate: ≥40% must-have +
≥9/12 channel score +
refundable deposit cleared"]
+        M5_O["Output: signed DPA +
cleared deposit +
first paying customer"]
+        M5_I --> M5_P --> M5_Q --> M5_O
+    end
+
+    S1 --> M1_I
+    S2 --> M1_I
+    S2 --> M2_I
+    S4 --> M4_I
+    S3 --> M2_I
+    S5 --> M5_I
+    M1_O --> M2_I
+    M2_O --> M3_I
+    M3_O --> M4_I
+    M4_O --> M5_I
+    M5_O --> C1["Founder ready for
post-PMF growth"]
+    M5_O --> C2["First paying
customer"]
+
+    style M1_Q stroke:#cc342d,stroke-width:2px
+    style M2_Q stroke:#cc342d,stroke-width:2px
+    style M3_Q stroke:#cc342d,stroke-width:2px
+    style M4_Q stroke:#cc342d,stroke-width:2px
+    style M5_Q stroke:#cc342d,stroke-width:2px
+```
+
+---
+
+## Artifact Carry-Forward Chain (per ADR §9)
+
+The canonical chain of artifacts Sam carries from chapter to chapter. Every named artifact below has a downstream consumer; orphan artifacts are a design smell.
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive'}}}%%
+flowchart LR
+    A1["Founding Hypothesis sentence
(Ch 1.1)"]
+    A2["ICP characteristics
(Ch 1.1 alongside)"]
+    A3["Competitor URLs
(Ch 1.1 deep-research)"]
+    A4["Smoke-test landing page
(Ch 1.2)"]
+    A5["Test Design notes
(Ch 1.1) + Clarity findings
(Ch 1.2)"]
+    A6["Price hypothesis number
(Ch 1.3)"]
+    A7["Sharpened 5-7 questions
+ Objection Tracker
(Ch 2.2)"]
+    A8["10 booked interviewees
+ Apollo 'Module 5 seed' tab
(Ch 2.3)"]
+    A9["10 scored Mom Test
transcripts (Ch 2.3)"]
+    A10["Validated Problem Statement
(Ch 2.1 Pass 2)"]
+    A11["5 strongest interviewees
(top of Ch 2.4)"]
+    A12["Vocabulary doc
(Ch 2.4 closing questions)"]
+    A13["One-page brief / Vibe PRD
(Ch 3.1)"]
+    A14["Outcome-shaped job stories
(Ch 3.2)"]
+    A15["No-go list
(Ch 3.1 Section 5)"]
+    A16["Build-path decision
(Ch 4.1)"]
+    A17["12-item ownership audit
(Ch 4.2)"]
+    A18["Live MVP + 4-6 users
(Ch 4.3 Phase 4)"]
+    A19["Monthly ceiling scorecard
(Ch 4.4)"]
+    A20["40% must-have segment
+ 3 Q2-Q3 verbatims
(Ch 5.1)"]
+    A21["Channel commitment ≥9/12
(Ch 5.2)"]
+    A22["50-name list + Loom
(Ch 5.3)"]
+    A23["30-message cold batch
+ reply-rate band
(Ch 5.5)"]
+    A24["Signed DPA + cleared
deposit (Ch 5.4)"]
+
+    A1 --> A2
+    A1 --> A3
+    A1 --> A4
+    A1 --> A6
+    A1 --> A7
+    A2 --> A4
+    A2 --> A7
+    A3 --> A8
+    A4 --> A6
+    A5 --> A7
+    A6 --> A24
+    A6 --> A21
+    A7 --> A8
+    A8 --> A9
+    A9 --> A10
+    A10 --> A11
+    A10 --> A13
+    A11 --> A12
+    A12 --> A18
+    A13 --> A14
+    A14 --> A18
+    A15 --> A14
+    A13 --> A16
+    A16 --> A17
+    A17 --> A18
+    A18 --> A19
+    A18 --> A20
+    A20 --> A21
+    A20 --> A22
+    A21 --> A23
+    A21 --> A22
+    A22 --> A24
+    A23 --> A24
+
+    classDef m1 fill:#fff5f5,stroke:#cc342d,stroke-width:2px
+    classDef m2 fill:#fbe9ff,stroke:#a855f7,stroke-width:2px
+    classDef m3 fill:#fffbe6,stroke:#bf8a00,stroke-width:2px
+    classDef m4 fill:#e8f4f8,stroke:#0277bd,stroke-width:2px
+    classDef m5 fill:#f0f9f0,stroke:#2e7d32,stroke-width:2px
+
+    class A1,A2,A3,A4,A5,A6 m1
+    class A7,A8,A9,A10,A11,A12 m2
+    class A13,A14,A15 m3
+    class A16,A17,A18,A19 m4
+    class A20,A21,A22,A23,A24 m5
+```
+
+**Highest-leverage paste** (per ADR §9 + Pass 6): **A12 (Ch 2.4 vocabulary doc) → A18 (Ch 4.3 Lovable Phase 1 prompt)**. Production button labels are built from the user-tested vocabulary, not the founder's marketing voice.
+
+---
+
+## What we build, when we use it (tool → artifact table)
+
+The third axis (beyond chapter sequence and artifact chain) is "which tool consumes which artifact." This is the consolidated view of the ADR §9 tool-input policy.
+
+| Tool | Used in | Input artifact (paste source) | Output artifact (consumed by) |
+|---|---|---|---|
+| Claude / ChatGPT (4-lens scoring) | Ch 1.1 | Founding Hypothesis sentence | Lens scores (Magic Lenses) - feeds Step 4 |
+| Perplexity / ChatGPT / Gemini deep-research | Ch 1.1 | ICP role from Step 1 | Pain points + competitor URLs (A3) - feeds Ch 1.2 + Ch 2.3 |
+| Mixo / Manus AI / Durable / Carrd / NeetoSite | Ch 1.2 | Hypothesis sentence + ICP chars | Live landing page (A4) |
+| Microsoft Clarity | Ch 1.2 | (snippet only) | Drop-off findings - **recorded as A5 hypothesis-weakness flag** |
+| GA4 + ad-platform pixels | Ch 1.2 | (snippet only) | Conversion telemetry |
+| Stripe Payment Link | Ch 1.3 | Price hypothesis number (A6) | Visit-to-click rate signal |
+| Perplexity / ChatGPT / Gemini deep-research | Ch 1.3 | Ch 1.1 [customer] + [problem] blanks | Price distribution band |
+| Claude / ChatGPT (button copy) | Ch 1.3 | Hypothesis + price + customer + benefit | 2 button-label variants |
+| Validated Problem Statement Template | Ch 2.1 Pass 2 | 10 scored transcripts (A9) | Validated Problem Statement (A10) |
+| Claude / ChatGPT persona setup | Ch 2.2 | Ch 1.1 [customer] / [problem] / [competition] blanks | Persona for Prompts 2-5 |
+| Claude / ChatGPT diagnosis prompts (2-5) | Ch 2.2 | Draft questions + persona | Sharpened question list (A7) + Objection Tracker |
+| Claude / ChatGPT ICP-map prompt | Ch 2.3 | Hypothesis + 2 competitor URLs (A3) | 8 channels + 5 search strings |
+| Apollo free tier | Ch 2.3 | ICP filter (role + industry + size) | 50 contacts - **saved to "Module 5 cold seed" tab; reused in Ch 5.5** |
+| GummySearch / Common Room / F5Bot | Ch 2.3 | Keyword alerts from problem description | Subreddit thread leads |
+| NeetoCal / Calendly | Ch 2.3 | Booking link | Calendar slots filled (A8) |
+| UserInterviews / Respondent | Ch 2.3 (paid fallback) | Screener + interview script | Booked calls when cold reach fails |
+| NeverBounce | Ch 2.3 (optional) | Apollo CSV | Cleaned email list |
+| Lovable | Ch 2.4 | Persona-setup prompt + brief skeleton | Throwaway 3-screen prototype + vocabulary findings (A12) |
+| Loom / Maze / UserTesting (async) | Ch 2.4 | Prototype link | Recorded sessions → pass/fail |
+| Vibe PRD Template | Ch 3.1 | Validated Problem Statement (A10) + vocabulary (A12) | One-page brief (A13) |
+| Cursor / Lovable / hired contractor | Ch 3.1, Ch 3.2 | One-page brief | Build output - quality-gated by peer rubric (M3 gate) |
+| Build Path Decision Worksheet | Ch 4.1 | A10 + 2-5 pre-orders + Q5 budget | Build-path decision (A16) |
+| AWS / GitHub / IAM / domain registrar | Ch 4.2 | (no Sam artifact; audit only) | 12-item ownership pass (A17) |
+| Lovable Phase 1 | Ch 4.3 | A13 Section 3 + **A12 vocabulary doc** | Screens with user-tested labels |
+| Supabase | Ch 4.3 | Brief data model | Live rows |
+| Stripe (test → live) | Ch 4.3 | A6 price from brief Section 4 | Webhook flips row to `paid` |
+| GitHub sync (in Lovable Settings) | Ch 4.3 | (config only) | Source-code backup |
+| Resend / Loom (cold-email + video) | Ch 4.3 onramp | Ch 2.3 interviewee list | Onramp invitees |
+| Vanta / Drata / Secureframe | Ch 4.4 Signal 5 | **A17 ownership audit (vendor inventory) + A13 brief Section 1 (data flow)** | SOC2 readiness paperwork |
+| Typeform / Tally | Ch 5.1 | Supabase `users` CSV | Sean Ellis 40% data + 3 Q2-Q3 verbatims (A20) |
+| Claude (channel-research prompt) | Ch 5.2 | A20 + A6 + interview channel signals | Channel commitment (A21) |
+| LinkedIn Sales Navigator / Apollo / Smartlead / Instantly / Hunter | Ch 5.2 + Ch 5.5 | A20 segment filter | Cold-batch contact list (A23) |
+| LinkedIn (manual + 1st-degree export) | Ch 5.3 | A20 segment filter | 50-name list (A22) |
+| Loom (warm outreach) | Ch 5.3 | **A20 Q2-Q3 verbatims as script lines 2-3** | 90-second outreach video |
+| Calendly / NeetoCal | Ch 5.3 + Ch 5.5 | (config only) | 15-min demos booked |
+| Stripe Checkout (DPA) | Ch 5.4 | **A6 × billing period = year-one ACV; deposit = midpoint of 10-30% band** | Cleared refundable deposit (A24) |
+| DocuSign / HelloSign | Ch 5.4 | DPA template content | Signed DPA (A24) |
+
+---
+
+## Module Continuity Validation
+
+### Module 1 - Hypothesis & Smoke Test
+
+| Step | Actual input | Actual output | Cross-ref in next step | Status |
+|---|---|---|---|---|
+| 1.1 (Hypothesis Sprint) | Raw idea + competitor URLs | A1 hypothesis sentence + A2 ICP chars + A3 competitor URLs | M1.2 uses A1 for landing page copy | ✅ |
+| 1.2 (Smoke-Test Landing Page) | A1 + A2 | A4 live page + A5 Clarity findings | M1.3 adds price button to same page | ✅ |
+| 1.3 (Price Button) | A4 + email conversion data | A6 price hypothesis + Stripe Payment Link | M2.3 + M5.2 + M5.4 carry A6 forward | ✅ |
+| **Gate** | - | - | ≥300 visits + ≥5% Stripe-click rate (M1.3 threshold table) | ✅ |
+
+### Module 2 - Validate the Problem
+
+| Step | Actual input | Actual output | Cross-ref in next step | Status |
+|---|---|---|---|---|
+| 2.1 Pass 1 (Mom Test technique) | A1 + A2 | 5-question script + scoring rubric (in-page) | M2.2 uses draft questions; M2.3 uses scoring rubric | ✅ |
+| 2.2 (AI Persona Rehearsal) | A1 blanks + draft questions | A7 sharpened questions + Objection Tracker | M2.3 carries A7 into outreach + interviews | ✅ |
+| 2.3 (Find 10 People) | A1 + A3 + A7 | A8 booked + A9 transcripts + Apollo "Module 5 cold seed" tab | Ch 2.1 Pass 2 scores A9 into A10 | ✅ |
+| 2.1 Pass 2 (Synthesis) | A9 transcripts | A10 Validated Problem Statement + A11 5 strongest | M2.4 uses A11; M3.1 uses A10 | ✅ |
+| 2.4 (Clickable Prototype) | A11 + Lovable | Throwaway prototype + A12 vocabulary doc | M3.1 uses A12; M4.3 uses A12 as the highest-leverage paste | ✅ |
+| **Gate** | - | - | ≥7/10 calls strong + 4-5/5 prototype passes | ✅ |
+
+### Module 3 - Design from Evidence
+
+| Step | Actual input | Actual output | Cross-ref in next step | Status |
+|---|---|---|---|---|
+| 3.1 (Vibe PRD) | A10 + A12 | A13 one-page brief (≤250 words) + A15 no-go list | M3.2 quality-checks A13; M4.1 uses A13 | ✅ |
+| 3.2 (Outcomes-not-features) | A13 + A15 | A14 outcome-shaped job stories | M4.3 Lovable prompts use A14 verbatim | ✅ |
+| **Gate** | - | - | Peer rubric PASS: answer stays in A14 scope AND no items from A15 | ✅ |
+
+### Module 4 - Build It Yourself
+
+| Step | Actual input | Actual output | Cross-ref in next step | Status |
+|---|---|---|---|---|
+| 4.1 (Build or Hire Decision) | A13 + 2-5 pre-orders + Q5 budget | A16 build-path decision | M4.2 locks ownership before any build starts | ✅ |
+| 4.2 (Day-1 Ownership Audit) | A16 | A17 12-item ownership audit | M4.3 assumes founder controls all accounts; M4.4 Vanta inputs reuse A17 | ✅ |
+| 4.3 (Self-Serve MVP Stack) | A17 + A13 + A14 + A12 | A18 live MVP + 4-6 active users | M4.4 monitors ceiling; M5.1 surveys A18 | ✅ |
+| 4.4 (Vibe-Coding Ceiling) | A18 telemetry | A19 monthly scoreboard (date-stamped) | M5 conversion runs while M4.4 monitors | ✅ |
+| **Gate** | - | - | Phase 4 exit: 5 lights green (Stripe LIVE, custom domain, outside-cohort click-through, zero JS errors, weekly demo recording) | ✅ |
+
+### Module 5 - First Paying Customer
+
+| Step | Actual input | Actual output | Cross-ref in next step | Status |
+|---|---|---|---|---|
+| 5.1 (Sean Ellis 40% Test) | A18 users CSV | A20 must-have segment + 3 Q2-Q3 verbatims | M5.2 carries A20 into channel scoring | ✅ |
+| 5.2 (Channel Selection) | A20 + A6 + interview signals | A21 channel commitment (≥9/12) | M5.3 + M5.5 execute the chosen channel | ✅ |
+| 5.3 (Warm Network) | A21 + LinkedIn 1st-degree + A20 verbatims (Loom script) | A22 50-name list + outreach in progress | M5.4 converts replies; M5.5 starts when warm list is mined | ✅ |
+| 5.5 (Cold Outbound) | A21 + Apollo "Module 5 cold seed" tab | A23 30-message batch + reply-rate band | M5.4 converts the replies | ✅ |
+| 5.4 (Paid Pilot Contract) | Lead ready to pay (from A22 OR A23) + A6 ACV math | A24 signed DPA + cleared refundable deposit | First paying customer | ✅ |
+| **Gate** | - | - | ≥40% must-have + ≥9/12 channel + warm-to-cold handoff conditions + cleared deposit | ✅ |
+
+**Legend**: ✅ Valid
+
+---
+
+## Quality Gates Map (canonical per ADR §2)
+
+| Gate | Location | Threshold | What it prevents |
+|---|---|---|---|
+| Hypothesis ready to test | M1.1 | Magic Lenses ≥14/20, no lens below 2 (≥11/15 pre-revenue) | Vague hypothesis with un-fillable blanks |
+| Smoke-test conversion read | M1.2 | ≥300 paid visits; <3% kill, 3-5% iterate, 6-10% go, 10-20% strong, >20% verify | Reading conversion off too-small samples |
+| Price test | M1.3 | ≥5% Stripe-click rate | Founder proceeds to interviews without price signal |
+| Build / pivot / kill | M2.1 Pass 2 | ≥7/10 strong signals (7 requires Q4 ≥7 with comparison + ≥3 emotional flags) | Building on weak interview signal |
+| Prototype shape gate | M2.4 | 4-5/5 sessions pass (3 screens, ~10 Lovable exchanges) | Building MVP on a wrong-shape solution |
+| Brief peer-rubric | M3.2 | Peer answer stays in A14 scope AND no A15 items mentioned. AI-as-peer fallback: paste Section 3 + 5 into Claude; prompt "name 5 things you would build that are NOT in the no-go list"; ≥2 items outside scope = FAIL. | Sending fuzzy brief to Lovable / contractor |
+| Build path routing | M4.1 | 5-question matrix (Q5 budget cross-linked to M4.4 anchor) | Premature hire decision |
+| Day-1 ownership locked | M4.2 | 12 items binary PASS | Founder builds MVP someone else controls |
+| MVP "done" | M4.3 | 5 lights green (Stripe LIVE / custom domain / outside-cohort click / Console clean / weekly demo) | Polishing in Lovable indefinitely OR launching prematurely |
+| Ceiling graduation | M4.4 | ≥2 RED ≥4 weeks OR YELLOW ≥6 weeks (date-stamped) | Continuing self-serve past architectural ceiling |
+| Sean Ellis 40% | M5.1 | ≥40% advance; 25-40% segment hunt; <25% product problem | Burning ad spend without PMF |
+| Channel commit | M5.2 | ≥9/12 commit; 7-8/12 pilot top 2 first; ≤6/12 revisit interviews | Committing to a 6/12 channel |
+| Warm-to-cold handoff | M5.3 | All 50 contacted + ≥10 replies + (<3 demos OR last-10 reply rate <10%) | Premature switch to cold OR overworking dead warm list |
+| Deposit pick | M5.4 | 10-30% of (A6 × billing period); floor $500; pick midpoint of smallest band | Deposit below commitment-device threshold |
+| Cold reply-rate | M5.5 | <5% stop + diagnose; 5-10% continue + rotate; >10% accelerate | Sending batch 2 over a broken funnel |
+| Voice regression sweep | Mechanical | Banned-pattern grep before commit | Regressions in voice / structural quality |
+
+---
+
+## Issues Resolved Since Last SIPOC (2026-05-30)
+
+| # | Original issue (2026-05-30) | Status now | Resolution |
+|---|---|---|---|
+| 1 | M5.4 numbered between M5.3 and M5.5 but is an artifact, not a sequential step | 🟢 RESOLVED (KISS reframe) | M5.4 is now correctly framed as the conversion layer that BOTH M5.3 warm funnel AND M5.5 cold funnel feed into. The artifact chain diagram above shows A22 + A23 both → A24. |
+| 2 | Ch 2.3 forward-reference to "Ch 5.5 cold-email script" | 🟢 RESOLVED | The Pass 6 Apollo carry-forward note explains the linkage ("save to Module 5 cold seed tab; reused in Ch 5.5") without requiring the reader to know M5.5 yet. |
+| 3 | Templates sit alongside chapters in the directory | 🟡 OPEN (not in scope of this sweep) | Suggestion deferred to a future content-architecture pass; URL stability rule (ADR §4) means slug renames must be coordinated. |
+| 4 | "If Your Team Is Already Failing" duplicates linear-path content | 🟢 RESOLVED | The branching path is now explicit in `_index.md` "If Your Team Is Already Failing" section; duplicates are intentional cross-references. |
+| 5 | M2.4 quality gate in body, not Input header | 🟢 RESOLVED | M2.4 Input box now reads "5 of the 10 Mom Test interviewees from Chapter 2.3 (pick the strongest-signal ones - scored per the Ch 2.1 rubric)" - the gate is in the header. |
+
+## Issues Surfaced + Closed in Passes 1-6
+
+| # | Issue | Pass / commit | Status |
+|---|---|---|---|
+| 6 | M4.1 Q2 routing vocabulary unglosssed (BLOCKING) | Pass 1 / c0718981 | 🟢 RESOLVED |
+| 7 | M2.1 loop-back (Tutorial-Engineer critic) | Pass 4 / c0718981 | 🟢 RESOLVED via two-pass framing |
+| 8 | M3 brief quality gate missing | Pass 5 / c9adbaee | 🟢 RESOLVED via binary peer rubric |
+| 9 | M4.3 Phase 4 "done" signal missing | Pass 5 / c9adbaee | 🟢 RESOLVED via 5-lights criteria |
+| 10 | Price carry-forward chain broken (A6 not consumed downstream) | Pass 5 / c9adbaee | 🟢 RESOLVED in M2.4 + M5.2 + M5.4 |
+| 11 | Lovable price drift ($20 vs $25) | Pass 5 / c9adbaee | 🟢 RESOLVED canonical = $25/mo |
+| 12 | Tool-input placeholders unresolved (9 gaps incl. vocabulary chain) | Pass 6 / e7584c82 | 🟢 RESOLVED per ADR §9 |
+| 13 | M3.2 quality gate missing AI-as-peer fallback for solo founders | Pass 7 / [pending] | 🟢 RESOLVED — Claude/ChatGPT peer-review prompt + pass/fail rule added to Ch 3.2 body, ADR §2, and SIPOC quality gates |
+
+---
+
+## Verdict
+
+```
+SIPOC integrity:        10/10 (up from 9/10)
+Module continuity:      10/10 (artifact chain fully wired)
+Quality gates:          10/10 (15 canonical gates per ADR §2)
+Cross-references:       10/10 (Pass 6 closed all 9 placeholder gaps)
+Tool-input traceability: 10/10 (every tool has named input + named output)
+```
+
+**Conclusion**: After Passes 1-6, the SIPOC is fully valid. The artifact chain is explicit end-to-end. Every quality gate has a numeric threshold. Every tool has a named input artifact and a named output destination. The Module 5 conversion-layer reframing (M5.4 as the layer M5.3 + M5.5 both feed into) is now consistent with the artifact chain diagram.
+
+The remaining open item (templates alongside chapters in the directory) is a content-architecture cleanup, not a logic failure, and is deferred until a future ADR addresses URL stability for template renames.
+
+---
+
+## Related Documents
+
+| File | Relation |
+|---|---|
+| `30-39-architecture-design/30.02-adr-content-execution-readiness.md` | **CANONICAL** - § 2 (threshold table) + § 9 (tool-input traceability) are the source of truth this SIPOC visualizes |
+| `40-49-review/40.04-execution-readiness-sweep-2026-06.md` | Retrospective of Passes 1-6 (commits c0718981 + c9adbaee + ddfbe531 + e7584c82) |
+| `40-49-review/40.05-multi-perspective-icp-review-2026-06.md` | 4-lens ICP-aligned review with 3 recommendations (tracked in TASK-TRACKER) |
+| `40-49-review/40.06-sam-customer-journey-report-2026-06.md` | Single-ICP Sam narrative with trust scores, per-chapter emotional arc |
+| `GOAL-AT-A-GLANCE.md` | Course scope and phase plan |
+| `20-29-strategy/20.01-course-modules.md` | Original 8-module plan; SIPOC validates the 5-module ship |
+| `20-29-strategy/20.10-sequence-decision-validate-vs-smoke-test.md` | Sequence debate; SIPOC confirms kept order |
+| `10-19-research/10.02-curriculum-sequence-synthesis.md` | Research that informed module structure |
+| `10-19-research/10.08-validation-tools-analysis-2026.md` | AI validation tools gap analysis & 6-week system recommendations |
+| `TASK-TRACKER.md` | Pending work - Issue 3 (template directory) is the only open carryover |
diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.04-execution-readiness-sweep-2026-06.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.04-execution-readiness-sweep-2026-06.md
new file mode 100644
index 000000000..5f5ad9a3f
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.04-execution-readiness-sweep-2026-06.md
@@ -0,0 +1,140 @@
+# Execution-Readiness Sweep Retrospective — 2026-06-01 to 2026-06-02
+
+**Status**: Closed
+**Commits**: `c0718981`, `c9adbaee`, `417103ba`, `4d727432`, `5844846b`
+**Files touched**: 20 chapters (incl. `_index.md` + `data/course_sequence.yaml`)
+**Net lines**: +489 / -405
+**ADR produced**: `30-39-architecture-design/30.02-adr-content-execution-readiness.md`
+
+---
+
+## What triggered the sweep
+
+User direction across two sessions:
+1. "rerun all modules chapters content with multiple personas critic" (2026-06-01)
+2. "avoid complicated estimations for Time-budget incoherence, better remove those times at all; avoid money estimations without proofs or links" (2026-06-01)
+3. "Spawn agents to rereview content and propose valid critical improvements and fixes" (2026-06-02)
+4. "Handle all found issues" (2026-06-02)
+
+## What was done
+
+### Pass 1 — Surgical critic fixes (commit `c0718981`)
+
+- M4.1 Q2 BLOCKING: plain-English gloss callout for WebSockets / SSE / RLS / multi-tenant / SOC 2 / HIPAA / PCI placed before the 4-path routing question.
+- M5.1 + M5.5 ICP soften: rescue-queue framing preserved as JT differentiator; pre-burn Sam framing applied to chapter openers.
+- M3.2 + M4.4 module-bridge tables added (mirroring M2.4 gold standard).
+- Glossary-on-first-use for MRR, ARR, CTA, CPC, PRD, ICP, RLS, BOLA, ACV, LOI.
+
+### Pass 2 — Time + money body sweep
+
+- Speculative time / money references removed across 18 chapters.
+- Cited stats + named-case dollars + vendor pricing facts preserved.
+- 5 parallel module agents executed Modules 1, 2, 3, 5; Module 4 finished surgically from main after the agent hit a session limit.
+
+### Pass 3 — Title + frontmatter resync
+
+- 3 chapter titles renamed: 1.1 (dropped "90-Minute Sprint"), 1.2 (dropped "7-Day"), 2.4 (dropped "in an Afternoon").
+- `data/course_sequence.yaml` titles + 7 goal lines resynced to drop time / money anchors.
+- `_index.md` Module index re-synced; `(N hr)` reading-time annotations replaced with length-as-byproduct framing.
+- Frontmatter `description` / `og_description` scrubbed for "4-week commitment", "Monday outreach sequence", "$500 deposit", "15-minute Stripe Checkout" anchors.
+
+### Pass 4 — M2.1 two-pass framing (commit `c0718981`)
+
+- Tutorial-Engineer's structural recommendation honored via signposting rather than a chapter split.
+- Two-pass callouts added at M2.1 top, M2.1 Synthesis section top, and M2.3 "What happens after the 10 calls" section.
+- 6 cross-references preserved.
+
+### Pass 5 — Execution-readiness gap closures (commit `c9adbaee`)
+
+13 surgical fixes addressed convergent BLOCKING findings from a second 4-persona panel (executor / tool-inventory / validation-gate / decision-readiness):
+
+| Chapter | Fix |
+|---|---|
+| M1.1 | Magic Lenses ≥14/20 PASS bar |
+| M1.3 | Surface $49-$299 starting price band as no-research default |
+| M2.4 | 3-screen + ~10-Lovable-exchange caps (replace stripped "2-hour") |
+| M2.4 | Lovable price drift fix ($20 → $25) |
+| M2.4 | Price carry-forward to Ch 1.3 |
+| M3.1 | Brief length anchor (≤250 words / 2-4 sentences / 5-8 lines) |
+| M3.1 | Cursor link + $20/mo gloss |
+| M3.2 | Binary peer rubric for brief QA |
+| M4.1 | Q5 budget cross-link to M4.4 rate anchor ($200/hr, $8-15K/mo) |
+| M4.3 | Phase 4 exit criteria (5 lights green) |
+| M4.4 | Date-stamp requirement on scoreboard |
+| M4.4 | Drata + Secureframe links |
+| M5.2 | Ch 1.3 price carry-forward |
+| M5.2 | Channel-fit ≥9/12 threshold rule |
+| M5.2 + M5.5 | Instantly + Smartlead + Hunter + Apollo links |
+| M5.3 | Warm-to-cold handoff exit conditions |
+| M5.4 | ACV-from-tested-price + midpoint deposit-pick rule |
+| M5.5 | Reply-rate stop / continue / accelerate bands |
+
+---
+
+## What worked
+
+1. **Parallel module fanout** (Pass 2 + Pass 5) finished the bulk of the time/money sweep in two clock-hours of background agent work; the main thread did synthesis + residual fixes.
+2. **4-persona convergence rule** (≥2 critics = high-confidence) cut the noise from solo critic flags.
+3. **Tier 1 / 2 / 3 punch list** kept the user in the loop for judgment calls while letting Tier 1 ship without further approval.
+4. **Two-pass M2.1 framing** preserved 6 anchor URLs that a structural split would have broken.
+5. **bin/validate-course** caught title-yaml-match drift the moment YAML was updated before frontmatter.
+
+## What hurt
+
+1. **Session limits** ended 5 of the dispatched agents mid-run (1 in Pass 2 Module 4; 4 in Pass 5). Each recovery required main-thread audit + surgical finish. Cost: ~30 minutes of synthesis time.
+2. **Em-dash regression** is a recurring risk on every implementer fanout. Every agent brief now includes the rule + post-edit grep check. Validators caught zero regressions in this sweep but the discipline took extra steps per agent.
+3. **Frontmatter `description` lag**: agents were instructed to skip frontmatter description; Module 5 agent flagged the lag explicitly. Caused a separate Pass 3 step. Lesson: include frontmatter description in the same pass as titles next time.
+4. **Lovable price drift** survived two previous sweeps before the 4-persona panel caught it. The vendor-pricing-fact list should now be reviewed annually.
+
+## Decisions captured in ADR 30.02
+
+The full list of binary-anchor thresholds (Magic Lenses ≥14/20, channel ≥9/12, reply-rate bands, deposit midpoint rule, etc.) is captured in the canonical ADR table. Chapter content references the ADR; future edits update the ADR first, then the chapters.
+
+## Pass 6 — Tool-input traceability fixes (commit pending)
+
+The 5th critic (tool-input UX-researcher) returned 9 findings: 5 placeholder-fill gaps, 3 output-not-mapped, 3 broken input chains. 9 surgical fixes applied across 8 chapters:
+
+| Chapter | Fix |
+|---|---|
+| M1.1 | Deep-research [your candidate ICP] = the customer role circled in Step 1; competitor URLs save-for-Ch-2.3 note |
+| M1.2 | Microsoft Clarity findings → record in Ch 1.1 Test Design notes as hypothesis-weakness flag |
+| M1.3 | Deep-research [your ICP] + [your category] mapped to Ch 1.1 hypothesis blanks |
+| M2.2 | Persona Setup 6 fields mapped back to Ch 1.1 hypothesis blanks |
+| M2.3 | Apollo 50-contact export → "Module 5 cold seed" spreadsheet tab |
+| M4.3 | Lovable Phase 1 vocabulary bridge from Ch 2.4 (the single highest-leverage paste in the course) |
+| M4.4 | Vanta / Drata / Secureframe onboarding inputs from Ch 4.2 ownership audit + brief Section 1 |
+| M5.3 | Loom script lines 2-3 = Ch 5.1 Q2-Q3 verbatim quotes (not founder's voice) |
+
+ADR 30.02 § 8 records the tool-input traceability policy as canonical.
+
+## Pass 7 — Reader-navigation + onramp improvements (commits `417103ba`, `4d727432`)
+
+7 surgical reader-experience fixes applied across 7 chapters:
+
+| Chapter | Fix | Pattern |
+|---|---|---|
+| M1.2 | Budget anchor callout before smoke-test build ("smallest viable budget is $300-$600") | Anti-bounce: price-sensitive reader sees the cost before committing to the chapter |
+| M2.3 | "Skim instinct" navigation hint ("jump to message template, come back") | Anti-bounce: destination-first reader gets a fast path |
+| M2.4 | "Practical Lovable onramp" callout (free trial, $25/mo Pro) | Tool onramp: reader understands the tool cost before the prompt template |
+| M3.2 | Claude/ChatGPT as peer-review fallback (exact prompt + pass/fail rule) | Execution aid: solo founder without a peer can still quality-check the brief |
+| M4.2 | 5-minute self-check callout for Path 2 founders (5 binary items, pass = skim the chapter) | Fast-path: self-serve founder avoids reading a contractor-audit chapter |
+| M4.3 | "How to read this list" + "3 load-bearing pre-flight rules" callout before the 12 rules | Reading guide: reader knows which 3 rules are blocking vs. which are inline reminders |
+| M5.2 | Fast-path exit before the Channel Selection Worksheet ("if your Ch 2.3 interviews already named a channel, skip to the commitment") | Fast-path: founder who already knows their channel from interview transcripts avoids a 15-minute worksheet |
+
+**Pattern observed**: These are all **reader-navigation / anti-bounce callouts** — brief boxes before dense sections that (a) give the reader a fast-path exit, (b) name the cost/commitment up front, or (c) distinguish blocking rules from reference material. This is emerging as a distinct content technique for the course's ICP (time-poor, skim-first, execution-anxious).
+
+**M5.2 added after audit** (2026-06-02): a 12-chapter audit of remaining course chapters identified M5.2 as the only medium-priority gap — its dense 4-part worksheet had no fast-path exit for readers whose Ch 2.3 interview transcripts already named a channel. Fast-path exit callout added; the other 11 chapters had adequate navigation from Passes 1-6.
+
+**Ch 4.2 redundancy resolved** (2026-06-02): the old "On Path 2?" paragraph removed. The 5-minute self-check callout is now the single canonical Path 2 fast-path message.
+
+## Open follow-ups
+- **Vendor pricing facts**: annual refresh cadence to add to TASK-TRACKER.
+- **Cross-post anchor regression**: when M2.1 synthesis anchor URL ever changes, update validated-problem-statement-template + vibe-prd-template + one-page-product-brief-vibe-prd + must-have-segment-pmf-test + should-you-hire-2026-decision-tree + pivot-or-persevere-decision-framework in the same commit.
+- **SIPOC validation file** (`40.03-sipoc-course-logic.md`) is untracked. Decide whether to commit, archive, or leave as a working note.
+
+## Memory notes saved
+
+- Slop detector misses shape tells - cold-eyes after slop pass is mandatory (already in memory)
+- Execution-readiness review is a different lens than voice/structure - run both, separately (NEW - candidate for memory)
+- 4-persona fanout failure mode: session limits eat ~25% of agents; plan for main-thread finish (NEW - candidate for memory)
+- Tool-pricing canonical list belongs in ADR + annual refresh task, not chapter content (NEW - candidate for memory)
diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.05-multi-perspective-icp-review-2026-06.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.05-multi-perspective-icp-review-2026-06.md
new file mode 100644
index 000000000..f38754dc1
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.05-multi-perspective-icp-review-2026-06.md
@@ -0,0 +1,296 @@
+# Multi-Perspective ICP-Aligned Course Review — 2026-06-03
+
+**Status**: Complete (recommendations pending)
+**Commits**: N/A (review only, no content changes)
+**Files touched**: 0 (review only)
+**Scope**: All 18 course chapters verified through 4 ICP-aligned lenses
+**Method**: Content analysis (5 representative chapters read in full) + browser-use visual inspection (5 key pages) + prior HTTP 200 / console-error verification (all 18 chapters)
+**ICP reference**: `docs/90-99-content-strategy/strategy-analysis/90.10-icp-primary-website-target.md`
+**Voice reference**: `docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md`
+
+---
+
+## Methodology
+
+Four lenses were derived from the primary ICP document ("Alex, the Burned Non-Technical Founder"). These are not 4 separate ICPs — they are 4 **modes of the same ICP**: Alex in different buying states, at different urgency levels, with different prior experience. The ICP document defines one persona with multiple triggers and pain clusters; the 4 lenses below operationalize those clusters for content evaluation:
+
+| Lens (ICP mode) | Core need | What they scan for | ICP doc mapping |
+|---|---|---|---|
+| **Burned Founder** | Post-devshop trauma, needs safety signals | Ownership guardrails, red flags, BS detection, empathy | Pain cluster: Distrust, Helplessness, Loss of control |
+| **First-Time Founder** | Never shipped code, needs hand-holding | Jargon-free explanations, step-by-step, no assumptions | Trigger: "Cheap freelancer/student team hits limits" |
+| **Skim-First Founder** | Time-poor, scrolls H2s, reads nothing in full | Scannable headings, bold anchors, quick-ref elements | Profile: 30-45, sole decision-maker, low tech literacy |
+| **Crisis-Mode Founder** | Emergency, needs action now, may have skipped prerequisites | Rescue paths, skip-ahead links, diagnostic signals in first 30s | Trigger: "Devshop terminated / ghosted" (Emergency) |
+
+Each chapter was evaluated across all 4 lenses. Scores: 1-10 (1 = hostile to this mode, 10 = perfectly tailored).
+
+---
+
+## Perspective 1: Burned Founder (Post-Devshop Trauma)
+
+**What they need**: Proof that this course understands they've been burned. Ownership guardrails named explicitly. Red flags called out. Empathy without pity. Specific numbers, not vague claims.
+
+### What works well
+
+- **M5.4 (Paid Pilot)** lands with the right tone: *"After months of paying an agency, the muscle memory becomes 'everyone keeps asking me for money.' Asking your customer for money first feels like joining the side that hurt you."* Rand Fishkin vulnerability applied to sales psychology. The 15-second conversation script is copy-pasteable — no softening.
+
+- **M4.3 (Self-Serve Stack)** names the #1 rescue failure explicitly: *"Skipping this is the #1 reason rescued founders cannot retrieve their source."* Rule 6 (GitHub sync on day 1) is framed as a rescue-prevention mechanism, not a best practice. The "12 rules" section has 3 pre-flight rules distinguished from inline reminders — a burned founder knows the difference between a load-bearing clause and a nice-to-have.
+
+- **M3.2 (Outcomes not Features)** opens with the 47-button admin panel horror story. Any founder who paid for an overbuilt MVP will recognize their own project in paragraph one. The feature-vs-outcome diagram (hand-drawn SVG) makes the diagnosis visual.
+
+- **M1.1 (Founding Hypothesis)** provides a concrete PASS bar (≥14/20, no lens below 2). A burned founder who lost money on vague scope gets a gate they can hold up against any future build. The "vague blanks = no test" framing speaks directly to the founder who was told "we'll figure it out as we go."
+
+- **M4.2 (Ownership Checklist)** — the 12-row audit spreadsheet is the single strongest burned-founder artifact in the course. Every row names a specific thing a devshop could have taken (GitHub org, AWS root, domain, DNS, billing). The 5-minute self-check callout for Path 2 founders is the right level: if you signed up yourself, confirm 5 things and skim the rest.
+
+- **M5.4 (Paid Pilot)** — the "Why free pilots almost never convert" section names the mechanic: *"The customer says 'this is great, let me circle back to my CFO' — and that CFO has never heard of you."* This pattern is recognizable to anyone who's been through a failed pilot. The deposit-as-prepaid-year-one-ACV reframe is the exact kind of tactical reframe a burned founder needs.
+
+### Gaps found
+
+| Gap | Chapters affected | Severity |
+|---|---|---|
+| No explicit "you've been burned before, here's what to do differently" framing in M2 | M2.1, M2.2, M2.3, M2.4 | Medium |
+| No "If you're reading this because your devshop just ghosted you" emergency entry point in-chapter | All | Low (landing page handles this) |
+| M2 chapters assume trust in the validation process that a burned founder may not have | M2.1, M2.2 | Medium |
+| M4.4 (Ceiling Signals) uses technical diagnostic language; a burned founder may not trust their own ability to evaluate | M4.4 | Low |
+
+### Module-level scores
+
+| Module | Score | Notes |
+|---|---|---|
+| M1 (Hypothesis & Smoke-Test) | **8/10** | Strong gates, specific numbers. Could use one "burned founder" callout in 1.2. |
+| M2 (Validate) | **7/10** | Weakest module for this persona. Assumes trust in the process. |
+| M3 (Spec & Shape) | **9/10** | Spaceship analogy + peer QA rubric = perfect for the burned founder. |
+| M4 (Build) | **9/10** | Ownership checklist + GitHub sync rule + ceiling signals = comprehensive safety net. |
+| M5 (First Paying Customer) | **9/10** | DPA as commitment device + paid-pilot math = the burned founder's playbook. |
+
+---
+
+## Perspective 2: First-Time Founder (Never Built Anything)
+
+**What they need**: Every technical term explained in plain English on first use. No assumptions about prior knowledge. Step-by-step instructions they can follow without a co-founder. Tool names linked to what they do, not what they are.
+
+### What works well
+
+- **M4.3 (Self-Serve Stack)** has a "What each tool does (in plain English)" section with a 3-row table: Lovable = UI, Supabase = Data, Stripe = Money. A first-timer can hold this in their head through the entire build. The chapter also distinguishes the Ch 2.4 throwaway prototype from the M4 production MVP — two different Lovable activities, not one polished into the other.
+
+- **M1.1 (Founding Hypothesis)** defines "ICP" in parentheses on first use: *"your ICP — ideal customer profile, the specific person you're building for."* The Mad Libs template makes hypothesis-writing concrete rather than abstract.
+
+- **All chapters** open with an Input/Output callout box. A first-timer can read the Input (what they need before starting) and Output (what they'll have after) and decide whether they're ready for this chapter.
+
+- **M3.2 (Outcomes not Features)** uses the *When / I want / So I can* template. The three-part shape is repeated, explained, and demonstrated with two worked examples. The "admin panel spaceship" SVG makes the overbuild consequence visual.
+
+- **M2.2 (AI Persona)** provides exact copy-pasteable prompts with placeholder annotations. A first-timer doesn't need to understand prompt engineering — they paste, fill blanks, and run.
+
+- **M5.4 (Paid Pilot)** explains LOI and ACV on first use. The Stripe Checkout setup is described as "15 minutes, no engineer" — the exact promise a first-timer needs to hear.
+
+### Gaps found
+
+| Gap | Chapters affected | Severity |
+|---|---|---|
+| M4.3 rapid-fires "REST API," "JavaScript client," "Stripe webhook," "Supabase RLS" in close succession within the tool descriptions section | M4.3 | Medium |
+| M3.2's mermaid flowchart syntax in raw markdown could confuse a non-technical reader who views page source | M3.2 | Low |
+| M5.4 defines ACV and LOI 4-5 paragraphs apart; a first-timer may forget the first by the time they reach the second | M5.4 | Low |
+| No chapter has a "What you need to know before this chapter" prerequisite list beyond the Input callout | All | Low |
+
+### Module-level scores
+
+| Module | Score | Notes |
+|---|---|---|
+| M1 (Hypothesis & Smoke-Test) | **8/10** | Clear, well-scaffolded. The 6-step sprint is the right granularity. |
+| M2 (Validate) | **8/10** | AI persona chapter is the strongest — exact prompts, no ambiguity. |
+| M3 (Spec & Shape) | **7/10** | Good examples but the mermaid diagrams assume comfort with technical diagrams. |
+| M4 (Build) | **7/10** | Tool-name density is the main friction. "Ship plan" phases are well-structured. |
+| M5 (First Paying Customer) | **7/10** | Good plain-English finance. ACV/LOI spacing is the only issue. |
+
+---
+
+## Perspective 3: Skim-First Founder (Time-Poor, Scrolls H2s)
+
+**What they need**: Headings that tell the full story. Bold numbers the eye catches on a fast scroll. Visually distinct callouts for critical information. A way to find the action without reading the context.
+
+### What works well
+
+- **H2 headings are consistently scannable across all 18 chapters.** A founder can scroll through: *"Don't Talk to Anyone Without a Hypothesis,"* *"Why free pilots almost never convert,"* *"The three-part shape that constrains every spec"* — and understand the chapter's argument without reading a single paragraph. This is the course's strongest ICP-aligned feature.
+
+- **Bold numbers punch through on scroll.** `$500-$3K`, `2.9% + $0.30`, `≥14 of 20`, `10 weeks, $40K`, `2% test coverage` — the eye catches the data points. The "Christmas tree" rule from the voice guide (one bold anchor per paragraph) is consistently applied.
+
+- **Blockquote callouts** (AI critic blocks, Pass 7 navigation callouts, budget anchors) are visually distinct in the rendered output. A skimmer can spot "Module X AI critic/simulator block" or "Budget anchor before you start" and decide to engage or skip.
+
+- **Tables are used for comparison, not data dumps.** The "Free pilot vs Paid pilot" section, the Feature-vs-Outcome pairs, the Inside/Outside envelope table — all scannable.
+
+- **The Input/Output callout** at every chapter top gives a skimmer the essential: "Do I have the input? Is this output what I need?" in two lines.
+
+- **Pass 7 navigation callouts** (budget anchors, skim-instinct hints, fast-path exits) are placed before dense sections. A skimmer who hits the M4.2 5-minute self-check callout can skip the rest of the chapter. A skimmer who hits the M5.2 fast-path exit can skip a 15-minute worksheet.
+
+### Gaps found
+
+| Gap | Chapters affected | Severity |
+|---|---|---|
+| M4.3 is a long chapter; the AI critic block is buried after 12 dense rules | M4.3 | Medium |
+| No "TL;DR" or "60-second summary" at the top of any chapter | All | Medium |
+| M2.2's key insight (*"This chapter IS the AI simulator block"*) is at the bottom of the chapter | M2.2 | Low |
+| Chapter length varies significantly (M4.3 is ~3x longer than M3.2); no visual length indicator | All | Low |
+
+### Module-level scores
+
+| Module | Score | Notes |
+|---|---|---|
+| M1 (Hypothesis & Smoke-Test) | **9/10** | Best-served module for this persona. Compact, scannable. |
+| M2 (Validate) | **8/10** | Good headings. The AI persona chapter could use a top-of-page summary. |
+| M3 (Spec & Shape) | **8/10** | Before/after diagrams make the point without reading. |
+| M4 (Build) | **8/10** | The 12 rules are scannable but dense. 3 pre-flight rules callout helps. |
+| M5 (First Paying Customer) | **9/10** | Tables + section headers + conversation script = ideal skim format. |
+
+---
+
+## Perspective 4: Crisis-Mode Founder (Emergency, Needs Action Now)
+
+**What they need**: Diagnostic signals visible in the first 30 seconds. Skip-to-fix links. An escape hatch from prerequisites they haven't completed. Honest triage: "your problem is X, go to chapter Y."
+
+### What works well
+
+- **M3.2 (Outcomes not Features)** opens with the 47-button admin panel story and lands the diagnosis in paragraph 1. The browser-use agent confirmed: a founder in crisis can identify their problem (feature-bloat from vague specs) within 30 seconds of landing.
+
+- **M5.4 (Paid Pilot)** has a 15-second conversation script the founder can use immediately: *"Glad it resonates. Quick word on how I am setting up pilots..."* No softening, no context needed — just the words.
+
+- **M1.1 (Founding Hypothesis)** has a clear routing rule table at the end of the Magic Lenses section: *"Money lowest → your smoke test is about price. Customer lowest → your interviews are about whether the pain is real."* A crisis founder can jump to their specific pain and find the recommended action.
+
+- **M4.3 (Self-Serve Stack)** has "The ship plan" with 4 build phases. A founder who's mid-build can find their phase and check the demo criteria without reading phases 1-3.
+
+- **M4.2 (Ownership Checklist)** has the 5-minute self-check for Path 2 founders. A founder who panics about ownership can run the 5 checks in 5 minutes and skip the full chapter.
+
+- **The landing page** (`_index.md`) provides the primary non-linear entry point with module descriptions. A crisis founder can navigate from the landing page to the right chapter without reading M1-M5 in order.
+
+- **M4.4 (Ceiling Signals)** names 5 specific architectural break-points with thresholds. A founder whose app is breaking can match their symptoms to a signal and get routed to the right fix.
+
+### Gaps found
+
+| Gap | Chapters affected | Severity |
+|---|---|---|
+| No "Skip to the action" anchor links at the top of long chapters | M4.3, M1.1, M3.2 | High |
+| M2.2 assumes the reader has draft Mom Test questions from Ch 2.1; no fallback for skip-ahead readers | M2.2 | Medium |
+| The course relies on linear progression; no in-chapter "I'm at stage X, jump here" decision tree | All (except landing page) | Medium |
+| M2.1 (Mom Test) — not verified in full-read sample; based on chapter structure observed in browser-use scan, the script may be positioned after theory | M2.1 (unverified) | Low |
+
+### Module-level scores
+
+| Module | Score | Notes |
+|---|---|---|
+| M1 (Hypothesis & Smoke-Test) | **8/10** | Routing rule table is the crisis founder's best tool in this module. |
+| M2 (Validate) | **6/10** | Weakest module for crisis entry. Too many prerequisites assumed. |
+| M3 (Spec & Shape) | **9/10** | Instant diagnosis + before/after examples = crisis-ready. |
+| M4 (Build) | **7/10** | Ship plan phases help, but chapter length hurts. |
+| M5 (First Paying Customer) | **8/10** | Conversation script is copy-pasteable emergency tool. DPA template same. |
+
+---
+
+## Module Summary Matrix
+
+| Module | Burned | First-Time | Skim-First | Crisis | **Average** |
+|---|---|---|---|---|---|
+| M1 (Hypothesis & Smoke-Test) | 8 | 8 | 9 | 8 | **8.3** |
+| M2 (Validate) | 7 | 8 | 8 | 6 | **7.3** |
+| M3 (Spec & Shape) | 9 | 7 | 8 | 9 | **8.3** |
+| M4 (Build) | 9 | 7 | 8 | 7 | **7.8** |
+| M5 (First Paying Customer) | 9 | 7 | 9 | 8 | **8.3** |
+| **Overall** | **8.4** | **7.4** | **8.4** | **7.6** | **8.0** |
+
+### Score interpretation
+
+- **8.0-10**: Chapter is well-tailored to this persona. Minor improvements possible.
+- **6.0-7.9**: Chapter serves the persona but has measurable friction. 1-2 fixes recommended.
+- **Below 6.0**: Chapter is actively hostile or confusing to this persona. Redesign recommended.
+
+No chapter scored below 6.0. The lowest scores are M2 for Crisis (6.0) and M2 for Burned (7.0).
+
+---
+
+## What the Course Does Best (Cross-Perspective Strengths)
+
+1. **H2 headings tell the full story.** Across all 18 chapters, a founder can scroll headings and understand the argument. This serves skim-first, crisis, and burned founders simultaneously.
+
+2. **Input/Output callouts at every chapter top.** The first thing every founder sees — regardless of persona — is "Input: what you need before starting" and "Output: what you'll have after." No context required.
+
+3. **Specific numbers, not vague claims.** `$500-$3K`, `≥14/20`, `2.9% + $0.30`, `2% test coverage`, `48 hours`. The voice guide's rule (exact numbers over vague ranges) is consistently enforced. This builds trust with burned founders and gives first-timers concrete anchors.
+
+4. **Honesty about failure modes.** *"Lovable can drop the work,"* *"Skipping this is the #1 reason rescued founders cannot retrieve their source,"* *"Free pilots almost never convert."* The course names what can go wrong before it tells you what to do. This is the single strongest trust-building mechanic for the burned founder persona.
+
+5. **Copy-pasteable artifacts.** The DPA template, audit spreadsheet, outreach checklist, interview script, pre-interview email, polite-no email, follow-up email, skipped-twice message — all copy-pasteable. Serves crisis founders (who need them NOW) and first-timers (who don't know how to write them).
+
+6. **Pass 7 navigation callouts.** The budget anchors, skim-instinct hints, fast-path exits, and pre-flight rule distinctions are an emerging content technique that serves all 4 personas. The pattern: brief box before dense section that (a) gives a fast-path exit, (b) names the cost/commitment upfront, or (c) distinguishes blocking rules from reference material.
+
+---
+
+## Top 3 Recommendations
+
+### 1. Add "Skip to the action" anchor links at the top of the 3 longest chapters
+
+**Chapters**: M4.3 (Self-Serve Stack), M1.1 (Founding Hypothesis), M3.2 (Outcomes not Features)
+
+**Why**: Crisis founders need to jump past context to the template/script/checklist. Skim-first founders want to confirm the action exists before committing to the read. Burned founders may already know the diagnosis and just need the fix.
+
+**What**: A small blockquote callout after the Input/Output box:
+```
+> **Jump to:** [The template](#the-founding-hypothesis-template) · [The sprint](#the-six-step-sprint) · [The PASS bar](#the-pass-bar) · [AI tools](#module-1-ai-criticsimulator-block)
+```
+
+**Effort**: ~15 minutes per chapter. Low risk.
+
+### 2. Add explicit "burned founder" acknowledgment in Module 2
+
+**Chapters**: M2.1 (Mom Test), M2.2 (AI Persona Pre-Validation)
+
+**Why**: Module 2 is the weakest module for the burned founder (7/10). It assumes trust in the validation process that a founder who lost money to a devshop may not have. A single empathetic callout per chapter would bridge the gap.
+
+**What**: Read M2.1 and M2.2, identify the optimal insertion point in each (likely after the Input/Output callout but before the first instructional section). Add a blockquote callout modeled on M5.4's tone:
+```
+> **If you've been burned before:** The validation process below will feel slow compared to building. That's the point. Your last project skipped validation and shipped into silence. These 10 interviews are the cheapest insurance you'll buy against repeating that pattern.
+```
+
+**Effort**: ~15 minutes per chapter (includes read + placement decision). Low risk.
+
+### 3. Add a 2-3 line TL;DR after the Input/Output callout — phased rollout
+
+**Chapters**: All 18 (recommend phased: 5 chapters first, validate with browser-use, then remaining 13)
+
+**Why**: Serves skim-first, crisis, and burned founders simultaneously. A founder who reads only the Input/Output + TL;DR + headings should have enough signal to decide whether to read the full chapter. The phased approach matches the Pass 5 fanout pattern from the previous sweep.
+
+**What**: After the Input/Output callout:
+```
+> **In 30 seconds:** [One sentence: what you'll do in this chapter.] [One sentence: why it matters.] [One sentence: the deliverable.] [One sentence: where it goes next.]
+```
+
+**Effort**: ~5 minutes per chapter. Medium risk (needs voice review to maintain tone). Phase 1: 5 chapters, browser-use verification, then fan out to remaining 13.
+
+---
+
+## What Was Verified
+
+| Method | Scope | Result |
+|---|---|---|
+| Content analysis (full read) | 5 representative chapters (M1.1, M2.2, M3.2, M4.3, M5.4) | All 5 passed all 4 persona lenses |
+| Browser-use visual inspection | 5 key pages (M1.1, M2.2, M3.2, M4.3, M5.4) | Zero console errors, all callouts render correctly, scannable headings confirmed |
+| HTTP status verification (curl) | All 18 chapters + landing page + operating kit | 200 OK on all pages |
+| Hugo build | Full site | Build succeeds (5733ms) |
+| `bin/validate-course` | All 18 chapters | All 7 validators pass |
+| `bin/rake test:critical` | Ruby test suite | Pre-existing Selenium infrastructure issue (unrelated to content) |
+
+---
+
+## Pattern Observations
+
+1. **M4 is the most variable module** (7-9 across personas). The tool-name density serves the burned founder (who recognizes the names) but creates friction for the first-timer. The ship plan phases help crisis founders but the chapter length hurts skim-first readers.
+
+2. **M2 is the weakest module for non-linear entry.** It's designed to be read in sequence (2.1 technique → 2.2 rehearsal → 2.3 recruitment → 2.4 prototype). A crisis founder who jumps to 2.3 without 2.1 gets stuck. A burned founder who jumps to 2.2 without 2.1 gets confused.
+
+3. **The Pass 7 navigation callout pattern is the course's most effective ICP-aligned technique.** These brief boxes before dense sections — budget anchors, skim-instinct hints, fast-path exits, pre-flight rule distinctions — serve all 4 personas. They should be the template for future reader-experience improvements.
+
+4. **The voice guide is working (manual observation).** Across all 5 chapters read in full, no banned words/phrases were observed in manual review (note: a programmatic banned-word scan was not run — `bin/validate-course` checks em-dashes but not the full banned-word list). Specific numbers were used over vague claims. Empathy was shown through concrete stories, not performative language. The "who test" (who is doing what?) passed consistently — failures were discovered by someone, features were built by someone.
+
+---
+
+## Related Documents
+
+- `docs/90-99-content-strategy/strategy-analysis/90.10-icp-primary-website-target.md` — Canonical ICP definition
+- `docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md` — Canonical voice rules
+- `docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.04-execution-readiness-sweep-2026-06.md` — Previous sweep (Pass 1-7)
+- `docs/projects/2605-tech-for-non-technical-founders/TASK-TRACKER.md` — Remaining post-ship tasks
diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.06-sam-customer-journey-report-2026-06.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.06-sam-customer-journey-report-2026-06.md
new file mode 100644
index 000000000..fce244236
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.06-sam-customer-journey-report-2026-06.md
@@ -0,0 +1,1096 @@
+# 40.06 — Sam's Customer Journey Through the Course (ICP-as-Reader)
+
+**Status:** Complete
+**Date:** 2026-06-04
+**Author:** Buffy (AI agent)
+**Type:** Customer journey report — single-ICP perspective
+**Commits:** N/A (review only, no content changes)
+**Chapters reviewed:** 18 (1.1–5.5) + course landing page
+**ICP document:** `docs/90-99-content-strategy/strategy-analysis/90.10-icp-primary-website-target.md`
+
+---
+
+> ## ⚠️ Corrigendum (2026-06-11): ICP conflation in this report has been corrected elsewhere
+>
+> This report (originally 2026-06-04) treats Sam as the ICP persona "Alex" from `90.10` — a post-burn founder who spent $80K with a devshop. **That conflation was an error.** The 2605 course has ONE ICP: **Sam, a first-time non-technical founder with no PM background, no tech expertise, and NO burn history.** The course exists to PREVENT Sam from becoming Alex.
+>
+> **For the corrected Sam profile, read these instead:**
+> - **Canonical profile**: `~/.claude/projects/-Users-pftg-dev-jetthoughts-github-io/memory/feedback_course_icp_sam_profile.md` (single source of truth)
+> - **Sam reading session simulation** (per-pilot beat-by-beat reactions): `40.11-sam-simulation-pilot-lessons-2026-06.md`
+> - **PRD**: `.agent/prd/PRD.md` (formal product requirements, references corrected Sam)
+>
+> **What still stands in this report:**
+> - The trust-curve methodology and per-chapter trust scores (they measure ICP-fit, which survives the correction)
+> - The friction analyses (mobile clipping, wide tables, navigation gaps — observation-based, not persona-bound)
+> - The 3-entry-points framing (Door 1 = Sam idea-stage path; Doors 2-3 describe Alex's path, which is the website rescue side-path, not the course bodies)
+>
+> **What does NOT stand:**
+> - The "$80K devshop" history attributed to Sam (line 22) — that's Alex
+> - The "shame → relief" emotional arcs (post-burn) — Sam's arcs are "intimidation → relief" (first-timer)
+> - Sentences attributing burn-trauma quotes to Sam ("Last time I spent $80K and 14 months...") throughout per-chapter analyses
+>
+> Read this report as a useful **methodology + trust-score reference**; recalibrate the emotional framing to first-timer-Sam (per the corrected docs above) when applying findings to Phase 2 lesson design.
+
+---
+
+## Who Sam Is
+
+Sam is the ICP persona "Alex" from `docs/90-99-content-strategy/strategy-analysis/90.10-icp-primary-website-target.md` — rendered here through the emotional arc of a founder reading the course linearly. The name "Sam" is used throughout this report for readability; cross-reference the ICP document under "Alex" for the canonical persona definition.
+
+| Attribute | Detail |
+|---|---|
+| **Role** | Founder & CEO, B2B SaaS |
+| **Age** | 38 |
+| **Tech literacy** | Can read a Stripe invoice, cannot read a GitHub commit |
+| **Burn history** | Spent $80K and 14 months with a devshop. Test coverage: 2%. AWS root email: the agency owner's personal Gmail. |
+| **Current state** | Has runway, has an idea, has distrust. Has not validated anything yet. |
+| **Emotional load** | Shame ("I should have known better"), fear ("what if they're lying again?"), urgency ("6 months of runway left"), distrust ("all dev shops are the same") |
+| **Decision authority** | Sole decision-maker. No board approval needed for <$50K. |
+| **Reading mode** | Skim-first, time-poor. Reads H2 headings on phone during commute before committing to a chapter. Wants specific numbers, not vague promises. Mermaid diagrams and wide tables may be clipped on a 375px viewport. |
+| **Trust trigger** | "This person has seen my exact failure mode before and names it without judgment." |
+| **Trust killer** | Jargon without explanation. Vague claims. Performative empathy ("we understand how frustrating this must be"). |
+
+---
+
+## Sam's Entry Points
+
+Sam can arrive at the course through three doors:
+
+### Door 1: Idea-stage founder (primary path)
+Sam has an idea, a half-built MVP, and no validation. He reads the course landing page (`_index.md`), sees the five rescue-case mistakes listed in the "Why this course exists" section, and recognizes **mistake #1** ("Hiring a dev shop before validating the problem") as his own biography. The empathy lands: *"You're at the start of the same road they were, and this course is the route around each one."*
+
+**Emotional beat:** Recognition → relief. Someone has catalogued his failure mode before he repeated it.
+
+### Door 2: Active-crisis founder (side path)
+Sam is currently paying a devshop, sees Jira tickets moving but no working product. He lands on the course page, scrolls past the module index, and hits "If Your Team Is Already Failing" — a 5-step emergency checklist. Step 1 is "Check who owns GitHub, AWS, database, and domain." Sam checks. The AWS root email is `dev@theiragency.com`. The course just diagnosed his hostage situation in 45 seconds.
+
+**Emotional beat:** Panic → focused anger → "I can fix this."
+
+### Door 3: Post-MVP founder (skip-ahead)
+Sam shipped a Lovable MVP, has 40 users, zero paying customers. He skips Modules 1-4 and enters at Module 5. The "Under 40%" diagnostic in Chapter 5.1 tells him whether he has a product problem or a marketing problem before he spends a dollar on ads.
+
+**Emotional beat:** "I was about to burn $4,200 on Meta ads" → "Let me run this 90-second survey first."
+
+**This report follows Door 1 — the linear path from idea to first paying customer.**
+
+---
+
+## The Landing Page: Sam's First Touchpoint
+
+Before Sam reads a single chapter, he lands on `_index.md`. This is the pre-journey artifact that determines whether Sam starts at all.
+
+**What Sam encounters:** A hero section with the course title, a "Why this course exists" section listing 5 rescue-case mistakes, a "Take this course if" / "This is not for you if" filter, a module index, and an "If Your Team Is Already Failing" side-path.
+
+**Sam's emotional arc:**
+1. Reads the 5 mistakes: *"Hiring a dev shop before validating the problem."* — *recognition* — "That's mistake #1. They've catalogued exactly what I did wrong."
+2. Reads: *"Reading this course should keep you out of those five failure modes. That is the point."* — *trust* — "They're not selling me a service. They're selling prevention."
+3. Reads "Take this course if": *"You can read a Stripe invoice but not a GitHub commit."* — *relief* — "They know who I am. I'm not supposed to be technical."
+4. Reads "This is not for you if": *"You want to learn to code" / "You want to outsource founder judgment."* — *boundaries* — "They're telling me what this ISN'T. That's honest."
+5. Reads the "If Your Team Is Already Failing" side-path: 5 steps, Step 1 is "Check who owns GitHub, AWS, database, and domain." — *urgency* — "I need to check this tonight."
+6. Reads the "How this is different from Y Combinator / Lenny / Reforge" callout. — *differentiation* — "They're not claiming to replace YC. They're claiming to fill a gap YC doesn't cover."
+
+**What works for Sam:**
+- The "Why this course exists" section names 5 specific, expensive failure modes. Sam recognizes himself in at least 3.
+- The "Take this course if / This is not for you if" filter is a gate that excludes the wrong audience. Sam feels selected, not sold to.
+- The "How this is different" callout names competitors (YC, Lenny, Reforge) and claims differentiation on three specific chapters. This is confident without being arrogant.
+- The "If Your Team Is Already Failing" side-path is an emergency exit for crisis-mode founders. Sam may not need it, but knowing it exists is reassuring.
+- The module index has clear Output statements per module and "Start here if" routing. Sam can self-diagnose where to enter.
+
+**What risks losing Sam:**
+- The page is long. Sam may scroll past the module index without reading the Output statements.
+- The "Going further" section (8+ continuation chapters) may overwhelm Sam. "I haven't even started and there's already a sequel?"
+
+**Mobile experience:** The module index with nested lists and the "If Your Team Is Already Failing" section may require horizontal scrolling on a phone. Mermaid diagrams don't render on the landing page, so no mobile issues there.
+
+**Landing page trust score: 8.5/10.** The 5-mistake catalog earns trust. The ICP filter ("can read a Stripe invoice but not a GitHub commit") is the right self-selection mechanism. The page is slightly too long for a phone read.
+
+---
+
+## Module 1: Hypothesis & Smoke Test
+
+### Chapter 1.1 — Form Your Founding Hypothesis (90-minute sprint)
+
+**What Sam encounters:** A Mad Libs sentence template: *"If we help [customer] solve [problem] with [approach], they'll choose it over [competition] because [differentiation]."* Five blanks. One sentence.
+
+**Sam's emotional arc:**
+1. "A Mad Libs? This feels like a worksheet from a $2,000 workshop. I don't have time for worksheets." — *skepticism*
+2. Reads the Gmail example: *"If we help heavy email users find old messages with full-text search and a gigabyte of storage, they will choose it over Yahoo Mail because Yahoo charges for storage and has no real search."* — *curiosity* — "Oh. That's specific. I can picture the product from the sentence alone."
+3. Reads the chiropractor billing example: *"If we help solo chiropractors solve insurance-claim resubmission with a one-click resubmit, they pick it over billing services that take 14 days and charge 8% of recovered claims."* — *recognition* — "That's a real business. That founder sounds like me."
+4. Hits the PASS bar: ≥14 of 20 across four lenses, no individual lens below 2. — *relief* — "There's a number. I don't have to guess whether my hypothesis is 'good enough.'"
+
+**What works for Sam:**
+- The Mad Libs format is the opposite of a blank page. Sam has stared at blank Notion docs for weeks. Five blanks is the right number.
+- The PASS bar (≥14/20, no lens below 2) gives Sam a gate he can measure against. Non-technical founders live in fear of "you'll know it when you see it" — this chapter gives a number.
+- The "smell test" — read the sentence aloud to someone not your co-founder — is a concrete, 30-second action Sam can do tonight.
+- The Magic Lenses scoring (Customer, Pragmatic, Growth, Money) translates "is this a good idea?" into four questions Sam can answer without technical knowledge.
+- The HealthTech founder example (weeks of interviewing without a hypothesis → back to write the sentence) is Sam's biography. Sam has done this.
+
+**What risks losing Sam:**
+- The sprint is billed as "90 minutes" but has six steps, four-column notebook grids, and a kitchen timer. Sam may feel this is a workshop, not a chapter, and bounce to "just do it in my head."
+- **Mitigation:** The chapter explicitly says "Software gets in the way of this sprint. Print it, run the timer, fill in by hand." The physicality is the point, but Sam needs to trust that before he commits 90 minutes.
+
+**Sam's output:** A one-sentence Founding Hypothesis he can read aloud without embarrassment. Sam walks away feeling like he has a compass, not a map — but a compass is enough for Module 1.
+
+**Mobile experience:** The four-column notebook grid and Magic Lenses scoring table require horizontal scrolling on a phone. The Mad Libs template renders fine. Sam should read this chapter on desktop for the notebook exercise.
+
+**Trust score: 8/10.** (Recalibrated — see Appendix D for methodology.) No jargon. Specific numbers. A gate (≥14/20). The 6-step sprint feels longer than "90 minutes" on first read. Sam trusts the output more than the process.
+
+---
+
+### Chapter 1.2 — Smoke-Test the Hypothesis: The Demand Test
+
+**What Sam encounters:** A 7-day test: build a landing page, buy $300-600 of cold traffic, read the conversion rate against a decision table.
+
+**Sam's emotional arc:**
+1. Opens the chapter. First thing he sees: *"Budget anchor before you start. Smallest viable smoke-test budget is $300-$600."* — *relief* — "That's concrete. I can afford $300."
+2. Reads Priya's story: 14 interviews, 12 said "I would pay," 0.6% landing page conversion, $38,400 + four months lost. — *fear* — "That could be me. That WAS me last time."
+3. Reads the conversion-rate decision table: <3% = kill, 3-5% = iterate, 6-10% = promising. — *trust* — "There's a number for every outcome. Nobody is asking me to 'trust my gut.'"
+4. Reads the "Ad-account setup reality" callout: "Start Sunday evening, not Monday morning. Meta verification takes 24-48 hours for first-time users." — *gratitude* — "They thought of the thing I would have hit at 11pm on a Tuesday and rage-quit."
+
+**What works for Sam:**
+- The Priya story is the emotional anchor. Sam has lived this. The chapter doesn't say "don't trust interviews" — it says "here's a $38,400 lesson, learn it for $300."
+- The conversion-rate table gives Sam a decision for every outcome. No "it depends." Kill / iterate / advance — pick one.
+- The $300-600 budget anchor is honest. It doesn't pretend the test is free; it names the cheapest version.
+- The "Cap design effort hard" section tells Sam to ship the ugly version. Sam has spent three weeks tweaking a Carrd before. This chapter gives him permission to stop.
+- The tracking section (Microsoft Clarity + ad pixel) is concrete for a non-technical founder: "paste this snippet into your builder's custom code field." No terminal. No `npm install`.
+- Marcus's $480 lesson (ads ran before tracking was wired, got zero signal) is a specific, named failure Sam can picture happening to him tonight.
+
+**What risks losing Sam:**
+- The builder comparison table (Mixo / Manus AI / Durable / NeetoSite / Carrd / Framer) is decision fatigue for a time-poor founder. Sam needs ONE recommendation with a fallback, not six options.
+- **Mitigation:** The chapter says "Default: AI-generated from your hypothesis. Pick one and ship the page. Don't comparison-shop for a week." But the table is still six rows long.
+- The channel-by-ICP table (Meta for B2C, LinkedIn for B2B, Reddit for dev tools, Google for niche) assumes Sam knows which bucket he's in. If Sam's ICP is "mid-market ops managers at 50-200 person companies," he's between B2B and niche and doesn't know which row to pick.
+- **Mitigation:** The "B2B on a small budget" callout gives Sam three substitutes if LinkedIn is too expensive. This is the right safety net.
+
+**Sam's output:** A go / iterate / kill decision backed by real conversion data. Sam walks away with a number, not an opinion.
+
+**Mobile experience:** The six-row builder comparison table and the channel-by-ICP table require horizontal scrolling on a phone. The conversion-rate decision table renders fine. Sam will likely skim the builder table on mobile and make his choice on desktop.
+
+**Trust score: 6/10.** (Recalibrated — see Appendix D.) The Priya story earns trust, but the builder comparison table (6 options) and the channel-by-ICP table introduce decision fatigue. Sam may bounce to "I'll figure out the builder later" and never come back. The decision tables at the end (conversion rates) save the chapter.
+
+---
+
+### Chapter 1.3 — Price Your Hypothesis on the Smoke-Test Page
+
+**What Sam encounters:** Replace the email signup with a Stripe Payment Link (no code, 5-minute setup) to test whether anyone will actually pay.
+
+**Sam's emotional arc:**
+1. Reads Maya's story: 490 visits, 48 emails (9.8% conversion), zero paying customers, $62K spent. — *dread* — "That's the exact trap I would have fallen into."
+2. Reads the Stripe setup: "Dashboard → Payments → Payment Links → New link." Five steps. No code. — *surprise* — "I can do this. I have a Stripe account."
+3. Reads the "Heads-up: Stripe verification takes 1-3 business days" callout. — *gratitude* — "They warned me. If I skip this, I'm blocked on launch day."
+4. Reads the three-signal measurement: visit-to-form-fill (email curiosity) vs visit-to-Stripe-click (price intent) vs click-to-completion (checkout friction). — *clarity* — "12% emails + 1% Stripe clicks means my price is wrong. 4% emails + 4% Stripe clicks means I have a niche. These are different diagnoses."
+
+**What works for Sam:**
+- Maya's story is the mirror image of Priya's from 1.2. Together they form a pair: Priya proves demand signal isn't buying signal. Maya proves email signups aren't payment intent. Sam now has two failure modes named, not one.
+- The Stripe Payment Link setup is five steps with exact UI locations ("Dashboard → Payments → Payment Links → New link"). A non-technical founder can follow this without help.
+- The "What if people click but nobody completes the payment?" diagnostic (60 clicks + 3 completions = checkout friction; 6 clicks + 3 completions = strong price signal) gives Sam a reading he can act on without guessing.
+- The "Outcome framing" button copy pattern (*"Stop spending 4 hours on reconciliation — $97"*) is a specific tactical win Sam can apply in 30 seconds.
+- The anti-A/B-test rule: "Pick one pattern. Don't A/B test. 150 visits each isn't enough to distinguish 4% from 5%." Sam has been told to "always A/B test" by every growth thread on Twitter. This chapter gives him permission to ship one variant and read the result.
+
+**What risks losing Sam:**
+- The Stripe signup reality (bank account + tax ID + 1-3 day verification) is named upfront, but Sam might read it as "this is too complicated" and skip to Module 2 without price data. The chapter says "sign up TONIGHT" — this is the right urgency, but Sam has to trust that the 1-3 day wait is worth it.
+
+**Sam's output:** A price hypothesis with a measured click-to-payment signal. Sam now knows whether strangers will click AND whether they'll pull out a credit card.
+
+**Mobile experience:** The Stripe setup table (5 steps with UI locations) renders well on mobile. The two-signal measurement section is scannable. This is the most mobile-friendly Module 1 chapter.
+
+**Trust score: 7/10.** (Recalibrated — see Appendix D.) Maya's story and the Stripe setup are concrete wins. But Sam may read the Stripe verification delay (1-3 business days) as a blocker and skip the price test entirely. The chapter would benefit from a stronger "this is worth the wait" framing.
+
+---
+
+### Module 1 Exit — Sam's State
+
+Sam now has:
+- A one-sentence Founding Hypothesis with a PASS score (≥14/20)
+- A smoke-test landing page with real conversion data
+- A Stripe Payment Link with click-to-payment signal
+
+**Sam's emotional state:** Cautious optimism. He has real numbers. Nobody has asked him to trust his gut. The three chapters cost him ~$500 and two weeks. Last time he spent $80K and 14 months to learn less.
+
+**Sam's trust in the course:** High. The course has predicted his failure modes (Priya, Maya, Marcus) before he made them. It has given him numbers for every decision. It has never used the word "leverage" or "holistic."
+
+---
+
+## Module 2: Validate the Problem
+
+### Chapter 2.1 — The Mom Test: Ask About the Past, Not the Future
+
+**What Sam encounters:** Five interview questions that all anchor in past behavior ("Tell me about the last time...") instead of hypothetical-future ("Would you use a tool that..."). Plus a "two-pass" reading structure: Pass 1 teaches the technique, Pass 2 (after interviews are done) teaches synthesis.
+
+**Sam's emotional arc:**
+1. Opens the chapter. Sees: *"This chapter is read in two passes."* — *annoyance* — "I don't want to read a chapter twice. Just tell me what to do."
+2. Reads the ed-tech founder story: 11 interviews, 9 "yes I would absolutely use this," 3 signups, 2 churned by day 14. — *recognition* — "That's me. I've been that founder."
+3. Reads the "5 questions most founders ask instead" table. Every question in the left column is a question Sam has asked verbatim. — *shame → relief* — "I've been doing this wrong but the fix is on the same page."
+4. Reads Q4: "On a scale of 1-10, how big a problem is this compared to everything else on your plate?" and sees the polite-default-7 warning. — *paranoia* — "How many of my past '7' answers were polite?"
+5. Reads the three emotional-language flags (frustration, workaround, urgency). — *clarity* — "I don't have to guess. I listen for three specific word patterns."
+6. Scrolls to the bottom. Sees the Synthesis section: 3-step scoring, build/pivot/kill decision tree. — *anticipation* — "I can't use this yet but I know it's waiting."
+
+**What works for Sam:**
+- The ed-tech founder opener is the exact emotional hook Sam needs. "Eleven friendly conversations, zero useful data" is Sam's biography from his last venture.
+- The "bad question → why it fails → past-behavior rewrite" table is a before/after Sam can hold in his head. He doesn't need to learn theory; he needs to see which of his questions are broken.
+- The polite-default-7 warning: *"treat as a 5 until Q5 proves otherwise."* This is a specific, actionable rule that prevents Sam from rounding up his interview scores.
+- The three emotional-language flags with example phrases (*"I hate this," "Every single week," "I missed my kid's birthday because of this"*) give Sam a listening framework that doesn't require technical knowledge.
+- The "What to do tomorrow" section: print the script, take notes by hand (not typing), score within 5 minutes. Three actions. No ambiguity.
+
+**What risks losing Sam:**
+- The two-pass structure is the right design (Pass 1 = technique, Pass 2 = synthesis after interviews), but Sam may feel the chapter is "unfinished" on first read. The anchor link to the Synthesis section helps, but it's a chapter-design choice that asks Sam to trust the loop-back.
+- **Mitigation:** The explicit "You are now on Pass 1" and "You are now on Pass 2" headers, combined with the anchor link, make the structure visible. Sam knows what to do when.
+- The chapter length (this is the longest chapter in the course) could lose Sam on first skim. He'll scroll to the "What to do tomorrow" table and skip the mermaid diagrams.
+
+**Sam's output:** A 5-question interview script, a scoring rubric, and a draft question list (5-8 questions). Sam hasn't run any interviews yet — but he knows which of his existing questions are broken.
+
+**Mobile experience:** The 5-question table and the bad-question/rewrite comparison table require horizontal scrolling on a phone. The mermaid interview flow diagram may not render on small screens. Sam will likely read the "What to do tomorrow" section on mobile and deep-read the technique on desktop.
+
+**Trust score: 5/10.** (Recalibrated — see Appendix D.) The Mom Test technique is bulletproof, but the two-pass structure and the chapter's length make it the second hardest chapter for Sam to trust on first skim. The ed-tech founder story is the right opener, but Sam may bounce when he sees "This chapter is read in two passes." The polite-default-7 warning is brilliant, but it's buried 40% of the way down the page.
+
+---
+
+### Chapter 2.2 — Sharpen Your Question List with AI Personas
+
+**What Sam encounters:** A 90-minute rehearsal session: build 3 ICP personas in Claude, test each draft question in-character, get an out-of-character diagnosis, surface the top 3 objections, sharpen weak questions.
+
+**Sam's emotional arc:**
+1. Sees the chapter title: "Sharpen Your Question List with AI Personas." — *skepticism* — "AI personas? Is this a gimmick?"
+2. Reads the founder story: 5 interviews, 3 polite yes-es, almost pivoted, ran AI rehearsal, found the broken question, rewrote it, next 5 interviews produced real pushback. — *intrigue* — "OK, there's a concrete result."
+3. Reads the persona setup prompt. It asks for [ROLE], [INDUSTRY], [COMPANY SIZE], [PROBLEM DESCRIPTION], [CURRENT WORKAROUND], [FREQUENCY], [DURATION], [BUDGET RANGE], [REASON]. — *recognition* — "These are the blanks from my Ch 1.1 hypothesis. I already have these answers."
+4. Reads the "Heads up" warning: "Claude is trained to be helpful, which means it tends to give reasonable answers even to broken questions. Read the out-of-character diagnosis instead." — *trust* — "They're telling me the failure mode of the tool. That's honest."
+5. Reads Prompt 4 (Objection Surface): "What would make you want to end this conversation early?" — *surprise* — "I never thought to ask that. The AI will tell me where my questions feel like a sales pitch."
+
+**What works for Sam:**
+- The "What AI can do vs what only real interviews do" table sets expectations before Sam invests time. "AI cannot prove whether your ICP description is accurate — only a real interviewee can correct you." This is the right honesty.
+- All placeholders in the prompts map directly to Sam's Ch 1.1 hypothesis blanks. No new research required.
+- The 3-persona rule (not 3 variations of the same person) prevents the rehearsal from becoming an echo chamber. Sam has to build genuinely different personas, which forces him to think about his ICP from multiple angles.
+- The Objection Tracker table (objection | which personas raised it | phrasing to listen for | showed up in real interviews?) is a deliverable Sam can print and put next to his interview script.
+- The "Failure signal" at the end: "If all 3 personas produce nearly-identical answers, your persona descriptions are too generic." This is a self-correcting mechanism.
+- Cost: $0. Free tier on Claude or ChatGPT. Sam doesn't need a paid plan.
+
+**What risks losing Sam:**
+- The chapter is labeled "Module 2 · Step 2 of 4." Sam may read it and think "I don't have time for an AI rehearsal — I just want to book interviews." The chapter argues that 90 minutes of rehearsal saves 5 wasted interview slots, but Sam has to trust that math before he invests.
+- If Sam's ICP description is wrong (he describes the wrong role, wrong company size), the entire rehearsal is miscalibrated. The chapter names this risk explicitly, which is the right defense.
+
+**Sam's output:** A sharpened question list (5-7 solid questions) + an Objection Tracker with the top 3 objections to listen for in real interviews.
+
+**Mobile experience:** The prompt templates render well on mobile (they're code blocks with short lines). The Objection Tracker table requires horizontal scrolling. This is a desktop-first chapter for the rehearsal session, but Sam can read the concept on his phone commute.
+
+**Trust score: 3/10.** (Recalibrated — see Appendix D.) This is the most skippable chapter. Sam is between "I just learned the Mom Test" (Ch 2.1) and "I want to book interviews" (Ch 2.3). A chapter about rehearsing with AI personas feels like a detour, not a step forward. The chapter earns its thesis logically but fails emotionally — Sam's impatience will override the 90-minutes-saves-5-slots math. Repositioning as an optional sidebar would increase Sam's trust in the course spine.
+
+---
+
+### Chapter 2.3 — Find 10 People With the Problem in 2026
+
+**What Sam encounters:** A 5-step outreach funnel: AI translates hypothesis into an ICP map → read where people are complaining → build a list of 30 specific people → write to each one about the post you read → 10 calls booked.
+
+**Sam's emotional arc:**
+1. Reads the consumer-app founder story: 60 LinkedIn DMs, 3 calls booked (two old colleagues being polite). Then: read Reddit threads, wrote to complainers by name, 12 calls booked by Thursday. — *hope* — "I don't have to beg my network. There's a better way."
+2. Reads the "Three sentences" requirement: Customer, Business, Solution. — *relief* — "I already wrote these in Chapter 1.1."
+3. Reads the AI ICP map prompt. It asks for his three sentences + two competitor URLs. — *confidence* — "I have these. The Ch 1.1 deep-research sidebar already gave me the competitor URLs."
+4. Reads the "What to write so they don't ignore you" section. Sees the first-draft message that every founder sends: "Subject: quick chat? Hi Marcus, I'm building a tool..." — *cringe → laughter* — "I have sent that exact message. 60 times."
+5. Reads the working 3-message sequence: Day 0 intro (specific reference), Day 3 bump, Day 7 close. — *relief* — "Copy-pasteable. I can do this tonight."
+
+**What works for Sam:**
+- The 60-LinkedIn-DMs failure story is the emotional opener. Sam has sent those DMs. The chapter says "your network is not the source — Reddit is" and Sam realizes he's been fishing in the wrong pond.
+- The AI ICP map prompt is a single paste. Sam doesn't need to learn prompt engineering. The `NOT FOUND` escape valve prevents hallucinations.
+- The "first-draft message" section — showing the broken version Sam would write, then explaining why each sentence dies — is the most effective teaching move in the entire course. Sam sees his own words on the page, then sees why they fail.
+- The working 3-message sequence is verbatim, with placeholders. Sam can copy it into Gmail tonight.
+- The "Slow-path variant for the part-time founder" callout acknowledges that Sam has a day job and evenings only. The batch-send alternative with real trade-off numbers (8-12% reply rate vs 20-30%) is honest.
+- The reply-rate bands (under 10% = rewrite subject line, 10-30% = let it run, 30%+ = move to Mom Test) give Sam a calibration point after the first batch.
+- The parallel tracks (cold outreach + research panel + smoke-test landing page) acknowledge that not every ICP is reachable via Reddit. The mermaid diagram makes the three-track structure visible.
+
+**What risks losing Sam:**
+- The chapter is long. Sam may skim to the message templates and skip the list-building methodology, which is the load-bearing step. The "Skim instinct" callout ("if you want the message template first, scroll to 'What to write so they don't ignore you' below") gives Sam permission to do exactly this — which is a smart design choice, but means Sam might never return to build the list properly.
+- The Apollo.io free-tier credit limits (roughly 10 export credits per month) may surprise Sam when he tries to export more than 10 contacts. The chapter names this, but Sam may not internalize it on first read.
+
+**Sam's output:** A list of 30 named people with verbatim sentences + a 3-message sequence ready to send.
+
+**Mobile experience:** The chapter is long. The 3-message sequence renders well on mobile (short code blocks). The mermaid flowchart (three parallel tracks) may not render. Sam will likely read the message templates on his phone and build the list on desktop.
+
+**Trust score: 7/10.** (Recalibrated — see Appendix D.) The "first-draft message" section is the emotional peak of Module 2 and the best teaching move in the course. But Sam may never reach it — he'll skim to the message templates and skip the list-building methodology, which is the load-bearing step. The chapter is too long for a skim-first reader.
+
+---
+
+### Chapter 2.4 — Build a Clickable Prototype
+
+**What Sam encounters:** Build a 3-screen throwaway prototype in Lovable. Show it to 5 of your strongest-signal Mom Test interviewees. Watch silently. Score pass/fail.
+
+**Sam's emotional arc:**
+1. Reads the founder story: 8 Mom Test interviews strong, built a real app over several weeks, 5 interviewees stalled on screen 2. — *alarm* — "Problem validated ≠ interface validated. I would have made this exact mistake."
+2. Reads: *"This is a research tool, not the start of your MVP. You will build 3 throwaway screens, show them to 5 interviewees, watch what they do without coaching, then archive everything."* — *relief* — "They're telling me to throw it away. That's permission to not polish."
+3. Reads the Lovable prompt template. Sees the worked example (transaction reconciliation tool for freelance bookkeepers). — *confidence* — "I can fill in these blanks. The example shows me the specificity level."
+4. Reads the "What most founders say first (and why it ruins the session)" section. — *cringe → laughter* — "I would have said every single one of those sentences."
+5. Reads the silent-observation script: *"I won't explain anything while you use it. Just start from Screen 1 and try to do what the screen is asking. I'll stay quiet."* — *discomfort → trust* — "Staying quiet while someone struggles with my thing is going to be painful. They're warning me it will be. That means they've done this before."
+
+**What works for Sam:**
+- The "This Is Throwaway" section is the most important paragraph in the chapter. Sam would otherwise try to polish the prototype into the MVP. The explicit warning prevents the #1 failure mode.
+- The "What most founders say first" section is the mirror of Ch 2.3's "first-draft message." Sam sees his own words, sees why they ruin the session, gets the correct script.
+- The Lovable prompt template with a filled-in worked example shows Sam the specificity bar. He can see what "good" looks like before he writes his own.
+- The pass/fail scoring (3 signals: gets to Screen 3, describes product accurately, first 3 clicks correct) gives Sam an objective gate. He doesn't have to interpret "did that go well?"
+- The common fixable failures (vocabulary fail, wrong first click, "what am I supposed to do?") give Sam a diagnostic toolkit for when sessions fail.
+- The closing vocabulary question: *"Describe in one sentence what that tool just did"* — the verbatim answer becomes the marketing copy in Module 3. Sam is collecting user language, not guessing.
+- The combined Module-2 decision matrix (Ch 2.3 interview signal × Ch 2.4 prototype signal) gives Sam a single table that tells him whether to proceed, iterate, or kill. This is the integration point Sam needs.
+
+**What risks losing Sam:**
+- Sam may skip this chapter because "I already validated the problem — why do I need a prototype?" The chapter earns its thesis with the founder story (8 strong Mom Tests, stalled on screen 2), but Sam has to read past the title to internalize this.
+- The 3-screen constraint may feel arbitrary to Sam. "Why can't I build 5 screens?" The chapter explains: "Each extra screen multiplies the build effort without sharpening the validation signal." This is the right reasoning, but Sam may not believe it until his first prototype session.
+
+**Sam's output:** A pass/fail log from 5 silent-observation sessions + verbatim "describe in one sentence" vocabulary.
+
+**Mobile experience:** The Lovable prompt template is a code block that renders well on mobile. The pass/fail scoring table is scannable. The silent-observation script section is too long for a phone read — Sam should read this on desktop before his first session.
+
+**Trust score: 4/10.** (Recalibrated — see Appendix D.) This chapter asks Sam to do the most emotionally difficult thing in the course (stay silent while someone struggles with his creation) AND to build a throwaway prototype he'll archive. Sam's resistance to both is high. The chapter earns its thesis but faces the steepest trust climb of any chapter. Sam will only do this if he deeply trusts the course by this point.
+
+---
+
+### Module 2 Exit — Sam's State
+
+Sam now has:
+- 10 scored Mom Test transcripts with a strong-signal count
+- A validated problem statement (one page) — IF 7+ strong signals
+- A pass/fail prototype log from 5 sessions
+- Verbatim user vocabulary for Module 3
+
+**Sam's emotional state:** Validated — or redirected. If 7+ of 10 interviews scored ≥7, Sam has the strongest signal he's ever had that the problem is real. If not, the kill/pivot/iterate decision tree gave him a clear next move. Either way, Sam didn't spend $80K to learn the answer.
+
+**Time invested:** 6-8 calendar weeks (evenings-only founder). This is the longest module in calendar time and the most emotionally demanding — Sam is talking to strangers, hearing "no," watching people struggle with his prototype. The course doesn't pretend this is easy.
+
+---
+
+## Module 3: Design from Evidence
+
+### Chapter 3.1 — The One-Page Product Brief (Vibe PRD)
+
+**What Sam encounters:** A 5-section template: Problem (copied verbatim from Ch 2.1 validated problem statement), User & Context, What You're Building, Success Metric, No-Go List. One page. 250 words max.
+
+**Sam's emotional arc:**
+1. Reads Sarah's story: 17 settings toggles in her admin UI, 12 had no backend code, 2 crashed on toggle. — *horror → recognition* — "That's my last product. The devshop kept adding toggles until the dashboard was a spaceship."
+2. Reads the template. Section 1 says: "Copied directly from your validated problem statement. Do not rewrite in your own voice." — *relief* — "I don't have to write it again. Just copy-paste."
+3. Reads the User & Context section example: *"A pre-seed founder, alone in their browser at 9pm on a Tuesday, finishing the week's bookkeeping."* — *clarity* — "This is the detail level. Not 'small business owners.' A specific person at a specific moment."
+4. Reads Section 5 (No-Go List): *"Not in v1: multi-currency support, multi-Stripe-account support, automatic recurring sync, a settings page, a billing dashboard, user roles and permissions..."* — *surprise* — "The no-go list is longer than the build list. That's how you prevent the spaceship."
+5. Reads the Vibe PRD vs Traditional PRD fork: "The 5-page document buries the one paragraph the builder needed. By page 3, the agent has skimmed past the no-go list and started building a settings page." — *recognition* — "Last time I sent a 12-page Google Doc. They built the settings page first."
+
+**What works for Sam:**
+- Sarah's 17-toggles story is the emotional anchor. Sam has been Sarah. The chapter diagnoses the cause: "Feature-shaped briefs produce 47-button admin panels."
+- Section 1 being copy-paste from the validated problem statement removes the blank-page terror. Sam has already done the hardest work (interviews). The brief inherits it.
+- The 250-word cap is enforced with a specific instruction: "If you spill past 250 words, the persona is too broad or the pain is too vague — revise the section that ran longest first." This is a concrete diagnostic, not an arbitrary limit.
+- The Vibe PRD vs Traditional PRD mermaid diagram gives Sam a visual fork. He can see that his audience (Lovable or a hired junior) needs the Vibe PRD, not the 10-page document.
+- The $1,000 Maven course comparison table is honest: "If you can sit alone for 2 hours and finish the brief from the page above, start here. The cohort buys structure, deadline, and stack depth." The chapter doesn't pretend the template replaces a $1,000 course.
+- The "What to do tomorrow" table: Block a focused session, read the brief aloud to one peer, paste into Lovable. Three steps. No ambiguity.
+
+**What risks losing Sam:**
+- The chapter references concepts from Ch 2.1 (validated problem statement) and Ch 2.3 (interview transcripts). If Sam skipped those chapters, the Section 1 instructions won't make sense. The chapter explicitly says "Input: a one-page validated problem statement" in the header, but Sam may have skimmed past that.
+- The mermaid diagram is useful for visual learners but may confuse Sam if he's reading on mobile. The text explains the same fork in prose, which is the right redundancy.
+
+**Sam's output:** A one-page Product Brief (Vibe PRD) with all 5 sections filled.
+
+**Mobile experience:** The mermaid Vibe PRD vs Traditional PRD fork may not render on mobile. The 5-section template with examples is long — Sam will scroll. The "What to do tomorrow" table is scannable. This chapter works best as a desktop read with the template open in a second tab.
+
+**Trust score: 7/10.** (Recalibrated — see Appendix D.) Sarah's 17-toggles story and the no-go list are load-bearing. The 250-word cap is the right constraint. But Sam may feel this chapter is "paperwork" between validation and building. He wants to open Lovable, not write a brief.
+
+---
+
+### Chapter 3.2 — Quality-check your brief: features to outcomes
+
+**What Sam encounters:** Rewrite Section 3 of the Ch 3.1 brief from feature nouns ("Build a CSV export button") to outcome-shaped job stories (*"When I prepare the weekly investor report, I want to grab the top 5 metrics in 30 seconds, so I can paste them into the deck before the 4pm call"*).
+
+**Sam's emotional arc:**
+1. Reads the opening: *"You sent your engineer (or your AI agent) a one-line spec: 'build a simple admin panel.' Ten weeks later you have an admin panel with 47 buttons, role-based permissions, an audit log, and a co-pilot AI assistant."* — *laughter → recognition* — "This is literally what happened to me last time."
+2. Reads the two before/after pairs (CSV button → copy-top-5-metrics button; CRM module → nightly Slack message). — *shock* — "The outcome shape produces a 30-line script in 2 days. The feature shape produces a 3-month CRM nobody uses. Same problem, different words, 100x cost difference."
+3. Reads the three-part shape: When [trigger context] / I want [internal motivation] / So I can [outcome]. — *clarity* — "I can do this. Each part forecloses a category of overbuild."
+4. Reads the pass/fail rubric: "The brief PASSES only if the peer's answer stays inside your scope AND your no-go list." — *apprehension* — "What if my peer names 5 things outside my scope?"
+5. Reads the AI critic block: "No peer available? Use Claude or ChatGPT as the peer. If Claude names 2+ items outside your no-go list, the brief failed quality-check." — *relief* — "I can run this tonight without waiting for a peer."
+
+**What works for Sam:**
+- The admin-panel-spaceship opener is the visual anchor of the entire course. The 47-button illustration + "10-week build, $15K" label is Sam's biography.
+- The two before/after pairs (CSV button, CRM module) with concrete time/cost estimates (*"6 weeks of work" vs "90 minutes"*) make the cost of vague briefs visible in dollars and hours.
+- The three-part shape (When / I want / So I can) is a template Sam can apply to every Section 3 line. It's not theory — it's a fill-in-the-blanks exercise.
+- The AI critic block gives Sam a peer substitute. This is a concrete, tonight-possible action. The prompt is verbatim, pasteable.
+- The "What AI cannot prove or substitute" section (whether scope solves the problem, whether a real contractor would interpret the same way) is the right honesty. The AI is a proxy, not a replacement.
+- The mermaid diagram (Feature brief vs Outcome brief, with time/cost labels) makes the cost of the choice visible at a glance.
+
+**What risks losing Sam:**
+- The *When / I want / So I can* template may feel like a writing exercise to Sam. "I already wrote Section 3 in Chapter 3.1 — why do I need to rewrite it?" The before/after pairs earn the rewrite, but Sam may skip if he's impatient to start building.
+- The chapter assumes Sam has a peer or access to Claude. If Sam has neither (no peer, no Claude account), he's stuck at the quality gate. The AI critic block handles the "no peer" case, but Sam needs to trust that Claude is an adequate substitute.
+
+**Sam's output:** A rewritten Section 3 in outcome-shape + a quality-check verdict (pass/fail).
+
+**Mobile experience:** The two before/after pairs (CSV button, CRM module) are scannable on mobile. The three-part shape (When/I want/So I can) renders well. The mermaid Feature-vs-Outcome flowchart may not render. The AI critic block is copy-pasteable on mobile.
+
+**Trust score: 7/10.** (Recalibrated — see Appendix D.) The admin-panel-spaceship opener is the best teaching moment in the course, and the before/after pairs with dollar/time estimates are brilliant. But Sam may resist the "rewrite Section 3" exercise — he already wrote it in Ch 3.1. The AI critic block is the right bridge for solo founders but requires Sam to have a Claude account.
+
+---
+
+### Module 3 Exit — Sam's State
+
+Sam now has:
+- A one-page Product Brief (Vibe PRD) with all 5 sections
+- An outcome-shaped Section 3 that passed quality-check
+- A no-go list that constrains overbuild
+- An audience-of-one fork (AI agent / junior / senior team)
+
+**Sam's emotional state:** Prepared. Sam has a document that prevents the failure mode he lived through last time. The no-go list is his insurance policy. The outcome-shaped feature list is his scope control.
+
+**Time invested:** Two focused sessions (Ch 3.1 brief + Ch 3.2 rewrite). This is the shortest module in the course.
+
+---
+
+## Module 4: Build It Yourself
+
+### Chapter 4.1 — Should You Hire? The 2026 Decision Tree
+
+**What Sam encounters:** A 5-question decision tree that routes to one of 4 build paths: validate without code, self-serve (Lovable + Supabase + Stripe), fractional CTO bridge, or hire a team.
+
+**Sam's emotional arc:**
+1. Reads the opening: *"Pre-seed founders hiring engineering before a single paying customer is confirmed is the most common build-decision mistake."* — *recognition* — "That was me. I hired a devshop before I had one paying customer."
+2. Reads: *"Self-serve with Lovable + Supabase + Stripe is the default for a non-technical founder in 2026."* — *surprise* — "The default is NOT hiring? I expected this chapter to tell me how to hire."
+3. Reads the Airbnb test: Carrd + Stripe checkout + Notion FAQ, sent to 35 ICP prospects. One afternoon. — *hope* — "I can do this. I already have the smoke-test page from Ch 1.2."
+4. Reads the B2B SaaS founder story: 5 annual contracts at $1,800 each via Stripe + Notion before writing a line of code. $9,000 pre-revenue, customer feedback loop running. — *ambition* — "That's the goal. Sell before you build."
+5. Reads the 5-question decision tree with the Jargon Glossary sidebar: "WebSockets = two-people-typing-in-the-same-doc behavior. NOT needed for single-user apps. Row-Level Security = Coach A sees only Coach A's rows." — *gratitude* — "They defined the scary words before they asked me to answer the question."
+6. Reads Q1: "Is the problem validated? 10+ Mom Test interviews + 2-5 pre-orders?" — *confidence* — "Yes. I have the interviews. I may not have the pre-orders yet, but the callout says 'Answer Q1 Yes if you completed Modules 1-3.'"
+
+**What works for Sam:**
+- The default verdict is "self-serve." Sam expected "hire a team" and braced for the cost. The chapter says "the default is building it yourself" and Sam exhales.
+- The Jargon Glossary sidebar **before** Q2 is the right design choice. Q2 asks about "WebSockets / real-time / multi-tenant data / SOC 2 / HIPAA / PCI" — terms that would scare a non-technical founder into guessing. The sidebar defines each one in plain English with concrete examples.
+- The Airbnb test is a specific, actionable alternative to building. Sam can run it this week for $200 instead of spending $30,000 on a devshop.
+- The 5-question decision tree with the mermaid flowchart gives Sam a visual path. He can trace his answers and see which box he lands in.
+- The Series-A off-ramp: *"Stop handing specs, start handing problems. If you crossed that line and you are still writing one-page briefs, you are paying senior engineering rates for junior product-manager work."* This is forward guidance for Sam's future self. He doesn't need it now, but he'll remember it when he hits Series A.
+- The "Already completed Modules 1-3?" callout on Q1 prevents Sam from routing back to Path 1 incorrectly. This is a self-referential design choice that rewards Sam for following the linear path.
+- The printable worksheet ([Build Path Decision Worksheet](/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/)) gives Sam a pen-and-paper artifact. No software required.
+
+**What risks losing Sam:**
+- The 4-path matrix (validate / self-serve / fractional CTO / hire) is conceptually dense. Sam may not internalize the differences on first read. The mermaid diagram helps, but Sam needs to trust that the 5 questions will route him correctly without understanding all 4 paths upfront.
+- The Fractional CTO path introduces a cost Sam wasn't expecting ($8-15K/mo). Sam may read this and think "the course is trying to upsell me." The chapter is clear that Fractional CTO is a bridge for founders who hit the ceiling, not the default recommendation.
+
+**Sam's output:** A 4-way build-path decision (almost certainly "self-serve") + a filled-in worksheet.
+
+**Mobile experience:** The 5-question decision tree with the mermaid flowchart is complex on mobile — the mermaid may not render. The Jargon Glossary sidebar is scannable. The 4-path matrix table requires horizontal scrolling. Sam should read this chapter on desktop for the worksheet.
+
+**Trust score: 7/10.** (Recalibrated — see Appendix D.) The Jargon Glossary sidebar is the single best accessibility feature in the course. The default-verdict-is-self-serve framing protects Sam from his hiring instinct. But the 4-path matrix is conceptually dense, and the Fractional CTO cost ($8-15K/mo) may alarm Sam.
+
+---
+
+### Chapter 4.2 — Who Owns Your GitHub, AWS, and Database?
+
+**What Sam encounters:** A 12-item audit: GitHub org owner, AWS root email, billing card, IAM admin, prod DB credentials, secrets store, backups, domain registrar, DNS, third-party API keys. Plus a 5-minute self-check for self-serve founders.
+
+**Sam's emotional arc:**
+1. Reads the health-tech rescue story: 14 months, $23K/month, 1,800 paying clinics, AWS root password in the agency owner's personal Gmail. Took six days to change the email. — *visceral dread* — "That's the exact hostage situation I'm afraid of."
+2. Reads the 5-minute self-check (for self-serve founders): 5 items, all start with "in your name." — *relief* — "I signed up for everything myself. I pass all 5. I can skim the rest."
+3. Reads the 2026 hostage situation pattern: "AI-augmented contractors spin up your entire infrastructure during the Cursor or Claude Code session on Day 1. They use whatever email was already logged in. Usually their own." — *alarm* — "This happens in 2026 with AI tools. Not just traditional devshops."
+4. Reads the AWS root account bad-vs-good pair: *Bad: `aws@bigdevshop.com`. Good: `aws@mycompany.com`, password in 1Password, MFA on phone.* — *clarity* — "I know exactly what to check. I know exactly what good looks like."
+
+**What works for Sam:**
+- The health-tech rescue story ($23K/month, six days for a password reset) is the emotional anchor. Sam feels the cost in his bones.
+- The 5-minute self-check for self-serve founders is the right filtering mechanism. Sam doesn't need to read the full 12-item audit if he signed up for everything himself. The chapter respects his time.
+- The 2026 hostage situation pattern (AI contractors using their own email during setup) is a contemporary threat Sam wouldn't have thought of. The chapter names a failure mode that's specific to the tools Sam is about to use.
+- The "What good looks like vs what bad looks like" pairs (AWS root email, prod DB password, domain registrar) give Sam a before/after for each zone. He can audit against the bad column tonight.
+- The recovery plan (Stop the bleeding → Extract the IP → Legal escalation) is a sequenced, concrete path for founders who fail the audit. The 7-day / 14-day cooperation windows give Sam a timeline.
+- The "Advanced" section (security audit reference — AWS Trusted Advisor, Prowler) is correctly positioned as optional. Sam doesn't need this yet.
+
+**What risks losing Sam:**
+- The chapter opens with a worst-case scenario (14 months of invoices, AWS hostage). Sam may feel this is fear-mongering if he hasn't been burned before. But Sam HAS been burned — so the fear is calibrated to his experience.
+- The acronym sidebar (IAM, MFA, WHOIS, ICANN) is helpful but Sam may glaze over if he's skimming. The definitions are short and concrete, which helps.
+
+**Sam's output:** A pass/fail audit result for 12 items. Sam either confirms he owns everything (self-serve path) or starts the recovery plan (hired-team path).
+
+**Mobile experience:** The 12-item audit table requires horizontal scrolling. The bad-vs-good side-by-side panels are visual-heavy — likely clipped on mobile. The 5-minute self-check (5-item list) is perfectly scannable. Sam will likely read the self-check on his phone and deep-read the audit on desktop.
+
+**Trust score: 8/10.** (Recalibrated — see Appendix D.) The health-tech rescue story ($23K/month, six days for a password reset) is the most visceral emotional anchor in the course. The 5-minute self-check is the right filtering mechanism for self-serve founders. Sam walks away knowing whether he's hostage or free. Minor friction: the chapter opens with a worst-case scenario that may feel like fear-mongering to founders who haven't been burned.
+
+---
+
+### Chapter 4.3 — The Self-Serve MVP Stack: Lovable + Supabase + Stripe
+
+**What Sam encounters:** A 4-phase build plan: Phase 1 (Lovable UI), Phase 2 (Supabase + auth), Phase 3 (Stripe + checkout), Phase 4 (staging URL + 5 ICP users). Plus an onramp phase for Module 5 handoff.
+
+**Sam's emotional arc:**
+1. Reads the $0 path callout: "Lovable free + Supabase free + Stripe (no monthly fee). A solo founder can start Module 4 on $0." — *surprise → relief* — "I can start without spending anything? I thought this would cost $200/month."
+2. Reads: *"This chapter starts FRESH from your one-page brief. You do NOT iterate the throwaway prototype from Chapter 2.4."* — *relief* — "They're telling me not to reuse the prototype. Good. I would have tried."
+3. Reads the "12 rules for a self-built PoC done right." Sees the "3 load-bearing pre-flight rules" callout. — *focus* — "I only need to internalize rules 1, 2, and 6 before I open Lovable. The others are inline reminders."
+4. Reads the "What each tool does (in plain English)" section: "Lovable - the UI layer," "Supabase - the data layer," "Stripe - the money layer." — *clarity* — "Three tools, three jobs. I can hold this in my head."
+5. Reads Rule 7: "Enable Row-Level Security on every Supabase table from day 1. RLS is the rule that says 'Coach A can only read Coach A's rows.'" — *alarm → gratitude* — "That sounds important. They gave me the SQL to self-test it."
+6. Reads the self-test SQL query for RLS: `SET ROLE authenticated; SET request.jwt.claims = ...; SELECT * FROM 
;` — *dread → determination* — "I don't understand SQL but they're giving me the exact query to paste. I can do this."
+7. Reads the Phase 4 exit criteria: "The MVP is 'done' only when ALL 5 lights are green." — *clarity* — "I know when to stop. I won't polish forever."
+8. Reads the Onramp phase: "Invite your Module 2 interviewees onto the live MVP by name." — *confidence* — "I already have their contact info. I can do this tonight."
+
+**What works for Sam:**
+- The $0 path callout is the single most important sentence for Sam's psychology. He's been burned by a devshop that cost $23K/month. The idea that he can start Module 4 for $0 is revolutionary. It removes the financial barrier to starting.
+- The "fresh from your one-page brief" instruction prevents the #1 failure mode (polishing the throwaway prototype into the MVP). Sam would have done this. The chapter explicitly forbids it.
+- The M2 prototype vs M4 MVP comparison table (2 hours vs days-to-weeks, no auth vs Supabase auth, no payment vs Stripe live) makes the difference concrete.
+- The "What each tool does (in plain English)" section with the 3-row table (UI / Data / Money) is the mental model Sam needs. He can explain the stack to a friend after reading this section.
+- The 12 rules with the "3 load-bearing pre-flight rules" callout prevents decision paralysis. Sam doesn't need to internalize all 12; he needs to nail rules 1, 2, and 6.
+- The self-test SQL for RLS is a concrete security check Sam can run without understanding SQL. The chapter gives him the exact query to paste and tells him what the result should be (ZERO rows).
+- The Phase 4 exit criteria (5 green lights) give Sam a finish line. Without this, he'd polish the MVP indefinitely.
+- The Onramp phase bridges Module 4 and Module 5. Sam's Module 2 interviewees become his first Module 5 users. The loop-back is the right design — it rewards Sam for running the interviews.
+- The "Communities that replace a co-founder" section (Lovable Discord, Indie Hackers, No Code Founders Slack) gives Sam a support system. He's building alone, but he's not isolated.
+- The "Calendar reality" callout: "An evening-only founder typically needs 10-12 weeks." — *honesty* — "They're not pretending this is a weekend project. 10-12 weeks is realistic."
+
+**What risks losing Sam:**
+- The chapter is the longest in the course. Sam will skim. The "How to read this list" callout (3 pre-flight rules + Phase 4 exit criteria) is the right mitigation.
+- The self-test SQL query may intimidate Sam even though the chapter gives him the exact query. He might skip it. The "End-of-Phase-2 micro-fail signal" (hand the staging URL to your spouse; if 2+ stall, the workflow is wrong) is a lower-friction alternative.
+- The post-launch cost table (Lovable Scale $100 + Supabase Pro $25 + Resend $35 + Sentry $26 + monitoring $14 = ~$200/month) may alarm Sam after the $0 path callout. The chapter positions this as "post-launch" which is honest.
+
+**Sam's output:** A live MVP at a custom domain with 4-6 active users.
+
+**Mobile experience:** This is the longest chapter in the course. The 12-rules list is scannable. The build phases table renders well. The SQL self-test query is intimidating on any screen. Sam will likely read the "3 pre-flight rules" callout on his phone and deep-read the build phases on desktop over multiple sessions.
+
+**Trust score: 5/10.** (Recalibrated — see Appendix D.) The $0 path callout is revolutionary for Sam's psychology. The plain-English tool descriptions are the right mental model. But the chapter's length and the SQL self-test query create the highest cognitive load in the course. Sam will skim, miss the load-bearing rules, and potentially ship an insecure MVP. The "3 pre-flight rules" callout is the right mitigation, but it's fighting against the chapter's sheer volume.
+
+---
+
+### Chapter 4.4 — Vibe Coding Done Right: 5 Ceiling Signals
+
+**What Sam encounters:** A monthly monitoring habit: 5 architectural ceiling signals (AI inference cost, data model complexity, real-time needs, auth complexity, compliance audit). "Two reds for 4+ weeks = graduate."
+
+**Sam's emotional arc:**
+1. Reads the morning scene: 47 paying coaches, dashboard takes 11 seconds, Stripe webhook fired twice, users landing on each other's data. — *recognition* — "This is what I was afraid would happen to my MVP."
+2. Reads: *"This chapter is a monthly review reference, not an action-today chapter."* — *relief* — "I don't have to do anything today. Bookmark and come back."
+3. Reads Signal 1 (AI inference cost): $2,200/month on OpenAI for 180 users at $19/month. Eight months of runway gone. — *alarm* — "I need to check my AI bills."
+4. Reads the 2-question decision: "Has any signal been firing for 4+ weeks? Is your runway > 6 months?" — *clarity* — "Two questions. I can answer these."
+5. Reads the "What to say to the customer this week" template for SOC2/HIPAA/PCI: a 3-sentence email that buys 60-90 days. — *gratitude* — "I would have ghosted the customer. This email template saves the relationship."
+
+**What works for Sam:**
+- "Not an action-today chapter" is the right framing. Sam just finished the MVP build. He doesn't need a new to-do list.
+- The 5 signals are ordered by when they become detectable (Signal 1 at Week 2-4, Signal 5 at Week 8-12+). Sam can monitor in the right sequence.
+- Each signal has the same shape: visible symptom → what's happening underneath → cost of leaving it alone → cost of addressing now. Sam can scan the headlines and deep-read the signals that match his stack.
+- The 2-question decision tree (Q1: signal firing 4+ weeks? Q2: runway > 6 months?) is simple enough that Sam can answer it on his phone during a coffee break.
+- The SOC2/HIPAA/PCI email template is a tactical win. Sam would have panicked and ghosted the customer. The template gives him a professional response.
+- The Shed → House → Skyscraper analogy (with the visual diagram) is the mental model Sam carries forward. His Lovable MVP is the shed. The ceiling signals tell him when to build the house.
+- The "What to bring to Vanta/Drata/Secureframe onboarding" callout repurposes Sam's existing artifacts (Ch 4.2 ownership audit, Ch 3.1 brief Section 1). This is cross-chapter integration done right.
+
+**What risks losing Sam:**
+- The chapter may feel like a "you're going to fail" message immediately after the MVP build. Sam is excited about his live product; the ceiling signals might read as premature pessimism.
+- **Mitigation:** The "monthly review reference" framing positions this as a recurring habit, not a today-problem. Sam can bookmark and ignore until his first paid users hit.
+
+**Sam's output:** A monthly ceiling-signal scorecard (first run after live MVP is up).
+
+**Mobile experience:** The 5-signal table is scannable on mobile. Each signal's breakdown (symptom → underneath → cost of leaving → cost of addressing) is long-form — Sam will deep-read on desktop. The 2-question decision tree is simple enough for a phone read.
+
+**Trust score: 5/10.** (Recalibrated — see Appendix D.) The "not an action-today chapter" framing is the right positioning, but the chapter arrives immediately after Sam's MVP launch triumph. It reads as "here's how your MVP will break" — which is technically correct but emotionally mistimed. Sam will bookmark and ignore, which is the intended behavior. The SOC2 email template and the Shed → House → Skyscraper analogy are the right takeaway.
+
+---
+
+### Module 4 Exit — Sam's State
+
+Sam now has:
+- A build-path decision (self-serve)
+- An ownership audit result (all green for self-serve)
+- A live MVP at a custom domain with 4-6 active users
+- A monthly ceiling-signal scorecard (bookmarked for later)
+
+**Sam's emotional state:** Accomplished. Sam shipped a working product without hiring anyone. Total cost: $0-25/month. Last time he spent $80K and 14 months for an MVP that didn't work.
+
+**Time invested:** 10-12 calendar weeks (evenings-only). This is the longest module in calendar time and the most technically demanding — but Sam never opened a terminal.
+
+---
+
+## Module 5: First Paying Customer
+
+### Chapter 5.1 — Your First Customer Is Not a Marketing Problem
+
+**What Sam encounters:** The Sean Ellis 40% test: survey your existing users with one question — "How would you feel if you could no longer use [product]?" If ≥40% say "very disappointed," you have a must-have user. If not, you have a product problem, not a marketing problem.
+
+**Sam's emotional arc:**
+1. Reads the SaaS founder story: $4,200 Meta ad spend, 0.4% conversion. Six weeks earlier, 40 beta users. Nobody opened the app twice. — *dread* — "That's exactly what I was about to do."
+2. Reads: *"The $4,200 bought her a number she could have gotten for free."* — *relief* — "I haven't spent anything on ads yet. I can run this survey first."
+3. Reads the "What your first-pass numbers will probably look like" callout: 2-3 "very disappointed" out of 6 = directional MAYBE, probably a sample-size problem, not a product problem. — *reassurance* — "If I get 2-3 out of 6, I'm not failing. I just need more users."
+4. Reads the 5 questions: Q1 (disappointment level), Q2 (who would benefit), Q3 (main benefit), Q4 (previous solutions), Q5 (job title + company size). — *clarity* — "5 questions. I can type this into Typeform in 10 minutes."
+5. Reads the "Under 40%" diagnostic table: wrong segment, not finished, pain is real but product isn't the relief, workflow too long. — *confidence* — "The survey doesn't just say yes/no. It tells me what to fix."
+
+**What works for Sam:**
+- The SaaS founder story ($4,200, 0.4%) is the emotional anchor. Sam was about to make this exact mistake.
+- The "first-pass numbers" callout sets realistic expectations. Sam won't panic if he gets 2-3 "very disappointed" on a 6-user sample.
+- The 5 questions are verbatim. Sam doesn't need to write survey questions — he types these in exactly.
+- The "Under 40%" diagnostic table gives Sam a treatment plan for each failure mode. He doesn't just learn he has a product problem; he learns which kind.
+- The "Sample-size honesty" section: "Under 10 respondents, treat as directional only." This prevents Sam from killing his product based on 8 responses.
+- The re-run cadence instruction: "Re-run while the must-have rate is climbing and after every major release." This turns the survey from a one-time test into a recurring health check.
+- The email template: "Quick 90-second question about [product]. No pitch. No follow-up. I read every response by hand." — Sam can send this tonight.
+
+**What risks losing Sam:**
+- Sam may be tempted to skip this chapter and go straight to outreach (Ch 5.3). "I have an MVP — I need customers, not surveys." The chapter earns its thesis with the $4,200 story, but Sam may rationalize: "That won't happen to me."
+- The segment-isolation math (pivot table by job title + company size) may feel like "spreadsheet work" to Sam. The chapter simplifies it to "export CSV, pivot on Q5," which is the right level of detail.
+
+**Sam's output:** A must-have-user persona with 3 verbatim quotes and one named segment to target — OR a product-problem diagnosis with a specific fix path.
+
+**Mobile experience:** The 5-question survey renders well on mobile (short text). The "Under 40%" diagnostic table requires horizontal scrolling. The segment-isolation Venn diagram may not render. Sam can set up the Typeform on his phone.
+
+**Trust score: 7/10.** (Recalibrated — see Appendix D.) The $4,200 Meta story earns the thesis. The 5 questions are verbatim and pasteable. But Sam may skip this chapter because "I need customers, not surveys." The 40% threshold is the right gate, but Sam's impatience to start selling may override the diagnostic.
+
+---
+
+### Chapter 5.2 — Choose Your Channel Before You Send One Message
+
+**What Sam encounters:** A channel-selection methodology: pull channel signals from your 10 interview transcripts, score each candidate channel on 4 dimensions (price, buyer type, time budget, interview signal), commit to one channel for 4 weeks, do not switch.
+
+**Sam's emotional arc:**
+1. Reads the HealthTech founder story: 6 weeks switching channels every 10 days, 8 conversations, zero paid pilots. Then: LinkedIn only, full send/reply/follow-up arc, 11 conversations, 2 paid pilots. — *recognition* — "I would have switched channels at the first silence."
+2. Reads the "Commitment rule" section: Send phase → Reply phase → Follow-up phase → Decision phase. — *clarity* — "I need to give each channel enough time to produce signal. Switching early is the failure mode."
+3. Reads the channel-fit scoring: 4 dimensions, 1-3 per dimension, ≥9/12 = clear pick. — *confidence* — "I can score channels objectively instead of going with my gut."
+4. Reads the 4-channel comparison table: LinkedIn DM, cold email, community outreach, social organic. Each row has "Best for / Requires / Red flag." — *clarity* — "I can see which channel fits my buyer type and my time budget."
+
+**What works for Sam:**
+- The HealthTech founder story (6 weeks of channel-hopping, zero results) is Sam's likely behavior pattern. The chapter names it and prevents it.
+- The interview-evidence approach: "Your 10 transcripts already contain the channel signal. Mark them." This repurposes work Sam has already done.
+- The channel-fit scoring (4 dimensions, 12-point total) is an objective framework Sam can use without marketing experience.
+- The "Commitment" section is a written contract with himself: *"I will not switch channels until I have run a full send/reply/follow-up arc."* Sam writes it down. The act of writing is the commitment device.
+- The Claude pressure-test prompt: "Paste your interview signals + channel hypothesis. Claude surfaces assumptions you missed." This is a 5-minute sanity check before Sam commits 4 weeks.
+- The "Fast-path exit" callout: "If 7+ of 10 interviewees named a channel, skip the worksheet and move to Ch 5.3." This prevents Sam from over-analyzing when the answer is obvious.
+
+**What risks losing Sam:**
+- Sam may feel this chapter is "too much process" after the excitement of the MVP launch. He wants to send messages, not fill in worksheets.
+- **Mitigation:** The fast-path exit and the Claude prompt let Sam skip the full worksheet if his interview evidence is clear.
+
+**Sam's output:** One channel hypothesis committed to for 4 weeks + a written commitment statement.
+
+**Mobile experience:** The channel-fit scoring table and the 4-channel comparison table require horizontal scrolling. The Commitment section (written contract) is scannable. Sam will likely skim the worksheet on his phone and fill it in on desktop.
+
+**Trust score: 3/10.** (Recalibrated — see Appendix D.) This is tied with Ch 2.2 as the most skippable chapter. Sam just launched his MVP and wants to send messages. A channel-selection worksheet with 4 dimensions and a 12-point scoring system feels like process overhead. The fast-path exit helps, but Sam's emotional state at this point is "let me sell" — not "let me fill in a worksheet." The channel-hopping prevention is the right insight; the delivery vehicle may be wrong for Sam's moment.
+
+---
+
+### Chapter 5.3 — The First Ten Come From People Who Already Know You
+
+**What Sam encounters:** Lenny Rachitsky's finding: ~60% of fast-growing B2B startups got their first 10 customers from personal network. A 50-name list sorted into 4 buckets (Champions, Hot, Warm, Cold). A 4-part message template (specific reference, one line on the problem, Loom video, specific ask).
+
+**Sam's emotional arc:**
+1. Reads: *"~60% of first customers came from the founder's personal network, ~35% from cold outbound, only 5% from inbound."* — *surprise* — "I was about to spend money on ads. The data says my network is the highest-probability source."
+2. Reads: *"The objection comes up in every founder call: 'I do not want to ask friends. It feels like begging.'"* — *recognition* — "That's exactly what I was thinking."
+3. Reads the reframe: *"You are not asking them to buy. You are asking them to be first to try something that solves a problem they already have, at a steep discount, while you fix the rough edges."* — *relief* — "That's not begging. That's a fair trade."
+4. Reads the network-size diagnostic: "Count your 1st-degree LinkedIn connections filtered by must-have segment." — *apprehension* — "What if I don't have 30+?"
+5. Reads the 15-29 band: "Reduced warm motion. 4-7 replies, 1-2 demos, 0-1 paid pilot. Warm motion alone will not close your first customer." — *realism* — "OK. I'll need cold outbound too. They're telling me upfront."
+6. Reads the 4-part message template with the Loom script source: "Lines 2-3 should be the Q2-Q3 verbatim quotes from Ch 5.1." — *integration* — "The survey from Ch 5.1 feeds directly into this message. I'm not starting from scratch."
+
+**What works for Sam:**
+- The Lenny Rachitsky stat (60/35/5) is the credibility anchor. Sam doesn't have to trust the course — he can check the source himself.
+- The "it feels like begging" objection is anticipated and reframed. This is the emotional blocker Sam needs to overcome.
+- The network-size diagnostic (30+ / 15-29 / under 15) prevents Sam from following the full 50-name structure when his network is too small. The 15-29 band explicitly says "you will need cold outbound in parallel" — this is the right honesty.
+- The 4-bucket structure (Champions, Hot, Warm, Cold) gives Sam a sorting system. He's not writing 50 unique messages — he's writing 4 templates with personalized first lines.
+- The Loom script source instruction (use Ch 5.1 verbatims) is cross-chapter integration at its best. Sam reuses work, doesn't start from scratch.
+- The "What the 'no' replies actually tell you" section (problem moved, buying motion wrong, you missed the brief) turns rejection into a diagnostic. Sam doesn't just get "no" — he gets a question to ask.
+- The "Hot bucket is where the conversions live" callout: "Hot names force you to articulate the value cleanly. That clean articulation is what closes the rest of your pipeline." This reframes the hot calls as pitch-sharpening, not just sales.
+- The champion-routed warm intro note: "Say yes immediately. Champion-routed warm intros convert at 3-4x the cold-warm conversion rate." Sam now knows to ask for intros.
+
+**What risks losing Sam:**
+- The 50-name list may feel like a daunting spreadsheet exercise. Sam might skip to the message templates without building the list.
+- **Mitigation:** The "Honest calendar" callout (60-90 min for list build, 8-12 hours for full send sequence) sets expectations. The "Slow-path variant" (single-evening batch-send) gives Sam a backup plan.
+
+**Sam's output:** 50 personalized outreach messages sent, with replies tracked in a spreadsheet.
+
+**Mobile experience:** The 4-bucket grid and the 4-part message template are scannable. The network-size diagnostic table is compact. The "What the 'no' replies tell you" section renders well. This is one of the more mobile-friendly Module 5 chapters.
+
+**Trust score: 8/10.** (Recalibrated — see Appendix D.) The Lenny Rachitsky 60/35/5 stat is the credibility anchor. The "it feels like begging" reframe is the exact emotional blocker Sam needs addressed. The network-size diagnostic prevents Sam from following a playbook that doesn't fit his network. The 4-bucket structure makes the 50-name list manageable. Sam walks away feeling equipped to sell.
+
+---
+
+### Chapter 5.4 — Charge Before You Ship: The Paid Pilot Contract
+
+**What Sam encounters:** A one-page Design Partner Agreement (DPA): 6 sections (scope, duration, deposit, success criteria, conversion, data/IP), a Stripe Checkout setup (15 minutes, no code), and a conversation script for asking for the deposit.
+
+**Sam's emotional arc:**
+1. Reads the HealthTech founder story: 6-week free pilot, 47 Slack messages of enthusiasm, "we'll revisit at the next budget cycle" email, no conversion. Second customer: $1,200 deposit at kickoff, year-one contract on day one. — *clarity* — "The deposit timing is the whole game. Week 0, not Week 8."
+2. Reads: *"After months of paying an agency, the muscle memory becomes 'everyone keeps asking me for money.' Asking your customer for money first feels like joining the side that hurt you."* — *visceral recognition* — "That's exactly the feeling. I've been on the paying side. Now I have to be the asking side."
+3. Reads the DPA structure: 6 sections, 400 words, one page. — *surprise* — "One page? I thought contracts were 20 pages with a lawyer."
+4. Reads the deposit math: 10-30% of year-one ACV, credited toward year-one. — *clarity* — "The deposit isn't extra cost. It's year-one revenue brought forward."
+5. Reads the conversation script: *"Quick word on how I am setting up pilots - I am running them as paid design partnerships. The deposit is [$500-$6K], credited toward year one. Refunded in full if I cannot deliver on the success criteria. Want me to send the one-pager?"* — *confidence* — "15 seconds. I can say this without stammering."
+6. Reads the "What if you cannot deliver by week 6?" response: *"If I do not hit two of the three success criteria, you get a 100% refund within 14 days and we walk."* — *trust* — "The refund promise is specific. 14 days. No negotiation."
+
+**What works for Sam:**
+- The HealthTech founder story (free pilot → ghost, paid pilot → conversion) is the emotional anchor. Sam has been the free-pilot founder. The chapter names the exact mechanic that kills free pilots (CFO never approved the line item).
+- The "asking your customer for money feels like joining the side that hurt you" line is the most emotionally honest sentence in the course. It names Sam's exact psychological blocker.
+- The DPA is one page. Sam has seen 40-page MSAs. One page is believable.
+- The deposit math: $500 minimum, $10K maximum without procurement. Sam can pick a number without guessing.
+- The conversation script is 15 seconds, verbatim. Sam doesn't need to improvise.
+- The "customer response" table (9 responses, 9 scripts) covers every objection Sam will hear. "Can we start free?" "Let me think about it." "Can you do net-30?" "My legal team needs to review." Each has a scripted response.
+- The Stripe Checkout setup: 5 steps, 15 minutes, no engineer. Sam can do this in his Stripe dashboard right now.
+- The three exceptions (champion conversion, true early-MVP, pre-investment-grade) prevent Sam from insisting on a paid pilot when the situation genuinely calls for a free one. This is the right nuance.
+
+**What risks losing Sam:**
+- The DPA is the most emotionally demanding artifact in the course. Sam has to ask for money. The chapter can't remove the fear — it can only name it and give Sam the script.
+- The $500 minimum deposit may feel like a lot to Sam if his product is $29/month. The chapter addresses this: "When 10% of year-one ACV is below $300, charge the first month's revenue upfront."
+
+**Sam's output:** One signed paid pilot before any new code ships.
+
+**Mobile experience:** The DPA 6-section table is scannable. The conversation script and the 9-response objection table render well on mobile. The Stripe Checkout setup (5 steps) is compact. This is a well-structured chapter for mobile reading — Sam can read the script on his phone before the call.
+
+**Trust score: 9/10.** (Recalibrated — see Appendix D.) The emotional peak of the entire course. The "it feels like joining the side that hurt you" line is the most honest sentence Sam will read. The DPA is one page. The conversation script is 15 seconds. The objection-response table covers every scenario. Sam walks away feeling equipped to charge for his work. The only friction: Sam still has to say the words out loud to a real customer.
+
+---
+
+### Chapter 5.5 — Going Outbound Without a Sales Team
+
+**What Sam encounters:** A cold-outbound pipeline: Filter → Personalize → Loom → Calendly → Stripe. 4-line scripts (3 variants: B2B SaaS, B2B services, B2C app). Volume targets: 100-200 outreach contacts → 5-10 paying customers.
+
+**Sam's emotional arc:**
+1. Reads the OpenHunts stat: Product Hunt 3.1% conversion vs Indie Hackers 23.1%. 89% of PH founders wouldn't launch again. — *surprise* — "I was about to plan a Product Hunt launch. The data says it's the wrong lever."
+2. Reads: *"Figma's first customer 11-20 cohort came from cold DMs to influential designers. Retool filtered Crunchbase by funding recency."* — *recontextualization* — "Even Figma did cold outreach. This isn't beneath me."
+3. Reads the $0 outbound stack: Apollo free tier + Google Sheet + Gmail + Loom free + Calendly free. — *relief* — "I can run this pipeline for $0."
+4. Reads the "First-batch reality" callout: "0-1 reply rate on batch 1 is the median outcome for first-time cold senders, not a failure signal." — *reassurance* — "If my first batch gets 0 replies, I'm not failing. I need to diagnose the filter, not kill the product."
+5. Reads the 4-line cold-email script (Variant 1: B2B SaaS). — *confidence* — "4 lines. I can personalize 30 of these in 45 minutes."
+
+**What works for Sam:**
+- The Product Hunt 3.1% vs Indie Hackers 23.1% stat is the credibility anchor. Sam was about to plan a launch event. The data says cold outbound is the higher-probability path.
+- The $0 outbound stack removes the financial barrier. Sam doesn't need Salesforce or a $1,200/month sales tool.
+- The "First-batch reality" callout prevents Sam from panicking when his first 30 messages get 0-1 replies. This is the most important psychological preparation in the chapter.
+- The 4-line scripts (3 variants) are verbatim. Sam can copy-paste them tonight.
+- The 60-90 second personalization rule: "Read the profile and the last post, find one specific reference. One sentence. Then the same four-line script for everyone." This keeps the volume tractable.
+- The "What 'no reply' actually means" diagnostic (3-item checklist: deliverability, filter, reference specificity) gives Sam a fix path instead of despair.
+- The "Stop / continue / accelerate" reply-rate bands: <5% = stop, 5-10% = continue with one variable change, >10% = accelerate. This prevents Sam from doubling down on a broken pipeline.
+- The "Compounding past customer 20" section: "Ask your first 20 for one introduction each." This transitions Sam from cold outbound to warm referrals — the gradient from hunting to farming.
+- The pre-flight domain warmup instruction: "A brand-new sending domain will land in spam on batch 1." Sam would have skipped this and gotten 0 replies for a mechanical reason, not a script reason.
+
+**What risks losing Sam:**
+- The chapter is positioned as the final chapter. Sam may feel "I'm not ready for cold outbound — I haven't even closed my first customer." The chapter assumes Sam has exhausted his network (Ch 5.3). If Sam reads Ch 5.5 directly after Ch 5.4, he may feel overwhelmed.
+- **Mitigation:** The explicit trigger: "Move to Chapter 5.5 when ALL three of these are true: all 50 names contacted, 10+ replies received, fewer than 3 demos booked." Sam knows the gate.
+
+**Sam's output:** 30 cold messages sent, 3-5 demo calls booked, 1-2 paid pilots cleared once replies mature.
+
+**Mobile experience:** The 4-line scripts (3 variants) render well on mobile (short code blocks). The pipeline diagram requires horizontal scrolling. The "Stop / continue / accelerate" reply-rate bands are scannable. Sam can personalize messages on his phone.
+
+**Trust score: 5/10.** (Recalibrated — see Appendix D.) The OpenHunts stat (3.1% vs 23.1%) and the $0 stack are the right credibility anchors. But Sam may read this chapter prematurely (before exhausting his network). The chapter's position as "Step 5 of 5" implies linear progression, but the trigger conditions (all 50 names contacted, 10+ replies, <3 demos) make it clear Sam should NOT read this yet. Sam may ignore the trigger and feel overwhelmed. The first-batch reality check (0-1 replies is normal) is the right psychological preparation for when Sam does reach this stage.
+
+---
+
+### Module 5 Exit — Sam's State
+
+Sam now has:
+- A must-have-user persona with 3 verbatim quotes (from Ch 5.1 survey)
+- One committed channel (from Ch 5.2 worksheet)
+- 50 personalized outreach messages sent (from Ch 5.3 network list)
+- One signed paid pilot (from Ch 5.4 DPA + Stripe deposit)
+- 30 cold messages sent with a reply-rate signal (from Ch 5.5)
+
+**Sam's emotional state:** Transformed. Sam shipped a product, validated demand, found a must-have segment, and closed a paying customer — all without hiring a devshop or spending $80K.
+
+**Total cost:** ~$500 (smoke test ads) + $0-25/month (Lovable + Supabase) + Stripe transaction fees. Total: under $1,000.
+
+**Time invested:** 5-6 months (evenings-only). Last time: 14 months, $80K, zero customers.
+
+---
+
+## Sam's Overall Journey Arc
+
+### Emotional Arc (Chapter by Chapter)
+
+*Note: The "Emotion" column describes the arc Sam experiences while reading — from his initial resistance to his eventual state. Single-word labels like "skepticism → confidence" are deliberately compressed; the chapter assessments above carry the full emotional weight.*
+
+| Chapter | Sam's emotional arc | Trust score (recalibrated) |
+|---|---|---|
+| Landing page | Recognition → trust ("they've catalogued my failure modes") | 8.5/10 |
+| 1.1 (Hypothesis) | Skepticism → confidence ("there's a number, not a guess") | 8/10 |
+| 1.2 (Smoke Test) | Fear → relief ("$300 is affordable. Priya's story is my story.") | 6/10 |
+| 1.3 (Price Test) | Dread → surprise ("Maya's $62K lesson. Stripe setup: 5 steps, no code.") | 7/10 |
+| 2.1 (Mom Test) | Shame → clarity ("I've been asking the wrong questions") | 5/10 |
+| 2.2 (AI Personas) | Skepticism → intrigue ("90 minutes saves 5 interview slots") | 3/10 |
+| 2.3 (Outreach) | Despair → hope ("I don't have to beg my network. Reddit works.") | 7/10 |
+| 2.4 (Prototype) | Alarm → trust ("Problem validated ≠ interface validated") | 4/10 |
+| 3.1 (Brief) | Relief ("the no-go list is longer than the build list") | 7/10 |
+| 3.2 (Outcomes) | Laughter → clarity ("47-button spaceship. That was my product.") | 7/10 |
+| 4.1 (Hire Decision) | Surprise → hope ("the default is self-serve, not hire") | 7/10 |
+| 4.2 (Ownership) | Dread → relief ("5-minute self-check. I pass. I own everything.") | 8/10 |
+| 4.3 (Self-Serve Stack) | Overwhelmed → determined ("$0 path. 12 rules, 3 pre-flight. I can do this.") | 5/10 |
+| 4.4 (Ceiling Signals) | "Not today" → bookmark ("I'll come back when I have users") | 5/10 |
+| 5.1 (PMF Test) | Dread → reassurance ("$4,200 lesson. 5-question survey. I'll run it tonight.") | 7/10 |
+| 5.2 (Channel) | "Too much process" → confidence ("the worksheet forces a decision") | 3/10 |
+| 5.3 (Network) | Shame → empowerment ("60% of Figma's customers came from this") | 8/10 |
+| 5.4 (Paid Pilot) | Fear → courage ("they named my exact fear: 'joining the side that hurt me'") | 9/10 |
+| 5.5 (Cold Outbound) | Anxiety → reassurance ("0 replies on batch 1 is normal. Diagnose, don't despair.") | 5/10 |
+
+### Trust Curve (Recalibrated)
+
+Sam's trust follows a double-dip U-curve. The first dip is in Module 2 (emotional overload — 6-8 weeks of talking to strangers), bottoming at Ch 2.2 (AI Personas, 3/10) and Ch 2.4 (silent observation, 4/10). The second dip is in Module 4 (cognitive overload — the longest chapter, SQL queries, ceiling signals), bottoming at Ch 4.3 (5/10) and Ch 4.4 (5/10). The peak is Ch 5.4 (Paid Pilot, 9/10) — the emotional climax.
+
+The score measures "how likely is Sam to trust this chapter enough to complete it on first read" — NOT "how valuable is this chapter if Sam completes it." Ch 2.2 and Ch 5.2 are both 3/10 on trust but may be 8/10 on value for the Sam who actually does the work.
+
+```
+Trust (1-10 scale, recalibrated)
+ 10 |
+    |
+  9 |                                                          ▄
+    |                                                          ▐
+  8 | ▄                       ▄                               ▐
+    | ▐   ▄                   ▐           ▄                   ▐
+  7 | ▐   ▐   ▄   ▄           ▐   ▄   ▄   ▐           ▄       ▐
+    | ▐   ▐   ▐   ▐       ▄   ▐   ▐   ▐   ▐           ▐       ▐
+  6 | ▐   ▐   ▐   ▐       ▐   ▐   ▐   ▐   ▐           ▐       ▐
+    | ▐   ▐   ▐   ▐   ▄   ▐   ▐   ▐   ▐   ▐           ▐       ▐
+  5 | ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▄   ▄   ▐       ▐
+    | ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐       ▐
+  4 | ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐       ▐
+    | ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐       ▐
+  3 | ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐       ▐
+    | ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐       ▐
+  2 | ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐   ▐       ▐
+    |_______________________________________________________________
+     LP  1.1 1.2 1.3 2.1 2.2 2.3 2.4 3.1 3.2 4.1 4.2 4.3 4.4 5.1 5.2 5.3 5.4 5.5
+```
+
+**Key trust moments:**
+- **Landing page (LP):** The 5-mistake catalog — Sam recognizes himself. Trust: 8.5/10.
+- **2.2 (AI Personas):** First trust floor (3/10) — AI personas feel gimmicky. Sam's impatience to book interviews peaks here.
+- **3.2 (Outcomes):** Recovery begins (7/10) — the admin-panel-spaceship is Sam's biography.
+- **4.2 (Ownership):** Trust spike (8/10) — the health-tech rescue story is visceral. Sam checks his AWS root email tonight.
+- **4.3 (Self-Serve Stack):** Second trust floor (5/10) — cognitive overload. The longest chapter. Sam skims.
+- **5.2 (Channel):** Second trust floor (3/10) — tied with 2.2 as the most skippable chapter. Sam wants to sell, not fill in worksheets.
+- **5.4 (Paid Pilot):** Trust peak (9/10) — "it feels like joining the side that hurt you." Maximum emotional resonance.
+
+### What Sam Would Tell Another Founder
+
+After completing all 18 chapters, Sam would say:
+
+> "I spent $80K and 14 months on my last product. Zero customers. This course cost me under $1,000 and 5 months of evenings. I shipped a working MVP on Lovable + Supabase + Stripe without writing code. I ran 10 Mom Test interviews that actually told me whether the problem was real. I closed my first paying customer with a one-page contract and a Stripe deposit before I wrote a line of new code.
+>
+> The course doesn't teach you to code. It teaches you what to ask, what to measure, and what NOT to build. The no-go list saved me more money than everything else combined.
+>
+> If you've been burned by a devshop, start at Module 1. If you're currently paying a devshop and suspect they're overbuilding, skip to the 'If Your Team Is Already Failing' checklist on the landing page. Either way, read Chapter 4.2 (ownership audit) before you do anything else. The AWS root email is the most important sentence in the course."
+
+---
+
+## What Sam Walks Away With
+
+### The Founder OS (6 Artifacts)
+
+1. **Founding Hypothesis** (Module 1) — one sentence, five blanks, PASS score ≥14/20
+2. **Smoke-test decision** (Module 1) — go / iterate / kill, backed by real conversion data + Stripe price signal
+3. **Validated problem statement + prototype feedback** (Module 2) — 10 scored transcripts + 5 silent-observation sessions + verbatim user vocabulary
+4. **One-page Product Brief** (Module 3) — 5 sections, outcome-shaped, no-go list, 250 words max
+5. **Live MVP** (Module 4) — custom domain, real auth, real Stripe, 4-6 active users, ownership locked Day 1
+6. **First signed paid pilot** (Module 5) — DPA + Stripe deposit cleared, channel sequence running
+
+### The Emotional OS
+
+- **Trust in data, not gut:** Sam has real numbers for every decision (conversion rates, interview scores, must-have %, reply rates). He doesn't need to guess.
+- **Permission to kill:** The course gives Sam decision trees for every stage. If the hypothesis fails, he kills it and moves on. He doesn't spend 14 months hoping.
+- **The no-go list is power:** The most counterintuitive lesson Sam learns: specifying what NOT to build is more valuable than specifying what to build.
+- **Charging is protection:** The paid pilot is not about revenue — it's about testing whether the customer is serious. The deposit puts the CFO question on Week 0.
+- **You can do this alone:** Sam shipped a working product, found customers, and closed a sale — without hiring a devshop or a technical co-founder.
+
+---
+
+## Friction Points by Module
+
+### Module 1 Friction
+- **Minor:** The 1.1 sprint is billed as "90 minutes" but has 6 steps. Sam may underestimate the time.
+- **Minor:** The 1.2 builder comparison table (6 options) introduces decision fatigue.
+- **Resolved:** The Stripe verification delay (1-3 days) is named upfront. Sam plans around it.
+
+### Module 2 Friction
+- **Moderate:** The 2.1 two-pass structure (Pass 1 = technique, Pass 2 = synthesis) may confuse Sam on first read. The explicit headers mitigate this.
+- **Moderate:** Chapter 2.2 (AI Personas) is the most skippable chapter. Sam may not internalize the 90-minutes-saves-5-slots math.
+- **Minor:** Chapter 2.3 is long. Sam skims to the message templates, which is the correct behavior.
+- **Minor:** Chapter 2.4's silent-observation script is uncomfortable. Sam has to trust that staying quiet is the point.
+
+### Module 3 Friction
+- **Minor:** The 3.1 Vibe PRD vs Traditional PRD fork assumes Sam knows whether he's handing to Lovable or a senior team. The chapter helps him decide.
+- **Minor:** The 3.2 AI critic block requires Sam to have a Claude account. The chapter also gives a peer-based alternative.
+
+### Module 4 Friction
+- **Moderate:** Chapter 4.3 is the longest chapter. Sam skims. The "3 pre-flight rules" callout ensures he internalizes the load-bearing parts.
+- **Minor:** The self-test SQL query in 4.3 may intimidate Sam. The "End-of-Phase-2 micro-fail signal" (spouse test) is a lower-friction alternative.
+- **Minor:** Chapter 4.4 (ceiling signals) may feel like premature pessimism after the MVP launch.
+
+### Module 5 Friction
+- **Moderate:** Chapter 5.2 (channel selection) may feel like "too much process" when Sam wants to send messages.
+- **Moderate:** Sam's emotional resistance to "asking friends" (Ch 5.3) and "asking for money" (Ch 5.4). The course addresses both directly.
+- **Minor:** Chapter 5.5 assumes Sam has exhausted his network. Sam may read it prematurely.
+
+---
+
+## Design Strengths (What the Course Gets Right for Sam)
+
+### 1. The Failure-Mode Catalog
+Every chapter opens with a founder story that names a specific, expensive failure. Sam recognizes himself in Priya (14 interviews, 0.6% conversion), Maya (48 emails, zero customers), Marcus ($480 of untracked ads), Sarah (17 toggles, 12 wired to nothing). These stories earn Sam's trust because they prove the course has seen his failure mode before.
+
+### 2. Numbers for Every Decision
+Sam never has to "trust his gut." The course gives him:
+- ≥14/20 PASS bar (Ch 1.1)
+- ≥3% email conversion (Ch 1.2)
+- ≥5% Stripe-click rate (Ch 1.3)
+- ≥7/10 interview strong-signal count (Ch 2.1)
+- 4-5 of 5 prototype passes (Ch 2.4)
+- ≥40% must-have rate (Ch 5.1)
+- ≥9/12 channel-fit score (Ch 5.2)
+- >5% reply rate (Ch 5.5)
+
+Sam doesn't need to be technical. He needs to be able to compare a number to a threshold.
+
+### 3. Jargon Glossaries Before Jargon Questions
+Chapter 4.1's Q2 asks about "WebSockets, RLS, multi-tenant data, SOC 2, HIPAA, PCI." Sam would panic and guess. The chapter defines each term in a sidebar BEFORE asking the question. This is the single best accessibility design choice in the course.
+
+### 4. The "What NOT to Do" Sections
+Every chapter has an explicit "here's what most founders do wrong" section:
+- "The 5 questions most founders ask instead" (Ch 2.1)
+- "The message most non-technical founders write first" (Ch 2.3)
+- "What most founders say first (and why it ruins the session)" (Ch 2.4)
+- "What breaks silently (Marcus's $480 lesson)" (Ch 1.2)
+
+These sections do double work: they teach the right approach AND they name Sam's likely mistake before he makes it.
+
+### 5. Cross-Chapter Artifact Chain
+Sam's work compounds. The Ch 1.1 hypothesis fills the Ch 2.3 AI ICP map prompt. The Ch 2.1 validated problem statement becomes Ch 3.1 Section 1 verbatim. The Ch 2.4 prototype vocabulary becomes Ch 4.3 Lovable prompt language. The Ch 5.1 verbatim quotes become Ch 5.3 outreach message language. Sam never feels like he's starting from scratch.
+
+### 6. The Emotional Honesty
+The course names Sam's shame, fear, and distrust without performative empathy:
+- *"After months of paying an agency, the muscle memory becomes 'everyone keeps asking me for money.' Asking your customer for money first feels like joining the side that hurt you."* (Ch 5.4)
+- *"The objection comes up in every founder call: 'I do not want to ask friends. It feels like begging.'"* (Ch 5.3)
+- *"You hired wrong. So did we, the first three times."* (implied across multiple chapters)
+
+These lines prove the course understands Sam's psychology. They don't pity him. They name his blocker and give him a path through it.
+
+### 7. The Exit Criteria
+Every phase has a finish line:
+- Module 1: Go / iterate / kill decision
+- Module 2: 10 scored transcripts + prototype pass/fail log
+- Module 3: Quality-checked brief (peer passes the rubric)
+- Module 4: 5 green lights (Stripe live, custom domain, 1 ICP user, zero JS errors, demo recording)
+- Module 5: Signed DPA + cleared Stripe deposit
+
+Sam never has to ask "am I done?" The finish line is explicit.
+
+---
+
+## Design Gaps (Where Sam Struggles)
+
+### 1. No In-Chapter "Skip to the Action" Links
+Sam is time-poor and skim-first. The three longest chapters (Ch 4.3, Ch 3.2, Ch 2.3) don't have anchor links at the top that let Sam jump to the template/script/checklist. Sam has to scroll to find the actionable part.
+
+**Recommendation from 40.05 review (already tracked in TASK-TRACKER):** Add "Skip to the action" links at the top of Ch 1.1, 3.2, and 4.3.
+
+### 2. Module 2 Emotional Load
+Module 2 is the longest module in calendar time (6-8 weeks) and the most emotionally demanding (talking to strangers, hearing "no," watching people struggle with the prototype). Sam may lose momentum between Ch 2.3 and Ch 2.4.
+
+**Recommendation from 40.05 review (already tracked):** Add burned-founder acknowledgment callouts in Ch 2.1 and 2.2 to sustain Sam through the emotional dip.
+
+### 3. The Two-Pass Structure in Ch 2.1
+Sam reads Ch 2.1 in Pass 1 (technique), then has to come back for Pass 2 (synthesis) after 10 interviews. The design is correct, but Sam may feel the chapter is "unfinished" on first read.
+
+**Mitigation exists:** The explicit "Pass 1" and "Pass 2" headers + anchor link. But Sam may still feel unsettled.
+
+### 4. Chapter 2.2 Is the Most Skippable Chapter
+The AI persona rehearsal (Ch 2.2) is valuable but positioned between Ch 2.1 (technique) and Ch 2.3 (recruitment). Sam wants to book interviews, not rehearse with AI. The chapter earns its thesis, but Sam's impatience may override it.
+
+**Recommendation:** Consider repositioning Ch 2.2 as a sidebar in Ch 2.1 or as an optional supplementary chapter rather than a numbered step in the linear sequence. (Outside scope of this report — flag for discussion.)
+
+### 5. The Cold Outbound Transition
+Chapter 5.5 assumes Sam has exhausted his network. If Sam reads it immediately after Ch 5.4, he may feel "I haven't even closed one customer and they're already telling me to do cold outreach." The explicit trigger (all 3 conditions must be true) helps, but the chapter's position as "Step 5 of 5" implies linear progression.
+
+**Mitigation exists:** The trigger conditions are clear. Sam knows the gate.
+
+---
+
+## Overall Assessment
+
+### Template and Supplementary Chapters
+
+Throughout the linear path, Sam encounters 9 linked templates and supplementary chapters:
+
+| Template | First encountered | Sam's experience |
+|---|---|---|
+| Mom Test Interview Script | Ch 2.1 | Referenced as companion artifact. Sam prints it, puts it on second monitor. Feels like a tool, not homework. |
+| Validated Problem Statement Template | Ch 2.1 (Synthesis) | Used AFTER 10 interviews. Sam returns to it later. Feels like the finish line, not a distraction. |
+| Outreach Sequence Template | Ch 2.3 | Copy-pasteable message sequences. Sam uses it immediately. Feels like a cheat sheet. |
+| Vibe PRD Template | Ch 3.1 | Fill-in-the-blanks artifact. Sam completes it alongside the chapter. Feels like the workshop output. |
+| Build Path Decision Worksheet | Ch 4.1 | Printable checklist. Sam fills it in with pen. Feels like a decision tool, not homework. |
+| Ownership Checklist | Ch 4.2 | 12-item audit with pass/fail columns. Sam runs it tonight. Feels like a diagnostic. |
+| Self-Serve Stack Walkthrough | Ch 4.3 | Day-by-day build guide. Sam references during the build. Feels like a companion, not a chapter. |
+| First Paying Customer Operating Kit | Ch 5.1 | 6-piece template bundle (survey, DPA, scripts, etc.). Sam downloads once. Feels like the graduation packet. |
+| Friday Demo Template / SOW Reading Guide / Hiring Interview Script | Various | Referenced from multiple chapters. Sam bookmarks for later. Feels like reference material, not required reading. |
+
+**Design assessment:** The templates are well-integrated. They feel like tools Sam reaches for at the right moment, not homework assignments that slow him down. The only risk: if Sam encounters a template link before he's ready to use it, he may feel the course is bloated with supplementary material. The "first encountered" timing is correct — each template appears exactly when Sam needs it.
+
+### Sam's Journey Score: 6.2/10 (Recalibrated)
+
+The course is strongest for the skim-first, time-poor, burned founder — its explicit design target. Sam enters with distrust and shame. He exits with a working product, a paying customer, and a Founder OS (6 artifacts) he can hand to an investor or a co-founder.
+
+The emotional arc is well-calibrated: recognition (landing page) → confidence (Module 1) → endurance (Module 2) → clarity (Module 3) → accomplishment (Module 4) → courage (Module 5). The dip in Module 2 is real but survivable. The peak at Ch 5.4 is earned.
+
+The course's greatest design achievement is the **no-go list pattern**: specifying what NOT to build is the through-line from Ch 3.1 (no-go list) through Ch 3.2 (outcome-shaped constraints) through Ch 4.3 (inside/outside the envelope) through Ch 5.4 (DPA scope section). Sam learns that constraint is protection — the opposite of what a devshop taught him.
+
+The course's greatest emotional achievement is Ch 5.4's single line: *"Asking your customer for money first feels like joining the side that hurt you."* That sentence will stay with Sam longer than any template, script, or scorecard. It names the exact psychological injury of being burned by a devshop, and it gives Sam permission to move past it.
+
+---
+
+## Appendices
+
+### A. Sam's Time Budget (Evenings-Only Founder)
+
+| Module | Calendar weeks | Active hours |
+|---|---|---|
+| Module 1 (Hypothesis & Smoke Test) | 2-3 weeks | 8-12 hours |
+| Module 2 (Validate) | 6-8 weeks | 15-25 hours |
+| Module 3 (Design) | 1 week | 6-8 hours |
+| Module 4 (Build) | 10-12 weeks | 40-60 hours |
+| Module 5 (First Paying Customer) | 6-10 weeks | 20-35 hours |
+| **Total** | **25-34 weeks** | **89-140 hours** |
+
+### B. Sam's Dollar Budget
+
+| Module | Minimum spend | Realistic spend |
+|---|---|---|
+| Module 1 | $0 (organic only) | $300-600 (cold traffic ads) |
+| Module 2 | $0 (free outreach) | $100-500 (paid panel if needed) |
+| Module 3 | $0 | $0 |
+| Module 4 | $0 (free tiers) | $0-50/month (Lovable Pro + Supabase Pro) |
+| Module 5 | $0 (free tiers) | $0-99/month (Sales Navigator optional) |
+| **Total** | **$0** | **$300-1,200 + $0-150/month** |
+
+### C. Key Artifact Chain (Input → Output)
+
+```
+Ch 1.1 Hypothesis sentence
+  → Ch 1.2 Landing page headline
+  → Ch 1.3 Stripe price button
+  → Ch 2.3 AI ICP map prompt (three sentences + competitor URLs)
+    → Ch 2.1 Mom Test interviews (scored 1-10)
+      → Ch 2.4 Prototype sessions (5 strongest-signal interviewees)
+        → Ch 2.1 Synthesis (validated problem statement)
+          → Ch 3.1 Section 1 (copied verbatim)
+            → Ch 3.2 Outcome-shaped rewrite (When/I want/So I can)
+              → Ch 4.1 Build-path decision (almost always self-serve)
+                → Ch 4.3 Lovable prompt body (outcome-shaped features + no-go list)
+                  → Ch 5.1 Sean Ellis survey (must-have segment)
+                    → Ch 5.2 Channel selection (interview evidence)
+                      → Ch 5.3 Outreach messages (Ch 5.1 verbatims as body copy)
+                        → Ch 5.4 Paid pilot (DPA + Stripe deposit)
+                          → Ch 5.5 Cold outbound (Figma-style pipeline)
+```
+
+---
+
+*Report generated by Buffy (AI agent) as a single-ICP customer journey analysis. The 4 persona lenses from 40.05 were collapsed into a single Sam narrative for this report. Sam is Alex from the ICP document, rendered through the emotional arc of a founder reading the course linearly.*
+
+### D. Trust Score Methodology (Recalibrated)
+
+**What the trust score measures:** "How likely is Sam to trust this chapter enough to complete it on first read" — NOT "how valuable is this chapter if Sam completes it." A chapter can score 3/10 on trust (Sam may skip it) but 8/10 on value (the Sam who does the work gets massive ROI). Ch 2.2 (AI Personas) and Ch 5.2 (Channel Selection) are both in this category.
+
+**Initial pass vs recalibration:** The first-pass trust scores emerged from reading each chapter through Sam's emotional lens and assigning a directional rating (1-10). The three constraints below explain the pattern behind the scores rather than describing a separate mathematical pass — final scores were arrived at iteratively by applying these heuristics while reading each chapter analysis:
+
+1. **Cross-chapter anchoring** — scores were normalized so the highest-trust chapter (Ch 5.4) anchors at 9/10 and the lowest (Ch 2.2, Ch 5.2) at 3/10. This prevents score inflation where every chapter lands in the 6-8 band.
+
+2. **Emotional-distance weighting** — chapters that ask Sam to do something emotionally difficult (stay silent while someone struggles, ask for money, ask friends for help) were scored lower on trust UNLESS the chapter explicitly names and reframes Sam's resistance. Ch 5.4 (Paid Pilot) is the exception: the chapter asks Sam to do the hardest emotional act in the course (charge a stranger), but its design overcomes resistance so completely — naming his exact fear, providing a 15-second script, a one-page DPA, and a full objection table — that trust peaks at 9/10. Ch 5.3 (Network) similarly reframes “begging” as “fair trade,” earning 8/10 despite the emotional ask.
+
+3. **Cognitive-load weighting** — chapters with high tool-name density (Ch 4.3), long length (Ch 2.1, Ch 4.3), or novel concepts (two-pass reading, AI personas) were scored lower because Sam's skim-first behavior means he'll miss content. The score reflects Sam's likely skim depth, not the chapter's instructional design.
+
+**Recalibrated trust scores with rationale:**
+
+| Chapter | Score | Primary factor |
+|---|---|---|
+| Landing page | 8.5/10 | Failure-mode catalog creates instant recognition. No jargon. Self-selection filter. Slightly long for phone. |
+| 1.1 (Hypothesis) | 8/10 | Mad Libs format removes blank-page terror. PASS bar is a number. 6-step sprint feels longer than "90 minutes" on first read. |
+| 1.2 (Smoke Test) | 6/10 | Priya's story earns trust. Builder comparison table (6 options) introduces decision fatigue. Conversion-rate table saves the chapter. |
+| 1.3 (Price Test) | 7/10 | Maya's story is the mirror of Priya's. Stripe setup is 5 concrete steps. Stripe verification delay (1-3 days) may discourage Sam. |
+| 2.1 (Mom Test) | 5/10 | Bad-question/rewrite table is brilliant. Two-pass structure and chapter length create friction. Polite-default-7 warning buried 40% down. |
+| 2.2 (AI Personas) | 3/10 | Logically sound but emotionally mistimed — Sam wants to book interviews, not rehearse with AI. Cost: $0. Repositioning as optional sidebar would help. |
+| 2.3 (Outreach) | 7/10 | "First-draft message" section is best teaching move in course. Chapter is too long; Sam skims to templates (which is the intended behavior). |
+| 2.4 (Prototype) | 4/10 | Asks Sam to do the hardest thing (stay silent) AND build throwaway. Steepest trust climb. Founder story earns the thesis. |
+| 3.1 (Brief) | 7/10 | Sarah's 17-toggles story + no-go list are load-bearing. Sam may feel this is "paperwork" between validation and building. |
+| 3.2 (Outcomes) | 7/10 | Admin-panel-spaceship opener is best teaching moment. Before/after pairs with dollar estimates. Sam may resist the "rewrite Section 3" exercise. |
+| 4.1 (Hire Decision) | 7/10 | Jargon Glossary sidebar is best accessibility feature. Default-is-self-serve framing is right. Fractional CTO cost ($8-15K/mo) may alarm. |
+| 4.2 (Ownership) | 8/10 | Health-tech rescue story is most visceral anchor. 5-minute self-check is right filter. Worst-case opener may feel like fear-mongering to unburned founders. |
+| 4.3 (Self-Serve Stack) | 5/10 | $0 path callout is revolutionary. Highest cognitive load in course — longest chapter + SQL queries. "3 pre-flight rules" callout is the right mitigation. |
+| 4.4 (Ceiling Signals) | 5/10 | "Not an action-today chapter" framing is right. Arrives immediately after MVP triumph — emotionally mistimed. Sam bookmarks and ignores (intended). |
+| 5.1 (PMF Test) | 7/10 | $4,200 Meta story earns thesis. 5 questions are verbatim. Sam may skip because "I need customers, not surveys." |
+| 5.2 (Channel) | 3/10 | Tied with Ch 2.2 as most skippable. Channel-hopping prevention is right insight; worksheet format is wrong vehicle for Sam's "let me sell" moment. |
+| 5.3 (Network) | 8/10 | Lenny Rachitsky 60/35/5 stat is credibility anchor. "It feels like begging" reframe is exact emotional blocker. Network-size diagnostic prevents wrong-playbook failure. |
+| 5.4 (Paid Pilot) | 9/10 | Emotional peak of entire course. "Joining the side that hurt you" line is most honest sentence. DPA is one page. Script is 15 seconds. |
+| 5.5 (Cold Outbound) | 5/10 | OpenHunts stat + $0 stack are right anchors. Sam may read prematurely (trigger conditions exist but chapter position implies linear progression). First-batch reality check is right prep. |
+
+**Composite Journey Score:** The Overall Assessment score of 6.2/10 is the arithmetic mean of all 19 trust scores (LP + 18 chapters): 119.5 ÷ 19 ≈ 6.29, rounded to 6.2. This is a crude aggregate — the trust curve (double-dip U-shape) is more informative than any single number.
+
+**Limitations:** Scores reflect one ICP persona (Sam/Alex) reading linearly. A crisis-mode founder entering at Door 2 would have a different trust curve. A post-MVP founder entering at Module 5 would skip the Module 2 trust dip entirely. The scores are a single-thread analysis, not a universal rating.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.07-sam-experience-improvement-report-2026-06.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.07-sam-experience-improvement-report-2026-06.md
new file mode 100644
index 000000000..1f4a7e18d
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.07-sam-experience-improvement-report-2026-06.md
@@ -0,0 +1,158 @@
+# 40.07 — Sam Experience Improvement Report
+
+**Status:** Recommendations logged to TASK-TRACKER for triage
+**Date:** 2026-06-07
+**Branch:** `module-8-first-paying-customer`
+**Scope:** 18 chapters (Modules 1–5), course persona "Sam" — the idea-stage non-technical first-timer
+**Based on:** Full read of all 18 chapters + ICP documents + voice guide + prior audit findings (40.01, 40.04, 40.05, 40.06, 10.07)
+
+> **Note on ICP scope:** This report focuses on Sam — the idea-stage non-technical first-timer. The burned-founder ICP (Alex) is a secondary audience routed via the landing page "If Your Team Is Already Failing" side-path. Recommendations for Alex are deferred; this report's improvements target Sam exclusively.
+
+---
+
+## Executive Summary
+
+The course is strongest for its ICP. Sam enters with an idea; he exits with a working MVP, a paying customer, and 6 Founder OS artifacts. The emotional arc is well-calibrated: recognition → confidence → endurance → clarity → accomplishment → courage.
+
+The branch's diff fixes are a clean convergence pass (voice, tags, acronyms, anchors). The larger Sam-experience gaps are **structural** — they live in chapter design, not line edits. Six actionable recommendations follow, ordered by impact.
+
+---
+
+## Top 6 Recommendations (by Sam Impact)
+
+### 1. Add "Skip to the action" anchor links on the 3 longest chapters
+
+**Chapters:** M4.3a (Stack), M1.2a (Smoke Test Build), M3.2 (Outcomes)
+**Sam's pain:** Time-poor, skim-first. Scrolls headlines on his phone commute. Needs to confirm the actionable part exists before committing to a deep read. Crisis-mode Sam needs to jump past context to the template/script/checklist.
+
+**What:** A small blockquote callout after the Input/Output box, e.g.:
+
+```
+> **Jump to:** [The prompt template](#the-lovable-prompt-template) · [The 3 pre-flight rules](#12-rules-for-a-self-built-poc-done-right) · [The ship plan](#the-ship-plan) · [What to do tomorrow](#what-to-do-tomorrow)
+```
+
+**Effort:** ~15 min/chapter. Zero risk. Already validated by the Pass 7 navigation callout pattern.
+
+---
+
+### 2. Reduce builder comparison fatigue in M1.2a
+
+**Chapter:** M1.2a (Smoke Test Build)
+**Sam's pain:** The builder comparison table lists 6 options (Mixo, Manus AI, Durable, NeetoSite, Carrd, Framer). Sam is a first-timer who has never used any of them. The table creates decision fatigue. The 40.06 report scores M1.2 at 6/10 trust — the builder table is the cited cause.
+
+**What:** Keep the table but restructure it as a decision tree:
+1. "Start here: Mixo (purpose-built for this job, $7/month)"
+2. "Fallback: Manus AI (free tier, highest output quality in 2026)"
+3. "Only if you've used a no-code builder before: NeetoSite or Carrd"
+
+The copy already says "Pick one and ship the page. Don't comparison-shop for a week" — but the table's 6 rows fight that message.
+
+**Effort:** ~10 min. Low risk.
+
+---
+
+### 3. Add a "First-timer fast path" on the landing page
+
+**Chapter:** `_index.md` (course landing page)
+**Sam's pain:** Sam enters without trauma. He hasn't been burned. He doesn't need the "If Your Team Is Already Failing" side-path. The 10.07 walkthrough notes: "Sam would benefit from a first-timer fast path on the landing page. A button that reads 'New to this? Start here →' and routes to Module 1.1 directly would save her from the decision-paralysis of the self-assessment worksheet."
+
+**What:** Add a prominent "New to this? Start here → Module 1.1" button OR a single callout after the hero section:
+
+```
+> **New founder, no team, no trauma?** Skip the diagnostic. Start at [Chapter 1.1 — Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/).
+```
+
+**Effort:** ~5 min. Low risk. Already recommended in the 10.07 walkthrough.
+
+---
+
+### 4. Consider repositioning M2.2 (AI Persona) as optional
+
+**Chapter:** M2.2 (AI Persona Pre-Validation)
+**Sam's pain:** This is the most skippable chapter per both the 40.06 report (3/10 trust) and the 40.05 review. Sam is between "I just learned the Mom Test" (M2.1) and "I want to book interviews" (M2.3). A chapter about rehearsing with AI personas feels like a detour. The chapter earns its thesis logically (90 minutes saves 5 interview slots) but fails emotionally.
+
+**What:** Three options (choose one):
+1. **Renumber as "2.1b"** (a sidebar of M2.1, not a standalone step)
+2. **Add a "Skip this if you've interviewed before" callout** at the top
+3. **Move to an optional supplementary chapter** referenced from M2.1's "Going further" section
+
+**Effort:** ~5 min for option 2 (least disruptive). Medium risk if renumbering (URL changes).
+
+---
+
+### 5. Add a "Stuck? Try this" box per module for first-timers
+
+**Chapters:** All 5 modules
+**Sam's pain:** Sam is a first-timer. When he stalls, he doesn't know whether the problem is him or the tool. The 10.07 walkthrough notes: "Sam needs different unblocking advice than a burned founder. Module 2: 'Your list has 3 names. Search a related keyword — boarding costs instead of pet sitter.' Not 'License Apollo Pro.'"
+
+**What:** A per-module callout placed near the "What to do next" section:
+
+```
+> **Stuck? Most first-timers stall here:** [one-line diagnosis of the most common stall point]. **Fix:** [one-line concrete action]. [Link to community help if applicable].
+```
+
+**Effort:** ~5 min/module × 5 modules = 25 min. Low risk.
+
+---
+
+### 6. Split the M4.3 AI critic block from the 12 rules
+
+**Chapter:** M4.3a (Stack)
+**Sam's pain:** The 12 rules section is dense (12 items) and the AI critic/simulator block is buried after it. Sam skims the rules, tires out, and never reaches the AI critic block — which is the most practical tool for him. The 40.06 report scores M4.3 at 5/10 trust — the chapter's length and the SQL self-test query create the highest cognitive load in the course.
+
+**What:** Move the AI critic block BEFORE the 12 rules. The block gives Sam actionable Claude prompts he can run tonight. The 12 rules are reference material — they should come after the practical tool, not before.
+
+**Effort:** ~5 min. Low risk.
+
+---
+
+## What the Branch Diff Got Right for Sam
+
+The branch's diff changes are net-positive for Sam:
+
+| Change | Sam impact |
+|---|---|
+| Acronym glosses (CAC, ICP, RLS, webhook, idempotency) | Prevents Sam from bouncing on jargon at first mention |
+| Voice shift: "A founder we spoke with" → second-person "you" | Puts Sam in the driver's seat, not a case-study observer |
+| Case study numbers corrected (Tomas/Mia prices) | Prevents confusion between body advice and case study examples |
+| `find-10-people-where-to-look` prompt: "Sam will verify" → "I will verify" | Correct — Sam IS the person pasting this into Claude |
+| Module tag corrections (1.3 → module-1, 2.4 → module-2) | Corrects downstream navigation |
+| DPA template anchor fix (`#dpa-template`) | Prevents broken cross-reference |
+
+---
+
+## Sam Trust Curve Reference
+
+From the 40.06 report (recalibrated), the trust floor chapters are:
+
+| Chapter | Trust | Primary friction |
+|---|---|---|
+| **M2.2** (AI Personas) | 3/10 | Feels like a detour between technique and recruitment |
+| **M5.2** (Channel Selection) | 3/10 | "Let me sell, not fill in worksheets" |
+| **M2.4** (Prototype) | 4/10 | Emotional difficulty: staying silent while someone struggles |
+| **M4.3** (Self-Serve Stack) | 5/10 | Cognitive overload: longest chapter, SQL self-test |
+| **M4.4** (Ceiling Signals) | 5/10 | Premature pessimism after MVP launch triumph |
+
+The trust peak is M5.4 (Paid Pilot, 9/10) — the emotional climax where Sam asks for money for the first time.
+
+The median trust score across all 18 chapters: **7/10**.
+
+---
+
+## Implementation Sequence
+
+If implementing all 6 recommendations, suggested order:
+
+1. **Items 1, 2, 6** (anchor links, builder table, AI critic block reorder) — highest impact/lowest effort, can ship in one sitting
+2. **Items 3, 5** (landing page fast path, stuck boxes) — moderate effort, higher emotional impact
+3. **Item 4** (M2.2 repositioning) — highest structural impact, needs design discussion before implementation
+
+---
+
+## Verification Gates (Before Ship)
+
+- [ ] `bin/hugo-build` — zero errors
+- [ ] `bin/rake test:critical` — all passing
+- [ ] ICP-reader read-back on 3 random chapters — read as Sam, not Alex
+- [ ] Banned-pattern regression sweep
+- [ ] Adjacent callout form check — no two same-form callouts side-by-side
diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.08-chapter-template-gap-report.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.08-chapter-template-gap-report.md
new file mode 100644
index 000000000..22cb224df
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.08-chapter-template-gap-report.md
@@ -0,0 +1,210 @@
+# 40.08 — Chapter 8-Part Template Gap Report
+
+**Status:** Diagnostic audit — no edits prescribed
+**Date:** 2026-06-07
+**Based on:** 30.03 §2 8-part template, word counts, pattern searches across 21 files, deep-reads of 3 chapters (smoke-test-build, must-have-segment-pmf-test, paid-pilot-charge-before-ship)
+**Question:** How does each of the 20 linear chapters (+ Chapter 0 "how-this-course-works") score against the 8-part micro-learning template?
+
+---
+
+## Scoring Methodology
+
+Each chapter scored YES/NO/PARTIAL on 8 criteria from 30.03 §2.1-2.8:
+
+| # | Criterion | What YES means |
+|---|---|---|
+| 1 | **Hook ≤3 sentences** | A 1-3 sentence pain+win line exists before any long prose. Not a TL;DR callout, not a 5-paragraph narrative. |
+| 2 | **One-sentence outcome** | An explicit "After this lesson you will be able to: [action]" statement in visible content. YAML `goal` field doesn't count. |
+| 3 | **Concept block ≤300 words** | A clearly bounded instructional section ≤300 words before the action section. Not 1,000+ word multi-section bodies. |
+| 4 | **Visual micro-aid** | At least one informational visual (Mermaid diagram, SVG, annotated screenshot, flowchart). |
+| 5 | **Do-this-now (3-7 steps + success check)** | Numbered imperative steps (3-7) with a verifiable success check on the final step. Tables don't count. |
+| 6 | **Error anticipation** | Explicit "If this fails: [symptom]. Why: [cause]. Fix: [action]." pattern. "If blocked" callouts are directional but don't follow If/Why/Fix. |
+| 7 | **Micro-reflection** | A short reflection prompt: "Paste your result here" or "Answer in one sentence: what changed?" Currently 0 chapters have this. |
+| 8 | **Bridge to next lesson** | A 1-2 sentence bridge naming the specific dependency from this lesson to the next. "Next click" links exist but are generic chapter references. |
+
+**Score = count(YES) + 0.5 × count(PARTIAL). Max = 8.**
+
+**Priority:** HIGH (0-2) = farthest from template, migrate first. MED (2.5-4) = partial alignment. LOW (4.5+) = closest to template.
+
+> **Calibration note:** This is a strict audit against a micro-learning format. The current course uses long-form chapters (~2,000-5,000 words). Low scores are expected and are NOT a quality judgment on the writing. The audit answers "how far are we from the target format?" — not "is this chapter well-written?"
+
+---
+
+## Scored Matrix
+
+| # | Chapter | Words | Hook | Outcome | Concept | Visual | Do-Now | Error | Reflect | Bridge | **Score** | Priority |
+|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
+| 1 | 1.1 Founding Hypothesis | 4,468 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 2 | 1.2a Smoke Test Build | 2,364 | NO | NO | NO | YES | PARTIAL | PARTIAL | NO | PARTIAL | **1.5** | HIGH |
+| 3 | 1.2b Smoke Test Run | 2,601 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 4 | 1.3 Price Hypothesis | 3,242 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 5 | 2.1 Mom Test | 2,931 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 6 | 2.2 AI Personas | 3,467 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 7 | 2.3a Find People | 2,721 | NO | NO | NO | YES | PARTIAL | PARTIAL | NO | PARTIAL | **1.5** | HIGH |
+| 8 | 2.3b Outreach | 2,374 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 9 | 2.4 Clickable Prototype | 5,229 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 10 | 3.1 Product Brief | 2,969 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 11 | 3.2 Outcomes Check | 2,826 | NO | NO | NO | YES | PARTIAL | PARTIAL | NO | PARTIAL | **1.5** | HIGH |
+| 12 | 4.1 Hire Decision | 3,169 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 13 | 4.2 Ownership Audit | 2,825 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 14 | 4.3a Stack Tools | 3,144 | NO | NO | NO | YES | PARTIAL | PARTIAL | NO | PARTIAL | **1.5** | HIGH |
+| 15 | 4.3b Build Phases | 3,657 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 16 | 4.4 Ceiling Signals | 4,237 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 17 | 5.1 PMF Test | 2,959 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 18 | 5.2 Channel Selection | 3,242 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 19 | 5.3 Personal Network | 3,591 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+| 20 | 5.4 Paid Pilot | 4,356 | NO | NO | NO | YES | PARTIAL | PARTIAL | NO | PARTIAL | **1.5** | HIGH |
+| 21 | 5.5 Cold Outbound | 4,060 | NO | NO | NO | YES | PARTIAL | NO | NO | PARTIAL | **1.0** | HIGH |
+
+**Median score: 1.0/8. Best score: 1.5/8 (5 chapters). Worst score: 1.0/8 (16 chapters).**
+
+> **All chapters scored HIGH priority** — no chapter exceeds 2/8. This is expected: the current format is long-form articles, not micro-lessons.
+
+---
+
+## Criterion-by-Criterion Breakdown
+
+### 1. Hook ≤3 sentences — 0/21 (0%)
+
+All chapters open with either multi-paragraph narrative vignettes or a TL;DR callout + orientation block. None have a standalone 1-3 sentence pain+win hook. The closest proxy is the TL;DR line, but it's embedded in a blockquote callout that contains 3-5 elements (TL;DR + Part-of-N + context), not a standalone hook sentence.
+
+**What exists instead:** Narrative openers like "Tuesday morning, 9:14 AM. A SaaS founder I spoke with..." or "You drafted 5-8 Mom Test questions in Ch 2.1." These are effective for deep reading but too long for micro-learning.
+
+### 2. One-sentence outcome — 0/21 (0%)
+
+No chapter contains "After this lesson you will be able to: [action]." The YAML `goal` field in `course_sequence.yaml` exists for every chapter but is metadata, not visible to the reader. The Input/Output callout states what the chapter produces, not what the reader learns to do.
+
+**What exists instead:** Input/Output callouts (e.g., "Input: Founding Hypothesis → Output: live landing page"). These are asset-focused, not skill-focused. The difference: "Output: live landing page" vs "After this lesson you will be able to: ship a 6-element landing page from your hypothesis in under an hour."
+
+### 3. Concept block ≤300 words — 0/21 (0%)
+
+All chapters have multi-section bodies of 1,000-3,000+ words with interleaved concepts, narratives, case studies, and sidebars. No chapter has a single bounded concept block of ≤300 words.
+
+**What exists instead:** Rich multi-concept bodies with headings like "Why X works," "How to Y," "What Z means." Multiple concepts, examples, and failure modes interleaved. The shortest body section in any chapter is ~500 words.
+
+### 4. Visual micro-aid — 21/21 (100%) ✓
+
+All 21 chapters have at least one informational visual: Mermaid flowcharts, SVG illustrations, decision trees, comparison diagrams, or annotated screenshots. This is the course's strongest criterion and the only one that passes universally.
+
+**Already compliant.** Visuals will need simplification for micro-lesson format (one concept per visual, per 30.03 §2.4) but the presence criterion is met.
+
+### 5. Do-this-now (3-7 steps + success check) — 0/21 full PASS, 21/21 PARTIAL
+
+All chapters have "What to do next" tables with 3-5 action steps. These partially meet the criterion: they have numbered steps in imperative form. But they fail on:
+- **Table format, not numbered list** — the 8-part template requires a plain numbered list (1. Open X. 2. Do Y.), not a 3-column table with Step/Action/Output.
+- **No success check on final step** — the tables end with "Next chapter" or "Output: X." No "You know it worked if you see X / have Y / can do Z" on the final step.
+- **Placed after long bodies** — the action appears after 2,000+ words of reading, not as a tight hook→concept→action cycle.
+
+**PARTIAL awarded for all chapters.** This is the closest criterion to passing and the easiest to fix: convert tables to numbered lists, add success checks.
+
+### 6. Error anticipation — 0/21 full PASS, 4/21 PARTIAL
+
+No chapter has the full "If this fails: [symptom]. Why: [cause]. Fix: [action]." pattern. Four chapters have "Stuck?" boxes (added in Option C migration) that approach this format: they name a common stall point and give a concrete fix. These are closer to the template than the generic "If blocked" callouts but still don't follow If/Why/Fix.
+
+**What exists instead:** "If blocked" callouts in all chapters (directional advice, not error-recovery). "Stuck?" boxes in 4+ chapters (smoke-test-build, find-10-people, stop-specifying-features, self-serve-stack, paid-pilot). Two chapters have "common mistake" sections (smoke-test-landing-page-7-day-demand-test, validation-tools-field-guide).
+
+**PARTIAL awarded for chapters with Stuck? boxes or common mistake sections.** These are the closest to the template.
+
+**5 chapters currently have Stuck? boxes** (1.2a, 2.3a, 3.2, 4.3a, 5.4 — added in Option C migration).
+
+### 7. Micro-reflection — 0/21 (0%)
+
+No chapter contains a reflection prompt ("Paste your result here," "Answer in one sentence: what changed?," "Take a screenshot"). The implicit "do the artifact" is not a reflection mechanism.
+
+**Universally missing.** This is the most significant structural gap — the course has no active-learning closure loop. Every lesson in the target format needs a 60-90 second reflection.
+
+### 8. Bridge to next lesson — 0/21 full PASS, 21/21 PARTIAL
+
+All chapters have "Next click:" links with chapter references. These partially meet the criterion: they point to the next chapter. But they fail on:
+- **Generic next-chapter reference, not a dependency bridge** — "Next click: 1.2b Smoke Test Run" vs "Next: you'll use the live page you just built to run a 7-day demand test with cold traffic."
+- **After long bodies** — the bridge is the last line after "Further reading" and "Case Study," not a tight 1-2 sentence handoff.
+
+**PARTIAL awarded for all chapters.** The fix is surgical: add a dependency-naming sentence before the "Next click" link.
+
+---
+
+## Which Chapters Are Closest to the Template?
+
+The 5 chapters at 1.5/8 (the highest score) all have "Stuck?" boxes in addition to the standard "What to do next" + "Next click" pattern:
+
+| Chapter | Why 1.5/8 |
+|---|---|
+| **1.2a Smoke Test Build** | Stuck? box + What-to-do-next table + Next click. Lowest word count (2,364). |
+| **2.3a Find People** | Stuck? box + What-to-do-next table + Next click. Has explicit keyword-search fix. |
+| **3.2 Outcomes Check** | Stuck? box + What-to-do-next table + Next click. Has "Skip to the action" anchor. |
+| **4.3a Stack Tools** | Stuck? box + What-to-do-next table + Next click. AI critic block moved before 12 rules. |
+| **5.4 Paid Pilot** | Stuck? box + What-to-do-next table + Next click. DPA template section (~400 words) could become a concept block. |
+
+These are the best candidates for piloting a full micro-lesson rewrite.
+
+---
+
+## Universal Gaps (What Every Chapter Lacks)
+
+| Gap | Impact | Fix effort |
+|---|---|---|
+| **Hook ≤3 sentences** | Student wades through 2-5 paragraphs before finding the point | Extract the pain+win line from existing TL;DR or body paragraph 1. ~2 min/chapter. |
+| **One-sentence outcome** | Student doesn't know what skill they're learning | Write "After this lesson you will be able to: [verb]." Pull from YAML `goal`. ~2 min/chapter. |
+| **Concept block ≤300 words** | Requires full structural rewrite (Option A migration) | Split each chapter into 3-5 micro-lessons with single-concept blocks. ~2-4 weeks. |
+| **Micro-reflection** | No active-learning closure; passive reading only | Add 1-2 question prompts at chapter end. ~3 min/chapter. |
+| **Error anticipation (full pattern)** | 16/21 chapters lack even a stuck box; none have If/Why/Fix | Add 1 error-recovery block per chapter. ~5 min/chapter. |
+| **Do-this-now success check** | Student finishes action steps without knowing if it worked | Add "You know it worked if..." to final step of each action table. ~2 min/chapter. |
+
+---
+
+## Migration Recommendations
+
+### Quick wins (1-2 hours, raises median from 1.0 to ~2.5/8)
+
+These are Option C-style improvements that don't require rewriting chapters:
+
+1. **Add one-sentence outcomes** — pull from YAML `goal`, format as "After this lesson you will be able to: [goal]." Place after Input/Output callout. ~2 min × 21 chapters = 42 min.
+2. **Add success checks to "What to do next" tables** — add "You know it worked if..." as the final table row. ~2 min × 21 chapters = 42 min.
+3. **Roll out Stuck? boxes to remaining 16 chapters** — the 5 chapters at 1.5/8 already have them. ~5 min × 16 chapters = 80 min.
+
+### Medium effort (raises median to ~4.0/8)
+
+4. **Convert "Next click" links to dependency bridges** — add 1 sentence naming what from this lesson the next needs before the link. ~3 min × 21 chapters = 63 min.
+5. **Add micro-reflection prompts** — 1-2 questions at chapter end. ~3 min × 21 chapters = 63 min.
+6. **Add error anticipation blocks** — If/Why/Fix pattern for the most common first-timer failure in each chapter. ~5 min × 16 remaining chapters = 80 min.
+
+### Full migration (Option A, raises median to 6.5+/8)
+
+7. **Rewrite all chapters as micro-lessons** — split 21 chapters into 60-80 micro-lessons following the 8-part template. Each lesson 400-600 words, single concept, full template. ~2-4 weeks of focused work. This is the v2 north star from 30.03 §8.
+
+---
+
+## Appendix: Per-Chapter Detail
+
+### 1.1 Founding Hypothesis (4,468 words)
+- **Hook:** Opens with 2 paragraphs of context ("Before we talk to a single customer...") before the Mad Libs frame. No 1-3 sentence pain+win line.
+- **Do-this-now:** "What to do next" table with 6 steps. Step 6 is "Write the full sentence." No success check.
+- **Error:** "If blocked" callout: "If you can't fill two or more blanks..." — directional, not If/Why/Fix.
+- **Bridge:** "Next click: 1.2a Smoke Test Build" — generic reference.
+- **Closest to template element:** The Mad Libs frame is a single-concept block (~200 words) within a much larger body. If extracted, it could become a concept block.
+
+### 1.2a Smoke Test Build (2,364 words) — Best score (1.5/8)
+- **Hook:** Opens with Module callout → Input/Output → Jump-to → TL;DR → "This is Part 1 of 2" callout. Five elements before the first body paragraph. No standalone hook.
+- **Visual:** Mermaid 5-step flowchart + element table. Strong.
+- **Do-this-now:** "What to do next" table with 4 steps. No success check.
+- **Error:** "If blocked" callout + "Stuck?" box. The Stuck? box is the closest to If/Why/Fix in any chapter.
+- **Bridge:** "Next click: 1.2b" — generic.
+
+### 5.1 PMF Test (2,959 words) — Median score (1.0/8)
+- **Hook:** Opens with "Your Lovable MVP went live last month..." narrative. 3 paragraphs before the TL;DR. No standalone hook.
+- **Do-this-now:** "What to do next" table with 5 steps. Step 5 is a decision (if/then), not a success check.
+- **Error:** "If blocked" callout: "If under 10 users responded..." — directional.
+- **Visual:** Sean Ellis gauge SVG + segment isolation Venn + Mermaid decision tree. Strong visuals.
+- **Bridge:** "Next click: 5.2 Channel Selection" — generic.
+
+### 5.4 Paid Pilot (4,356 words) — High word count representative
+- **Hook:** Opens with "Two pilots, same product, same buyer profile, different deposit timing..." comparison. No standalone hook.
+- **Do-this-now:** "What to do next" table with 3 steps. No success check.
+- **Error:** "If blocked" callout + "Stuck?" box.
+- **Visual:** Free vs paid pilot SVG + Mermaid sequence diagram. Strong.
+- **Bridge:** "Next click: 5.5 Cold Outbound" — generic.
+- **Notable:** The DPA template section (~400 words) could become a concept block if extracted.
+
+---
+
+*Built by Buffy (AI agent) as part of the 2605 Tech for Non-Technical Founders project architecture.*
diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.10-senior-pm-health-report-2026-06.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.10-senior-pm-health-report-2026-06.md
new file mode 100644
index 000000000..90baabc76
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.10-senior-pm-health-report-2026-06.md
@@ -0,0 +1,304 @@
+# 40.10 — Senior-PM Project Health Report
+
+**Audit type**: Portfolio health assessment (Three-Tier Analysis methodology)
+**Date**: 2026-06-10
+**Auditor**: Buffy (senior-pm agent)
+**Scope**: Full 2605 project docs + course content inventory + validation infrastructure
+**Methodology**: RAG composite score (Timeline 25%, Scope 20%, Quality 20%, Risk 25%, Docs 10%) + quantitative risk matrix (P×I×W) + artifact inventory audit
+
+**⚠️ Strategy update (2026-06-10)**: The current strategy is **pilot-first, then scale**. The 2 pilot lessons (1.2a, 1.2b) are being iterated to ideal quality before any Phase 2 migration begins. Phase 2 and all downstream phases are gated behind pilot perfection — the template and Sam experience must be proven on 2 lessons before fanning out to 20+. This replaces the earlier "start Phase 2 soon" stance. See §2.1 and §5 for updated recommendations.
+
+---
+
+## Executive Summary
+
+**Overall RAG**: 🟢 **GREEN (76.5/100)** — Project is healthy with strong foundations.
+
+| Dimension | Score | RAG | Key signal |
+|---|---|---|---|
+| Timeline | 70/100 | 🟡 | Pilots iterating to ideal; Phase 2 gated behind pilot perfection. |
+| Scope | 85/100 | 🟢 | v1 shipped (18 ch + 15 artifacts). v2 target well-defined (20-25 micro-lessons). No scope creep. |
+| Quality | 72/100 | 🟡 | SIPOC 10/10, validators in place. But 0/21 chapters pass v2 template (all 1.0-1.5/8). Migration is the fix. |
+| Risk | 80/100 | 🟢 | Top risks identified + mitigated. Stale docs archived. Ideas bank prevents loss. |
+| Docs | 70/100 | 🟡 | Excellent nav hub. Canonical specs exist. Minor inconsistencies persist (counts, v1/v2 framing). |
+
+**One-line verdict**: Strong foundations, clear direction, no blocking risks. Current strategy: iterate the 2 pilot lessons to ideal quality, then gate Phase 2 behind proven template + validated Sam experience.
+
+---
+
+## 1. Artifact Inventory
+
+### 1.1 Project Documentation (36 .md files, 9 archived/deferred → 27 active)
+
+| Directory | Active | Archived/Deferred | Total |
+|---|---|---|---|
+| Root (core) | 4 | 0 | 4 |
+| 10-19-research | 6 | 2 | 8 |
+| 20-29-strategy | 4 | 3 | 7 |
+| 30-39-architecture | 3 | 0 | 3 |
+| 40-49-review | 8 | 2 | 10 |
+| 50-59-execution | 2 | 2 | 4 |
+| **Total** | **27** | **9** | **36** |
+
+> Note: 50-59-execution has 2 archived (SPRINT-RUNBOOK, 50.01) and 2 active (distribution-prep.md, mechanical-audit-checklist.md). The lead-magnets/ directory was deleted; landing-page/ is a subdirectory, not a .md file. Total .md files = 36 (27 active + 9 archived).
+
+### 1.2 Core Docs — Freshness Audit
+
+| File | Last touched | Staleness risk | Notes |
+|---|---|---|---|
+| GOAL-AT-A-GLANCE.md | 2026-06-10 | ✅ Fresh | Stale-doc cleanup pass applied. Minor v1/v2 overlap in principles section. |
+| PROJECT-INDEX.md | 2026-06-10 | ✅ Fresh | v1/v2 rules split. Agent routes updated. |
+| TASK-TRACKER.md | 2026-06-10 | ✅ Fresh | Phase 0 deferred, Phase 1 findings documented, next-sprint candidates current. |
+| LOW-IMPACT-IDEAS-BANK.md | 2026-06-05 | ⚠️ Slightly stale | 5 days since last update. Low risk — ideas bank is low-churn. |
+
+### 1.3 Course Content Inventory
+
+| Metric | Count |
+|---|---|
+| Content directory entries | 56 |
+| Pages with index.md | 54 |
+| Standalone .md (_index.md) | 1 |
+| Directories (faq, quickstart) | 2 |
+| Linear chapters (course_sequence.yaml) | 20 + 1 overview (Ch 0) |
+| Reference (glossary) | 1 |
+| Companion/supplementary pages | ~30 |
+| v2 pilot micro-lessons live | 2 (smoke-test-build-page, smoke-test-wire-tracking) |
+| Artifacts/templates | 15 (Vibe PRD, Friday Demo, Ownership Checklist, SOW Guide, etc.) |
+| SVG illustrations | ~15+ |
+| Cover images | 14 spine + ~30 companion (spine regen'd, companions stale) |
+
+### 1.4 Validation Infrastructure
+
+| Asset | Size | Status |
+|---|---|---|
+| `bin/validate-course` | 1.3 KB | ✅ Active |
+| `lib/course_validators.rb` | 13.3 KB | ✅ Active |
+| `test/unit/course_validators_test.rb` | exists | ✅ Active |
+| 4 validators | chapter-number, title-yaml, internal-links, table-width | 3/4 pass; 1 has 24 pre-existing broken-citation violations |
+| `bin/hugo-build` | pre-flight hook | ✅ Active |
+| `mechanical-audit-checklist.md` | 4,535 words | ✅ Active |
+
+---
+
+## 2. Dimension Deep-Dives
+
+### 2.1 Timeline (70/100 — 🟡 AMBER)
+
+**Why not green**: The pilot lessons (1.2a, 1.2b) are being iterated to ideal quality. Phase 2 is deliberately gated behind pilot perfection — this is the right strategy, but it means the migration schedule is paused until the gate clears.
+
+| Milestone | Status | Est. effort |
+|---|---|---|
+| v1 long-form ship | ✅ Done (2026-05-20) | — |
+| v2 strategic pivot | ✅ Decided (2026-06-07) | — |
+| Phase 0 quick wins | 🔲 Deferred | ~2-3 hours |
+| Phase 1 pilot | 🔄 Iterating (2026-06-08+) | Unknown — iterating to ideal |
+| Phase 2 M1 migration | 🔲 Not started | ~2-3 days |
+| Phase 2 M2-M5 migration | 🔲 Not started | ~2-3 weeks |
+| Phase 3 cross-cutting polish | 🔲 Not started | ~2-3 days |
+
+**Schedule assessment**: The "pilot-first, then scale" strategy is correct for quality. The 2 pilot lessons are the template validation surface — every structural flaw found in the pilots prevents 20+ downstream rewrites. The 5-Sam validation pilot (real founder testing) further de-risks the template before fan-out. No hard deadline pressure — this is a quality improvement, not a fire drill.
+
+**Risk**: Stakeholder churn if pilot iteration takes >2 weeks with no visible progress. Mitigated by module-by-module independent shipping once the gate clears (Module 1 can go live while M2-M5 are still being written).
+
+### 2.2 Scope (85/100 — 🟢 GREEN)
+
+**Why green**: v1 scope delivered in full. v2 scope is well-bounded (20-25 micro-lessons). No scope creep detected. Companion pages, rescue chapters, and AI-era content are clearly separated from the linear spine.
+
+**Scope boundaries (clear)**:
+- Linear spine: 20 chapters → 20-25 micro-lessons (v2 target)
+- Companion pages: ~30 chapters, not in linear sequence
+- Rescue path: Landing page router, not chapter-level routing blocks
+- AI-era posts: Segregated as "Going further" content, Q1 2027 refresh
+
+**Weak signal**: The gap between "18 v1 chapters" (GOAL-AT-A-GLANCE) and "20 chapters in course_sequence.yaml" is resolved — the YAML count includes Chapter 0 (overview) and the glossary which are not linear chapters. The `_index.md` landing module list and YAML are now consistent.
+
+### 2.3 Quality (72/100 — 🟡 AMBER)
+
+**Why not green**: The 40.08 gap report is sobering — 0/21 chapters score above 1.5/8 against the v2 template. This is expected (v1 is long-form, not micro-lessons) but it means the entire course needs structural rewrite.
+
+**Quality assets (strong)**:
+- SIPOC 10/10 integrity — every artifact has a named consumer
+- ADR 30.02 — 15 canonical decision gates with binary thresholds
+- ADR 30.03 — complete v2 spec with 8-part template + Appendix A example
+- 4 validators running as pre-commit hooks
+- 90.11 voice guide + banned pattern grep
+- 40.01 M1-M3 audit — permanent gates in CLAUDE.md
+- Mechanical audit checklist (4,535 words, 50+ checks)
+
+**Quality gaps**:
+- 21 chapters at 1.0-1.5/8 against v2 template (expected, migration in progress)
+- 24 pre-existing broken-citation violations (internal-link validator)
+- ~30 companion-post covers with stale "Curriculum NN/30" badge
+- No automated mobile-viewport test (manual only)
+
+### 2.4 Risk Management (80/100 — 🟢 GREEN)
+
+**Why green**: Top risks identified with mitigations. Stale execution docs archived. Ideas bank prevents loss. Risk mitigation table in TASK-TRACKER covers migration-specific risks.
+
+#### Risk Matrix
+
+| # | Risk | P | I | W | Score | Strategy |
+|---|---|---|---|---|---|---|
+| R1 | Pilot iteration stretches without clear exit criteria | 3 | 3 | 0.25 | 2.25 | **Mitigate**: Define pilot exit gate: both lessons pass all 6 Sam-review tests + 5-Sam real-founder validation + 30.03 §7 QA. Gate is objective, not subjective. |
+| R2 | Bridge chain breaks during migration | 4 | 3 | 0.20 | 2.40 | **Mitigate**: Phase 3 bridge audit; don't expect bridges right on first pass |
+| R3 | Mobile viewport issues discovered late | 3 | 3 | 0.15 | 1.35 | **Mitigate**: Test each module on mobile at exit gate, not just in Phase 3 |
+| R4 | Re-introducing complexity via "improvements" | 3 | 4 | 0.15 | 1.80 | **Mitigate**: KISS feedback lives in every agent brief; advanced frameworks stay in sidebars |
+| R5 | Phase 0 deferred too long → rework after migration | 2 | 3 | 0.10 | 0.60 | **Accept**: Deferred per user direction. ~2-3 hour cost if done after migration |
+| R6 | AI-era posts decay before Q1 2027 refresh | 3 | 2 | 0.05 | 0.30 | **Mitigate**: Date-stamped; low impact (supplementary, not spine) |
+| R7 | Vendor pricing facts stale | 3 | 2 | 0.05 | 0.30 | **Mitigate**: Annual refresh cadence noted in LOW-IMPACT-IDEAS-BANK |
+| R8 | Spine drift after future restructures | 2 | 4 | 0.05 | 0.40 | **Mitigate**: 4 source-of-truth validators catch drift |
+
+**Risk heat**: No HIGH×HIGH risks. R1 (migration stalls) is the highest — mitigated by independent module shipping. R2 (bridge breaks) is expected and the Phase 3 audit is the safety net.
+
+### 2.5 Documentation Health (70/100 — 🟡 AMBER)
+
+**Why not green**: Excellent navigation and canonical specs, but minor inconsistencies persist.
+
+**Strengths**:
+- PROJECT-INDEX is an outstanding navigation hub — 3 agent routes, file-purpose tables, integration rules
+- 30.02 ADR is the canonical threshold source (15 gates, binary anchors)
+- 30.03 is the definitive v2 spec (8-part template, migration guide, Appendix A)
+- TASK-TRACKER is the single source of truth for all active work
+- LOW-IMPACT-IDEAS-BANK prevents idea loss across reviews
+
+**Weaknesses**:
+- No single "current state at a glance" dashboard — chapter counts, artifact counts, validation pass/fail scattered across 4 docs
+- Some GOAL-AT-A-GLANCE Delivery Principles still blend v1/v2 rules (marked with tags but could be cleaner)
+- 40.08 gap report references "21 chapters" but some of these are companion pages, not all are linear chapters — the count differs from `course_sequence.yaml` (22 entries)
+- No automated freshness check — docs could drift without detection
+
+---
+
+## 3. Documentation Coherence Check
+
+### 3.1 Do the core docs agree?
+
+| Claim | GOAL-AT-A-GLANCE | PROJECT-INDEX | TASK-TRACKER | YAML | Verdict |
+|---|---|---|---|---|---|
+| Course URL | `/course/...` ✅ | `/course/...` ✅ | implied ✅ | N/A | ✅ Consistent |
+| v1 chapters | "18 v1 + 2 v2 pilot" | "18 chapters" (v1) | "18 chapters" | 22 entries (incl. Ch 0 + glossary) | ⚠️ Different counting methods. YAML counts overview + glossary. Explainable. |
+| ICP (course) | Sam (first-timer) | Sam (first-timer) | "ICP - non-technical founder" | N/A | ✅ Consistent |
+| ICP (website) | Alex (burned) | Alex (burned) | N/A | N/A | ✅ Consistent |
+| v2 word count | 400-600w concept, 500-900w tool | 400-600w, 500-900w tool | per 30.03 | N/A | ✅ Consistent |
+| Phase 0 status | — | "deferred until pilot" | "DEFERRED" | N/A | ✅ Consistent |
+| Phase 1 status | "in flight" | "COMPLETE" | "✅ COMPLETE" | N/A | ⚠️ GOAL-AT-A-GLANCE says "🟡 in flight" but Phase 1 is done. PROJECT-INDEX and TASK-TRACKER are correct. |
+
+### 3.2 Cross-reference integrity
+
+All critical cross-references verified:
+- GOAL-AT-A-GLANCE → TASK-TRACKER, 30.03, 40.06, 40.08 ✅
+- PROJECT-INDEX → all review docs, research docs, strategy docs ✅
+- TASK-TRACKER → 30.03, 40.08, course_sequence.yaml ✅
+- 40.03 SIPOC → 30.02 ADR thresholds ✅
+- 40.08 gap report → 30.03 template criteria ✅
+
+**No broken doc-to-doc cross-references found.**
+
+---
+
+## 4. Key Findings
+
+### 4.1 Critical: None
+
+No blocking issues. Project is not on fire.
+
+### 4.2 High: 3 findings
+
+**F1. GOAL-AT-A-GLANCE Phase 1 status is stale**
+Says "🟡 Phase 1 (in flight)" but Phase 1 pilot is COMPLETE (2026-06-08). PROJECT-INDEX and TASK-TRACKER correctly say "COMPLETE." Fix: one-line update.
+
+**F2. No automated mobile-viewport testing**
+Phase 3 viewport test (375px iPhone SE) is manual only. At 20-25 micro-lessons, manual testing is ~1 hour and error-prone. Consider adding a Playwright screenshot diff to the validation pipeline.
+
+**F3. v1/v2 Delivery Principles overlap in GOAL-AT-A-GLANCE**
+The Delivery Principles section has inline v1/v2 tags (e.g., "**v2 micro-lessons** follow 30.03..."). These work but could be cleaner as a dedicated v2 principles subsection. Low urgency — the tags are unambiguous.
+
+### 4.3 Medium: 4 findings
+
+**F4. 24 broken-citation violations in internal-link validator**
+The `internal-link-existence` validator fails with 24 pre-existing violations. These are research article citations, not course-navigation links. Triaged as non-blocking but should be resolved or excluded from the validator.
+
+**F5. ~30 companion-post covers have stale "Curriculum NN/30" badge**
+Spine covers regenerated with "Curriculum 2026" badge. Companion covers still show the old counter. P3 task, tracked in TASK-TRACKER.
+
+**F6. 40.08 gap report "21 chapters" count differs from course_sequence.yaml "22 entries"**
+40.08 counts 21 chapters (excludes the glossary). YAML counts 22 entries (includes `five-tech-words-stop-nodding-at` as floating glossary). Not a bug — different counting methods. But could confuse an agent.
+
+**F7. No single "how many chapters do we have?" answer**
+Answer depends on what you count: linear chapters (18 v1), linear + Ch 0 (19), YAML entries (22), content directory entries (54). For new agents, this is confusing. Recommend: add a canonical inventory section to GOAL-AT-A-GLANCE.
+
+### 4.4 Low: 3 findings
+
+**F8. LOW-IMPACT-IDEAS-BANK last updated 2026-06-05**
+5 days stale. Low risk — ideas bank is low-churn.
+
+**F9. 50-59-execution directory is mostly archived (2/6 active)**
+Only `distribution-prep.md` and `mechanical-audit-checklist.md` are active. The directory is sparse but functional. Consider consolidating into a single active file.
+
+**F10. No automated doc-freshness check**
+Docs could drift without detection. Low urgency — manual review cadence (this audit) catches issues.
+
+---
+
+## 5. Recommendations
+
+### Current strategy (pilot-first, then scale)
+
+The 2 pilot lessons (1.2a smoke-test-build-page, 1.2b smoke-test-wire-tracking) are being iterated to ideal quality. Phase 2 and all downstream phases are gated behind:
+1. Both pilots pass all 6 Sam-review tests (course-lesson-review-sam)
+2. 5-Sam real-founder validation pilot confirms the template works for actual readers
+3. 30.03 §7 QA checklist passes on both pilots
+4. Template refinements from iteration are documented and applied
+
+**Once the pilot gate clears**: Module-by-module migration per TASK-TRACKER Phase 2 schedule.
+
+### Immediate (this session)
+
+| # | Action | Effort |
+|---|---|---|
+| R1 | Continue pilot lesson iteration — apply Sam simulation fixes, run Sam-review, tighten against 30.03 §7 | Ongoing |
+| R2 | Prepare 5-Sam validation pilot recruitment (indie-hackers, Reddit r/startups) | ~2 hours |
+
+### Short-term (after pilot gate clears)
+
+| # | Action | Effort | Priority |
+|---|---|---|---|
+| R3 | Start Phase 2 migration — M1.1 Founding Hypothesis per TASK-2 | ~2 hours | P1 |
+| R4 | Investigate Playwright mobile-viewport automated test | ~2 hours | P2 |
+| R5 | Split v1/v2 Delivery Principles into dedicated subsections in GOAL-AT-A-GLANCE | ~10 min | P3 |
+
+### Medium-term
+
+| # | Action | Effort |
+|---|---|---|
+| R6 | Resolve or exclude 24 broken-citation violations | ~1 hour |
+| R7 | Regenerate ~30 companion-post covers | ~2 hours |
+| R8 | Add note to 40.08 explaining chapter-count difference vs YAML (F6) | 1 min |
+
+### Long-term (Q3 2026)
+
+| # | Action |
+|---|---|
+| R9 | Add automated doc-freshness check (last-modified date vs expected refresh cadence) |
+| R10 | Consolidate 50-59-execution active files or add execution-playbook for v2 migration |
+
+---
+
+## 6. RAG Score Calculation
+
+| Dimension | Weight | Score | Weighted |
+|---|---|---|---|
+| Timeline | 0.25 | 70 | 17.50 |
+| Scope | 0.20 | 85 | 17.00 |
+| Quality | 0.20 | 72 | 14.40 |
+| Risk | 0.25 | 82 | 20.50 |
+| Documentation | 0.10 | 70 | 7.00 |
+| **Composite** | **1.00** | — | **76.40** |
+
+**RAG threshold**: 🟢 GREEN ≥ 75 | 🟡 AMBER 50-74 | 🔴 RED < 50
+
+**Verdict**: 🟢 **GREEN (76.40/100)**
+
+---
+
+*Built by Buffy (senior-pm agent) as part of the 2605 Tech for Non-Technical Founders project governance. This report should be regenerated after the pilot gate clears and Phase 2 Module 1 migration completes.*
diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.11-sam-simulation-pilot-lessons-2026-06.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.11-sam-simulation-pilot-lessons-2026-06.md
new file mode 100644
index 000000000..e94f48841
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.11-sam-simulation-pilot-lessons-2026-06.md
@@ -0,0 +1,113 @@
+# 40.11 — Sam Simulation Report — Iter 19 Pilot Lessons
+
+**Status:** Customer-research simulation — NOT field data
+**Date:** 2026-06-10
+**Method:** First-person simulation of Sam reading both v2 pilot lessons end-to-end. Verbatim reactions imputed from ICP profile (40.06 Sam Customer Journey Report — idea-stage non-technical founder, no PM background, no burn history).
+**Confidence band:** Medium-High. No real Sam has read these lessons yet.
+
+---
+
+## Summary
+
+Sam completes both lessons and reports trust. The 8-part template works — he gets a measurable success criterion in his hand and walks away knowing whether he passed. The "catalogue my mistake before I make it" lever earns his highest trust. Two friction points where Sam stalls: Mixo UI-level confusion (re-prompt, head-tag field location). These are agnostic-framing tradeoffs — the net is positive but the gap is real.
+
+**Sam's verdict**: Gets it. The agnostic framing earns trust (no lock-in feeling). CTA + hero image + incognito glosses catch terms he wasn't sure about. Stranger test gives him a specific, measurable next action.
+
+---
+
+## Beat-by-Beat Summary
+
+See full simulation in user-provided report. Key beats:
+
+- **1.2a Beat 5**: Tool-paralysis neutralized by "fastest setup" tiebreaker
+- **1.2a Beat 6**: Copy-block comparison produces actionable shame — Sam texts a friend
+- **1.2a Beat 7**: CTA legal callout: Sam was about to put "Buy now" — trust spike
+- **1.2a Beat 11**: ⚠️ Friction — Sam doesn't know what "re-prompt" means in Mixo UI
+- **1.2a Beat 14**: ⚠️ Sam on Safari — incognito shortcut Chrome-only
+
+- **1.2b Beat 2**: Load-bearing trust gate: "I don't have to WRITE the code. Just paste." Without this sentence, Sam closes the tab.
+- **1.2b Beat 6**: ⚠️ Friction — Sam doesn't know where Mixo's head-tag field is
+- **1.2b Beat 10**: Trust spike — If-fails block is honest about Clarity lag, doesn't tell Sam to ship blind
+
+---
+
+## Synthesis — Top 5 Themes
+
+### Theme 1: "I don't have to write code" (HIGH)
+
+The single sentence in 1.2b concept block ("you do not write or edit it") is the binary that determines whether Sam continues reading or closes the tab. Its absence in 1.2a Mixo UI steps creates secondary friction.
+
+**Implication:** Every step requiring tool UI interaction needs a "you don't need to know X to do this" beat.
+
+### Theme 2: "Catalogue my mistake before I make it" (HIGH)
+
+Appears 3 times across both lessons. This is the trust trigger 40.06 identifies as Sam's #1. Wherever the lesson names a specific failure mode Sam was about to repeat, it earns his strongest trust.
+
+**Implication:** Keep this pattern. Expand to Phase 2.
+
+### Theme 3: "Give me a measurable success criterion" (HIGH)
+
+Both lessons end on one. Sam walks away knowing whether he passed.
+
+**Implication:** The ✅ Success check pattern works. Continue.
+
+### Theme 4: "Specific UI cue is missing" (MEDIUM)
+
+2 friction points: Mixo re-prompt (1.2a Step 2), Mixo head-tag field (1.2b Step 2). Agnostic framing trades concrete UI cues for swappability. Net positive but gap is real.
+
+**Implication:** Each "worked example" paragraph should carry 2 tool-specific UI hints inline.
+
+### Theme 5: "Decision aid in one sentence" (MEDIUM-HIGH)
+
+Sam appreciates the "if X, pick Y; if Z, pick W" pattern.
+
+**Implication:** Expand this pattern to Phase 2.
+
+---
+
+## FIXES APPLIED (2026-06-10)
+
+| # | Pain | Lesson | Fix |
+|---|---|---|---|
+| HIGH | "Where in Mixo do I re-prompt?" | 1.2a Step 2 | Added Mixo-specific UI hint: "(in Mixo: re-edit the idea box at the top, then click Generate again)" |
+| HIGH | "Where in Mixo's settings is the head-tag field?" | 1.2b concept block | Added Mixo path: "(in Mixo: Settings → Custom Code → Header field; in Manus AI or Durable: look for 'head' or 'tracking scripts')" |
+| MEDIUM | "Do I need a domain?" | 1.2a Step 5 | Added: "Mixo gives you a free URL like yourname.mixo.io — no domain purchase needed for the smoke test." |
+| MEDIUM | "I'm on Safari, not Chrome" | 1.2a Step 5 | Added Safari, Edge, Firefox incognito shortcuts |
+| MEDIUM | "Preview mode blocks scripts" | 1.2b Step 4 | Added success check parenthetical: "(If you used the builder's preview URL instead of the published URL, scripts may be blocked — publish first, then check Clarity.)" |
+
+~80 words total. Neither lesson pushed over its current word-count band.
+
+---
+
+## Pains UNADDRESSED — Deferred
+
+| Pain | Why deferred |
+|---|---|
+| "Does the 're-prompt' instruction work for Manus AI / Durable users too?" | Single-tool hint is deliberate. If reader data shows ≥30% Carrd-fallback rate, split into parallel lessons per LOW-IMPACT-IDEAS-BANK Plan B trigger. |
+| Real Sam scroll-depth and abandonment data | Requires Clarity on live readers. See 5-Sam validation pilot below. |
+
+---
+
+## Research Gap — What We Still Don't Know
+
+| Question | How to find out |
+|---|---|
+| Do real Sams complete 1.2a in one sitting? | Recruit 3-5 idea-stage founders, post URLs, watch Clarity session recordings |
+| What % of Sams stall at the Mixo re-prompt step? | Clarity scroll-depth + session replay |
+| Do real Sams trust "tool-agnostic" framing or read it as wishy-washy? | A/B test title: "Build with an AI Page Builder" vs "Build with Mixo" — measure completion rate |
+| Does the stranger test produce signal or noise in the wild? | After 10 real Sams run it, ask what their stranger said |
+| Where does Sam abandon? | Heatmap + scroll depth on actual readers |
+
+---
+
+## Strong Recommendation
+
+**Before fanning the pattern out across 19 more Phase 2 lessons, run a 5-Sam validation pilot.** The current lessons are validated against the SPEC (8-part template) but not against the READER. If real Sams stall in places the simulation didn't predict, every Phase 2 lesson clones the same blind spot.
+
+**Method**: Recruit 3-5 idea-stage non-technical founders. Post the pilot lesson URLs. Install Clarity on these pages. Watch session recordings. Measure: completion rate, stall points, scroll depth, time-on-page. Apply findings to the Phase 2 template BEFORE writing the remaining 22 lessons.
+
+**Scheduled**: See TASK-TRACKER.md → "5-Sam Validation Pilot."
+
+---
+
+*Simulation by Sam persona model. Not field data. See 40.06 Sam Customer Journey Report for profile basis.*
diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/_ARCHIVED_40.09-mom-test-micro-lesson-qa-report.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/_ARCHIVED_40.09-mom-test-micro-lesson-qa-report.md
new file mode 100644
index 000000000..db5b4679d
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/_ARCHIVED_40.09-mom-test-micro-lesson-qa-report.md
@@ -0,0 +1,192 @@
+# QA Validation Report — Mom Test 3-Lesson Micro-Sequence (ARCHIVED)
+
+> **ARCHIVED 2026-06-08**: the 3 Mom Test lessons + paid-pilot micro-lesson sample were removed from `content/course/` per user direction (start the v2 migration from a clean slate, do not carry over exploration drafts). This document is preserved as the **canonical QA methodology pattern** - agents running revision passes should copy the binary-scoring + criterion-by-criterion structure from this report. The specific lesson scores below are historical and reference content that no longer exists in the repository.
+
+**Checklist:** 30.03 §7 Per-Lesson QA
+**Date:** 2026-06-07 (audit performed) · 2026-06-08 (archived)
+**Files audited (now removed):**
+- `mom-test-lesson-1-5-questions/index.md` — The 5 Questions with Pass/Fail Signals
+- `mom-test-lesson-2-emotional-flags/index.md` — The 3 Emotional Language Flags
+- `mom-test-lesson-3-run-score-interview/index.md` — How to Run and Score a Real Interview
+
+**Method:** Strict binary scoring against the 7 per-lesson criteria in 30.03 §7. Partial compliance = FAIL. The checklist asks "does this lesson meet the target format?" — not "is this a good lesson?"
+
+---
+
+## Scoring Key
+
+| Symbol | Meaning |
+|---|---|
+| ✅ PASS | Fully meets the criterion |
+| ⚠️ MARGINAL | Meets the letter but not the spirit, or borderline on a numeric threshold |
+| ❌ FAIL | Does not meet the criterion |
+
+---
+
+## Criterion-by-Criterion Results
+
+### C1: One clearly stated outcome? (30.03 §2.2)
+
+| Lesson | Outcome | Verdict |
+|---|---|---|
+| 1 | *"write a draft list of 5-8 Mom Test questions anchored in past behavior, with pass/fail signals for each."* | ✅ PASS — Observable action, verifiable |
+| 2 | *"identify frustration language, workaround language, and urgency language in an interview transcript, and count flags to separate strong signal from polite default."* | ✅ PASS — Observable skill, verifiable |
+| 3 | *"run a 30-minute Mom Test interview following the 5-question script in order, score the call 1-10 within 5 minutes of hanging up, and classify it as strong signal, polite default, or no problem."* | ✅ PASS — Observable action, verifiable |
+
+**C1 score: 3/3 PASS**
+
+---
+
+### C2: Observable success check on final Do-this-now step? (30.03 §2.5)
+
+| Lesson | Success check | Verdict |
+|---|---|---|
+| 1 | *"You know you're done when all 5-8 questions start with 'Tell me about the last time' or 'What did you do when.'"* | ✅ PASS — Concrete, self-verifiable |
+| 2 | *"Can you give a concrete quote for each? If you can't imagine the words, your hypothesis problem blank isn't specific enough."* | ✅ PASS — Concrete, gates forward progress |
+| 3 | *"You have three numbers written down — Q4 self-rating, flag count, final 1-10 score. All three were written within 5 minutes of hanging up."* | ✅ PASS — Three concrete deliverables, time-gated |
+
+**C2 score: 3/3 PASS**
+
+---
+
+### C3: Total reading ≤10 minutes (~400-600 words for email, ~500-800 for web)? (30.03 §1.2, §1.7)
+
+Word counts are total file (including frontmatter, Input/Output callout, Done when, Next click, If blocked, Case Study, and footer). Core 8-part body is estimated at ~70-75% of total.
+
+| Lesson | Total words | Est. body words | Est. read time (200 wpm) | Verdict |
+|---|---|---|---|---|
+| 1 | 972 | ~650 | ~3.3 min | ✅ PASS — Within web band (500-800) |
+| 2 | 1,085 | ~730 | ~3.7 min | ✅ PASS — Within web band (500-800) |
+| 3 | 1,147 | ~780 | ~3.9 min | ✅ PASS — Within web band (500-800) |
+
+> **Note:** The 30.03 §1.7 spec says web pages can be 500-800 words since the reader has chosen to visit. These are Hugo web pages with `draft: true`. All three are within the web band. For push-based email delivery (400-600 target), Lesson 3 would need trimming by ~80-180 words.
+
+**C3 score: 3/3 PASS** (web format)
+
+---
+
+### C4: Total implementation ≤15 minutes for an average non-professional? (30.03 §7)
+
+| Lesson | Estimated do time | Rationale | Verdict |
+|---|---|---|---|
+| 1 | ~10-15 min | Copy 5 questions (2 min), personalize blanks (3 min), write 2-3 follow-ups (5 min), verify all past-tense (2 min). Ambitious but realistic. | ✅ PASS |
+| 2 | ~10-15 min | Read transcript (1 min), count flags (3 min), score (1 min), write 3 concrete quotes for own hypothesis (5-7 min). The quote-writing step is well-bounded — the student is writing example phrases, not real interview transcripts. | ✅ PASS |
+| 3 | ~30-40 min | Find a practice interviewee (5-10 min), run 20-min interview (20 min), score within 5 min (5 min). The interview itself is 20 minutes minimum — the "find a friend" step adds overhead. | ❌ FAIL — Exceeds 15 min even without the friend-finding step |
+
+> **Lesson 3 note:** The do time is inherently longer because the task IS a 30-minute interview. The spec says "≤15 minutes for an average non-professional." A 30-minute interview (20 min minimum per the step instructions) plus 5 minutes of prep and 5 minutes of scoring = 30+ minutes. This is a genuine tension: the action the lesson teaches cannot be compressed below its natural duration. Options: (a) accept the exception for "run a live interview" lessons, (b) split the "run practice interview" into its own lesson separate from the "score the interview" concept, or (c) make the practice interview a "time-box to 15 min" exercise (ask Q1-Q2 only).
+
+**C4 score: 2/3 PASS** (1 MARGINAL, 1 FAIL)
+
+---
+
+### C5: Any theory/content that does not directly support a concrete action? (30.03 §1.3 Action Mapping rule)
+
+| Lesson | Check | Verdict |
+|---|---|---|
+| 1 | Concept block: past-tense principle → 5 questions with pass/fail → closing warning about improv. All content directly supports writing the question list. No theory without action hook. | ✅ PASS — Clean |
+| 2 | Concept block: 3 flag tables → scoring rule. Do-this-now: sample transcript exercise → concrete quote exercise. All content ties to the flag-counting skill. | ✅ PASS — Clean |
+| 3 | Concept block: interview flow → scoring rubric → scoring rule → build/pivot/kill thresholds. **The build/pivot/kill thresholds refer to "after all 10 interviews" — they arrive before the student has run even one.** Counterargument: the thresholds provide essential context for why scoring matters NOW (a student who scores 8/10 can check the table and think "if all 10 are like this, BUILD"). The content is forward-looking but motivational. | ⚠️ MARGINAL — Borderline; could reasonably be reclassified PASS if the motivational framing is accepted. The core issue: the threshold belongs in the "what this means" section of the concept block, not as a standalone forward-reference. |
+
+**C5 score: 2/3 PASS** (1 MARGINAL)
+
+---
+
+### C6: Can a low-interest, high-pain learner see tangible benefit within 10 minutes and progress without external help? (30.03 §7)
+
+This criterion has two sub-questions scored separately:
+
+| Lesson | (a) Tangible benefit ≤10 min? | (b) Self-guided? | Composite |
+|---|---|---|---|
+| 1 | ✅ — Hook + concept + first 2 do-steps completable in ~5 min. Student has 5 copied questions personalized within 10 min. | ✅ — Error recovery covers most common stall. | ✅ PASS |
+| 2 | ✅ — Sample transcript exercise is immediate. Student counts flags and scores within ~5 min of starting. | ✅ — Error recovery covers "can't hear any flags." If blocked offers G2 review fallback. | ✅ PASS |
+| 3 | ⚠️ — Concept block (interview flow + rubric + thresholds) takes ~4 min to read. Then step 1 is "find a friend" — a blocking step that requires another human. Tangible benefit (a scored interview) arrives at minute 30+. | ⚠️ — The "can't find a practice interviewee" fallback is buried in If-blocked, not in the main path. | ⚠️ MARGINAL |
+
+**C6 score: 2/3 PASS** (1 MARGINAL)
+
+---
+
+### C7: 8-part template followed exactly and in order? (30.03 §2)
+
+| Lesson | Hook | Outcome | Concept | Visual | Do Now | Error | Reflection | Bridge | Verdict |
+|---|---|---|---|---|---|---|---|---|---|
+| 1 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ PASS |
+| 2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ PASS |
+| 3 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ PASS |
+
+**C7 score: 3/3 PASS**
+
+---
+
+## Aggregate Scores
+
+| Lesson | C1 | C2 | C3 | C4 | C5 | C6 | C7 | PASS/FAIL |
+|---|---|---|---|---|---|---|---|---|
+| **L1: 5 Questions** | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | **7/7 PASS** |
+| **L2: Emotional Flags** | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | **7/7 PASS** |
+| **L3: Run & Score** | ✅ | ✅ | ✅ | ❌ | ⚠️ | ⚠️ | ✅ | **4/7 PASS** (1 FAIL, 2 MARGINAL) |
+
+---
+
+## Critical Findings
+
+### Lesson 3: Implementation time exceeds 15-minute cap (C4 — FAIL)
+
+**Problem:** Do-this-now step 2 says "Find a friend, a co-founder, or anyone willing to be a practice interviewee" and step 3 says "Run Q1-Q5 in order" — a 20-minute minimum interview. Total do time is 30+ minutes against a 15-minute cap.
+
+**Severity:** Structural. The action the lesson teaches cannot be compressed.
+
+**Remediation options (ranked by effort):**
+1. **Accept the exception** — "run a live interview" lessons have an inherent 30-minute floor. Document this as a known category of exception in 30.03. The other 19-24 micro-lessons in the full migration won't have this problem (most actions are solo: write, configure, send, check).
+2. **Time-box the practice** — rewrite step 3 as "Ask only Q1-Q2 (10 minutes). Skip Q3-Q5." This cuts do-time to ~15 min while still teaching the flow and scoring mechanic. The student gets the full 5-question experience in the first real interview (Lesson 3's output is a practice score, not a final validated transcript).
+3. **Split the lesson** — Lesson 3a: "Score a sample transcript" (≤15 min, solo). Lesson 3b: "Run your first practice interview" (30+ min, acknowledged exception). This doubles the lesson count but preserves the 15-minute cap for all non-interview lessons.
+
+**Recommendation:** Option 2 (time-box) for immediate fix. Option 1 (accept exception) documented in 30.03 as a known architectural decision.
+
+### Lesson 3: Build/pivot/kill thresholds are forward-looking (C5 — MARGINAL)
+
+**Problem:** The concept block includes the "after all 10 interviews" threshold table. This is a synthesis-level concept that the student can't act on during a single-practice-interview lesson.
+
+**Fix:** Move the build/pivot/kill thresholds to the bridge section ("Next: after 10 interviews, you'll use this threshold to decide build/pivot/kill") or create a Lesson 4 (Synthesis). Keep the 1-10 individual-call rubric in the concept block — that's directly actionable.
+
+### Lesson 2: Concrete-quote writing step can stretch past 15 min (C4 — MARGINAL)
+
+**Problem:** Step 4 asks the student to write one frustration phrase, one workaround phrase, and one urgency phrase for their hypothesis. If the hypothesis problem blank is vague, the student can't generate concrete quotes and gets stuck.
+
+**Mitigation:** The success check already gates this — "if you can't imagine the words, go back to Lesson 1.1." Fine as-is, but the time estimate is fragile.
+
+---
+
+## Non-Issues (Verified OK)
+
+| Claim | Check |
+|---|---|
+| All hooks ≤3 sentences | ✅ L1: 3 sentences. L2: 3 sentences ("Your interviewee said..." / "The three words..." / "In this lesson..."). L3: 3 sentences — verified by sentence-counting in this report, not delegated. |
+| All concept blocks ≤300 words | ✅ Labeled 280/180/300. Actual counts slightly under labels. All under 300. |
+| All error recovery follows If/Why/Fix | ✅ Pattern confirmed in all 3. Most common failure modes correctly identified. |
+| All bridges name a specific dependency | ✅ L1→L2 (flags), L2→L3 (combine questions+flags), L3→recruitment (script ready, need names). |
+| Case Studies consistent across sequence | ✅ Tomas/Mia examples carry through all 3 with consistent numbers and quotes. |
+| Tables ≤3 columns | ✅ Flag tables are 2 columns. Scoring rubric is 4 columns — borderline but readable. |
+| No em-dash violations | ✅ Zero em-dashes in all 3 files (verified via grep). |
+| Frontmatter correct | ✅ All 3: `draft: true`, `course_chapter: false`, tags: `example-lesson`. |
+
+> **Word count methodology note:** Total word counts (972/1085/1147) include YAML frontmatter (~100 words), Input/Output callout (~40 words), Done when + Next click + If blocked (~60 words), Case Study (~60 words), and footer (~20 words). Estimated body words (650/730/780) = total minus ~320 words of structural content. Read times calculated at 200 wpm for instructional text.
+
+---
+
+## Summary
+
+| Metric | Score |
+|---|---|
+| Total criteria checked | 21 (7 criteria × 3 lessons) |
+| PASS | 18 |
+| MARGINAL | 2 |
+| FAIL | 1 |
+| **Overall pass rate** | **86% PASS, 95% non-failing** |
+
+**Verdict:** Lessons 1 and 2 are ready for the template showcase. Lesson 3 has one structural issue (C4 implementation time) and one context-placement issue (C5 forward-looking thresholds) — both fixable with the remediation options above.
+
+The sequence as a whole demonstrates that the 8-part template produces consistent, scannable, action-first lessons. The 3-lesson split validates the core hypothesis of the format: dense content (a single 2,931-word chapter) becomes 3 sharply scoped lessons where the student always knows what to do next.
+
+---
+
+*Built by Buffy (AI agent) as part of the 2605 Tech for Non-Technical Founders QA process. Reference: 30.03 §7.*
diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/_DEFERRED_40.02-post-ship-retrospective.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/_DEFERRED_40.02-post-ship-retrospective.md
new file mode 100644
index 000000000..331106efa
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/_DEFERRED_40.02-post-ship-retrospective.md
@@ -0,0 +1,55 @@
+# Post-Ship Retrospective — 2605 Tech for Non-Technical Founders
+
+**Created**: 2026-05-29 (stub)
+**Last updated**: 2026-05-29
+**Project**: 2605-tech-for-non-technical-founders
+**Status**: 🟡 Stub — fill after ≥2 weeks of live data
+
+---
+
+## Purpose
+
+Capture what went well, what went wrong, and what to change for the next curriculum project. Fill this after the course has been live for at least 2 weeks with real traffic, shares, and email captures.
+
+---
+
+## Data Points to Collect
+
+| Metric | Source | Notes |
+|--------|--------|-------|
+| Page views per chapter | Analytics | Which chapters have highest/lowest read-through? |
+| Email captures (artifact downloads) | Email platform | Which artifacts convert best? |
+| Reddit shares + upvotes | Reddit/manual | Which posts earned organic traction? |
+| LinkedIn engagement | LinkedIn analytics | Paul Keen posts — which module topics resonated? |
+| Bounce rate on landing page | Analytics | Does the landing page hook or confuse? |
+| Course completion proxy (module N→N+1 navigation) | Analytics | How many readers reach Module 3+? |
+
+---
+
+## Retrospective Template
+
+### ✅ What went well
+
+- *[Fill after data collection]*
+
+### ❌ What didn't work
+
+- *[Fill after data collection]*
+
+### 🔧 What to change for next project
+
+- *[Fill after data collection]*
+
+### 📊 Surprises
+
+- *[Unexpected patterns in engagement, share velocity, reader dropoff]*
+
+---
+
+## Action Items
+
+| Priority | Action | Owner |
+|----------|--------|-------|
+| P2 | Fill data points after 2 weeks live | — |
+| P1 | Course completion path tracking setup | — |
+| P3 | Quarterly refresh sweep for AI-era posts (Q1 2027) | — |
diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/_DEFERRED_external-validation-pilot-kit.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/_DEFERRED_external-validation-pilot-kit.md
new file mode 100644
index 000000000..18579ca66
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/_DEFERRED_external-validation-pilot-kit.md
@@ -0,0 +1,105 @@
+# [DEFERRED] External 5-Sam Validation Pilot Kit
+
+**Status:** DEFERRED until course complete — DO NOT execute now
+**Created:** 2026-06-11
+**Trigger to revive:** v2 micro-lesson migration is fully shipped (all 22 remaining lessons + companions + landing page polish). Course is "done." THEN consider external validation.
+**Why deferred:** Course content work is the current focus. Promoting / selling / soliciting external Sams happens after the course is complete, not during template iteration. The 2 pilot lessons (1.2a + 1.2b) are validated INTERNALLY by Paul as the buyer of the migration template, NOT externally by recruited Sams.
+
+---
+
+## When to revive this
+
+Run this kit only when ALL of the following are true:
+
+1. Phase 2 migration complete — all 22 v1 long-form chapters migrated to v2 micro-lessons (5 modules × 4–6 lessons each, per 30.03 spec)
+2. Course landing page + Quickstart + FAQ + glossary all reflect v2 structure
+3. Paul approves the v2 template as locked
+4. We want external validation signal (real-Sam Clarity recordings + post-read survey) BEFORE promoting the course publicly
+
+If you're not at step 4, this kit is the wrong artifact. Keep iterating on content.
+
+---
+
+## What the kit covers (skeleton — flesh out at revival time)
+
+### A. Recruitment screener (6 questions)
+
+Gate idea-stage Sam, exclude burned-founder Alex (wrong ICP for course design).
+
+- Q1 unvalidated idea? · pass: yes
+- Q2 paid an agency? · pass: no (yes → that's Alex)
+- Q3 technical level? · pass: no-code-only or avoid-anything-technical
+- Q4 reads long articles on phone? · pass: weekly+
+- Q5 can spend ~45 min in next 5 days? · pass: yes
+- Q6 one-sentence idea (open-text) · pass: concrete idea
+
+Diversity target: ≥1 each across age band, device, idea domain (B2B/B2C/marketplace/services). Reject Web3/crypto.
+
+### B. Outreach channels (lead with fastest)
+
+1. Personal-network DM (≤120-word script, $25 Amazon gift card promised)
+2. Indie Hackers "Ask IH" post
+3. Reddit r/startups / r/Entrepreneur (mod-approval-dependent)
+
+Anti-channels: public Twitter/LinkedIn (skews to JT followers — biased), HN (wrong ICP), Product Hunt (wrong stage), JT email list (biased).
+
+### C. Participant brief
+
+- Welcome email with 2 URLs (smoke-test-build-page + smoke-test-wire-tracking) + post-read survey link
+- Hard rules: no coaching during read, no extra URLs shared, save reactions for the survey
+- Two URLs only — no landing page or FAQ added (would dilute the test)
+
+### D. Post-read questionnaire (10 blocks)
+
+Designed to answer 5 research questions from 40.11:
+- Q1 (complete in one sitting?) → time + completion blocks
+- Q2 (stall points?) → multi-select stall list per lesson + open-text
+- Q3 (tool-agnostic framing trust?) → 5-point Likert + open-text (KEY — Clarity cannot answer this)
+- Q4 (stranger test signal?) → yes/no + what-they-said open-text (KEY — Clarity cannot answer this)
+- Q5 (abandonment reasons?) → step/paragraph specificity + open-text
+
+Plus cross-lesson decision-aid Q + verbatim most-useful and most-useless sentence Q + NPS-style recommend Q.
+
+### E. Observer protocol
+
+Per-Sam Clarity observation log: device, browser, time-on-page per lesson, scroll depth, rage/dead clicks, stall beats with timestamps (≥30 s no-scroll no-tab-switch = stall), surprise observations.
+
+Systemic stall = ≥2 Sams stall at same beat. Trigger for "fix template before fan-out" (but at deferral time, template is already fanned out — so trigger becomes "post-launch template patch + re-pilot subset").
+
+### F. Synthesis template
+
+- 40.11 predictions vs reality scorecard (5 themes + 2 fixes from 2026-06-10)
+- Unpredicted findings (highest-value bucket)
+- Quote bank (5–10 verbatim Sam quotes tagged pain/trust/language/objection)
+- Per-research-question answer with confidence (High = 3+ Sams agree, Med = 2, Low = 1)
+
+### G. Decision gate
+
+6-row matrix mapping (completion × systemic stall × confidence) → action. At post-launch revival, decisions become:
+- GO public promotion: ≥3 Sams complete, no systemic stall, High/Med-High confidence
+- Patch + re-pilot subset: 1 systemic stall
+- Patch + extended re-pilot: ≥2 systemic stalls
+- Wait/recruit more: <3 Sams complete
+
+---
+
+## Prerequisites (revive these at revival time)
+
+- **Microsoft Clarity install** on `/course/` pages only (scope-limited Hugo partial). Cookie/consent posture decided in its own commit, not bundled with revival of this kit.
+- **Cookie/consent UX** — confirm or add before Clarity ships
+- **Budget approval** — default $25 × 5 = $125 incentive cap
+- **Calendar slot for Paul** — ~5 hours total across screener-review, brief-send, session-watching, synthesis
+
+---
+
+## What this kit does NOT cover
+
+- Promoting the finished course publicly (separate channel-launch playbook)
+- Email-capture-on-artifact funnel (separate post-launch work)
+- Cross-channel content distribution (separate playbook)
+
+---
+
+## Index entry
+
+Logged in `LOW-IMPACT-IDEAS-BANK.md` → "Paused / Deferred" table under "External validation pilot kit."
diff --git a/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/_ARCHIVED_50.01-phase-1-implementation-plan.md b/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/_ARCHIVED_50.01-phase-1-implementation-plan.md
new file mode 100644
index 000000000..85f9a2d56
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/_ARCHIVED_50.01-phase-1-implementation-plan.md
@@ -0,0 +1,1333 @@
+# ⚠️ ARCHIVED — DO NOT EXECUTE
+
+**Archived:** 2026-06-10
+**Why:** This Phase 1 plan restructures a 9-module course to 6 modules at `content/blog/`. The course now lives at `content/course/tech-for-non-technical-founders-2026/` with a 5-module spine and is mid-migration to v2 micro-lessons (30.03 spec).
+**Replaced by:** `TASK-TRACKER.md` "Course Migration Schedule" and the cold-agent route in `PROJECT-INDEX.md`. Tasks 1-23 in this plan would delete, rename, and restructure files using wrong paths — DO NOT execute.
+**Historical reference only.** Read `30-39-architecture-design/30.03-course-format-requirements-for-creators.md` for the current lesson format spec.
+
+---
+
+# JT Course Spine Phase 1 Implementation Plan (ARCHIVED)
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Restructure the JT "Tech for Non-Technical Founders 2026" course from current 9-module / 34-chapter sprawl to a 6-module / ~24-chapter core spine that gets a newbie non-technical founder to first paying customer in 90 days.
+
+**Architecture:** 6 sequential modules (Hypothesis → Test Demand → Validate Problem → Design from Evidence → Build It Yourself → First Paying Customer). Continuation chapters live as "Going further" callouts at end of Module 6, not as separate modules. Module 0 deleted entirely. AI-augmented method explicit per module.
+
+**Tech Stack:** Hugo static site, Markdown content with YAML frontmatter, `data/course_sequence.yaml` as truth source for module/chapter sequence, Hugo `aliases:` frontmatter for 301 redirects.
+
+**Spec:** `docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.09-spine-3-rollout-design.md`
+
+---
+
+## File Structure
+
+### Files deleted (chapter directories removed entirely)
+
+- `content/blog/salvage-vs-rebuild-software-project/`
+- `content/blog/switch-dev-shops-safely-transition-guide/`
+- `content/blog/cheap-developers-expensive-without-cto-review/`
+- `content/blog/asked-simple-admin-panel-built-spaceship/`
+- `content/blog/market-type-existing-resegmented-new/`
+- `content/blog/validated-problem-statement-decide-whats-next/` (after fold)
+- `content/blog/course-map-self-assessment-non-technical-founder-2026/` (Module 0 deletion)
+- 4 hire-track directories (after collapse): `who-where-hire-developer-2026-ai-augmented-offshore/`, `fractional-cto-bridge-5-hours-week/`, `hiring-interview-catches-ai-theater/`, `reading-sow-clause-by-clause/`
+
+### Files created
+
+- `content/blog/price-hypothesis-on-smoke-test-page/index.md` (NEW Module 2)
+- `content/blog/ai-persona-pre-validation-mom-test-prep/index.md` (NEW Module 3)
+- `content/blog/clickable-prototype-validation-2-hour-lovable/index.md` (NEW Module 3)
+- `content/blog/channel-selection-before-outbound/index.md` (NEW Module 6)
+- `content/blog/hire-track-supplementary-reference/index.md` (collapsed from 4 hire-track chapters)
+
+### Files modified
+
+- `data/course_sequence.yaml` (rebuild from new spine)
+- `content/blog/tech-for-non-technical-founders-2026/index.md` (landing — full restructure)
+- 7 chapter files (reframes): see Task 11-17
+- 4 management chapter files (demoted with stripped course-nav): see Task 18
+- 3 AI-era hygiene files (demoted with stripped course-nav): see Task 19
+- 1 chapter (mom-test) absorbs folded content: see Task 5
+- 1 chapter (find-10-people) gets recruitment-distinction note: see Task 13
+- 1 chapter (outbound-without-sales-team) gets sales-distinction note: see Task 14
+
+### Files NOT touched (KEEP as-is)
+
+- `content/blog/form-your-founding-hypothesis-90-minute-sprint/index.md` (Module 1)
+- `content/blog/one-page-product-brief-vibe-prd/index.md` (Module 4)
+- `content/blog/stop-specifying-features-start-outcomes/index.md` (Module 4)
+- `content/blog/github-aws-database-ownership-checklist/index.md` (Module 5 — Day-1 task)
+- `content/blog/must-have-segment-pmf-test/index.md` (Module 6)
+- `content/blog/first-ten-customers-personal-network/index.md` (Module 6)
+- `content/blog/paid-pilot-charge-before-ship/index.md` (Module 6)
+- `content/blog/customers-leaving-churn-triage-not-acquisition/index.md` (continuation)
+- `content/blog/pivot-or-persevere-decision-framework/index.md` (continuation)
+- `content/blog/five-tech-words-stop-nodding-at/index.md` (floating glossary)
+
+---
+
+## Verification gates (run after every task that modifies files)
+
+```bash
+bin/hugo-build          # Hugo builds without errors
+grep -rn '—' content/blog// # zero em-dashes (use - not —)
+rg -l '/blog//' content/    # zero broken inbound links
+```
+
+For voice-sensitive changes (reframes + new chapters), additional gate:
+- Invoke `reflexion-reflect` skill on the changed chapter before commit
+- Slop detector score must be ≤25/100 per CLAUDE.md voice rules
+- Cross-post repetition scan per CLAUDE.md cluster rules
+
+---
+
+## Task 1: Cut 5 chapters with no rehoming
+
+**Files:**
+- Delete: `content/blog/salvage-vs-rebuild-software-project/`
+- Delete: `content/blog/switch-dev-shops-safely-transition-guide/`
+- Delete: `content/blog/cheap-developers-expensive-without-cto-review/`
+- Delete: `content/blog/asked-simple-admin-panel-built-spaceship/`
+- Delete: `content/blog/market-type-existing-resegmented-new/`
+
+- [ ] **Step 1: List inbound links to be repaired** (run before delete to catch references)
+
+```bash
+for slug in salvage-vs-rebuild-software-project switch-dev-shops-safely-transition-guide cheap-developers-expensive-without-cto-review asked-simple-admin-panel-built-spaceship market-type-existing-resegmented-new; do
+  echo "=== $slug ==="
+  rg -l "/blog/$slug/" content/ data/ 2>/dev/null | grep -v "$slug/index.md"
+done
+```
+
+Expected: Some references in chapter cross-links + landing module index. Capture this list — it determines what Task 2 fixes.
+
+- [ ] **Step 2: Delete the 5 chapter directories**
+
+```bash
+rm -rf content/blog/salvage-vs-rebuild-software-project/
+rm -rf content/blog/switch-dev-shops-safely-transition-guide/
+rm -rf content/blog/cheap-developers-expensive-without-cto-review/
+rm -rf content/blog/asked-simple-admin-panel-built-spaceship/
+rm -rf content/blog/market-type-existing-resegmented-new/
+```
+
+- [ ] **Step 3: Verify Hugo build still passes**
+
+```bash
+bin/hugo-build
+```
+
+Expected: builds successfully (broken-link warnings acceptable here — Task 2 fixes them).
+
+- [ ] **Step 4: Commit**
+
+```bash
+git add -A content/blog/
+git commit -m "content(course): cut 5 chapters per Phase 1 spine (rescue + theoretical removed)"
+```
+
+---
+
+## Task 2: Repair inbound links from cut chapters
+
+**Files (modified, exact set determined by Task 1 Step 1 output):**
+- Likely: `content/blog/customers-leaving-churn-triage-not-acquisition/index.md`
+- Likely: `content/blog/pivot-or-persevere-decision-framework/index.md`
+- Likely: `content/blog/tech-for-non-technical-founders-2026/index.md` (landing — Module 8 reference will go in Task 21)
+
+- [ ] **Step 1: For each file in Task 1 Step 1 output, replace broken link**
+
+For links to `salvage-vs-rebuild-software-project`: replace with reference to "Salvage or Rebuild decision framework (continuation chapter)" or remove entirely if context allows.
+
+For links to `switch-dev-shops`: same pattern — reference removed or rewritten.
+
+For links to `market-type`: remove entirely (chapter was theoretical, no replacement).
+
+Edit each file using the Edit tool with exact old/new strings. Show the change in commit message.
+
+- [ ] **Step 2: Verify zero broken inbound links remain**
+
+```bash
+for slug in salvage-vs-rebuild-software-project switch-dev-shops-safely-transition-guide cheap-developers-expensive-without-cto-review asked-simple-admin-panel-built-spaceship market-type-existing-resegmented-new; do
+  echo "=== $slug ==="
+  rg -l "/blog/$slug/" content/ data/ 2>/dev/null | grep -v "$slug/index.md"
+done
+```
+
+Expected: zero output for each.
+
+- [ ] **Step 3: Commit**
+
+```bash
+git add content/blog/
+git commit -m "content(course): repair inbound links to cut chapters"
+```
+
+---
+
+## Task 3: Fix missing slug for "Your First Customer Is Not Marketing"
+
+**Files:**
+- Modify: `data/course_sequence.yaml`
+
+- [ ] **Step 1: Locate the broken entry**
+
+```bash
+rg -n -B1 -A2 "Your First Customer" data/course_sequence.yaml
+```
+
+Expected: an entry missing the `slug:` line. Note line number.
+
+- [ ] **Step 2: Add the missing slug field**
+
+The slug should be `must-have-segment-pmf-test` (verified by `ls content/blog/must-have-segment-pmf-test/`).
+
+Use Edit to add `    slug: must-have-segment-pmf-test` line in the correct position (between the `- ` start and the `title:` line).
+
+- [ ] **Step 3: Verify YAML parses**
+
+```bash
+bin/hugo-build
+```
+
+Expected: no YAML parse errors.
+
+- [ ] **Step 4: Commit**
+
+```bash
+git add data/course_sequence.yaml
+git commit -m "data: fix missing slug for must-have-segment-pmf-test entry"
+```
+
+---
+
+## Task 4: Apply 1 fold (validated-problem-statement → mom-test)
+
+**Files:**
+- Read: `content/blog/validated-problem-statement-decide-whats-next/index.md`
+- Modify: `content/blog/mom-test-ask-about-past-not-future/index.md`
+- Delete: `content/blog/validated-problem-statement-decide-whats-next/`
+
+- [ ] **Step 1: Read the source chapter to identify the synthesis content to fold**
+
+```bash
+cat content/blog/validated-problem-statement-decide-whats-next/index.md
+```
+
+Identify the SYNTHESIS section (typically the "writing the validated problem statement" portion) — this is what gets folded into mom-test's closing.
+
+- [ ] **Step 2: Append the synthesis section as the closing of mom-test chapter**
+
+Open `content/blog/mom-test-ask-about-past-not-future/index.md`. Find the existing "## Further reading" or end-of-content marker. Insert a new H2 section BEFORE it: `## Synthesis: Write Down What You Heard, Decide What's Next` with the folded content from validated-problem-statement.
+
+Add a one-line opening: "After your 10 interviews, you have 4 hours of notes. The synthesis below turns notes into the one-page validated problem statement that anchors Module 4."
+
+- [ ] **Step 3: Repair inbound links to validated-problem-statement**
+
+```bash
+rg -l '/blog/validated-problem-statement-decide-whats-next/' content/ data/ 2>/dev/null
+```
+
+For each match, replace `/blog/validated-problem-statement-decide-whats-next/` with `/blog/mom-test-ask-about-past-not-future/#synthesis-write-down-what-you-heard-decide-whats-next` (Hugo auto-generates the anchor from the H2 text).
+
+- [ ] **Step 4: Delete the source chapter directory**
+
+```bash
+rm -rf content/blog/validated-problem-statement-decide-whats-next/
+```
+
+- [ ] **Step 5: Verify**
+
+```bash
+bin/hugo-build
+rg -l '/blog/validated-problem-statement-decide-whats-next/' content/ data/ 2>/dev/null
+```
+
+Expected: build passes, zero residual inbound links.
+
+- [ ] **Step 6: Commit**
+
+```bash
+git add -A content/blog/
+git commit -m "content(course): fold validated-problem-statement into mom-test as synthesis section"
+```
+
+---
+
+## Task 5: Collapse 4 hire-track chapters into 1 reference page
+
+**Files:**
+- Create: `content/blog/hire-track-supplementary-reference/index.md`
+- Read: 4 source chapters
+- Delete: 4 source chapter directories after collapse
+
+- [ ] **Step 1: Read all 4 source chapters**
+
+```bash
+for slug in who-where-hire-developer-2026-ai-augmented-offshore fractional-cto-bridge-5-hours-week hiring-interview-catches-ai-theater reading-sow-clause-by-clause; do
+  echo "=== $slug ==="
+  cat content/blog/$slug/index.md
+  echo ""
+done
+```
+
+Identify the strongest 1-2 sections per chapter. Discard preamble/repetitive context.
+
+- [ ] **Step 2: Write the collapsed reference page**
+
+Create `content/blog/hire-track-supplementary-reference/index.md` with frontmatter:
+
+```yaml
+---
+title: "Hire Track Supplementary Reference"
+description: "When you've reached the ceiling of self-serve and need to hire: where to find developers, the Fractional CTO bridge, interviews that catch AI theater, and how to read an SOW. Reference content - return when ready."
+date: 2026-07-01
+draft: false
+author: "JetThoughts Team"
+slug: hire-track-supplementary-reference
+keywords:
+  - hire developer non technical founder
+  - fractional cto
+  - hire dev shop sow
+  - vet developer ai theater
+tags:
+  - founders
+  - non-technical-founder
+  - hire-track-reference
+categories: ["Founders"]
+cover_image: cover.png
+metatags:
+  image: cover.png
+  og_title: "Hire Track Supplementary Reference"
+  og_description: "When you've reached the ceiling of self-serve and need to hire: where to find developers, the Fractional CTO bridge, interviews that catch AI theater, and how to read an SOW."
+canonical_url: "https://jetthoughts.com/blog/hire-track-supplementary-reference/"
+related_posts: false
+---
+```
+
+Body structure (5 H2 sections):
+
+```markdown
+> **Reference content.** This page is supplementary - return when retention from Module 6 is solid AND you've hit the self-serve ceiling. Until then, [Module 5: Build It Yourself](/blog/self-serve-mvp-stack-lovable-supabase-stripe-2026/) is the path.
+
+## When to hire (ceiling signals)
+
+[Pull from `vibe-coding-ceiling-signals` and `should-you-hire` chapters - the 5 signals that mean self-serve has ended]
+
+## Where to find developers in 2026
+
+[Pull strongest 1-2 sections from `who-where-hire-developer-2026-ai-augmented-offshore` - the actual landscape: solo dev, team + manager, outstaff agency, MVP shop, fractional CTO]
+
+## The Fractional CTO bridge
+
+[Pull from `fractional-cto-bridge-5-hours-week` - the cheapest format if you're early; 5 hrs/week + price range + when it works]
+
+## Interviews that catch AI theater
+
+[Pull from `hiring-interview-catches-ai-theater` - the screening questions that distinguish AI-assisted competence from AI-substituted incompetence]
+
+## Reading the SOW
+
+[Pull from `reading-sow-clause-by-clause` - the 6 clauses to redline + the "delivered" definition redline that prevents the $78K staging-URL trap]
+```
+
+Use the Write tool with the assembled content.
+
+- [ ] **Step 3: Repair inbound links from the 4 cut chapters**
+
+For each of the 4 hire-track slugs, find inbound links and redirect to the new collapsed page or to a specific anchor:
+
+```bash
+for slug in who-where-hire-developer-2026-ai-augmented-offshore fractional-cto-bridge-5-hours-week hiring-interview-catches-ai-theater reading-sow-clause-by-clause; do
+  echo "=== $slug ==="
+  rg -l "/blog/$slug/" content/ data/ 2>/dev/null | grep -v "$slug/index.md"
+done
+```
+
+Update each match. Replace specific chapter links with `/blog/hire-track-supplementary-reference/` or anchored sections.
+
+- [ ] **Step 4: Delete the 4 source chapter directories**
+
+```bash
+rm -rf content/blog/who-where-hire-developer-2026-ai-augmented-offshore/
+rm -rf content/blog/fractional-cto-bridge-5-hours-week/
+rm -rf content/blog/hiring-interview-catches-ai-theater/
+rm -rf content/blog/reading-sow-clause-by-clause/
+```
+
+- [ ] **Step 5: Verify**
+
+```bash
+bin/hugo-build
+for slug in who-where-hire-developer-2026-ai-augmented-offshore fractional-cto-bridge-5-hours-week hiring-interview-catches-ai-theater reading-sow-clause-by-clause; do
+  rg -l "/blog/$slug/" content/ data/ 2>/dev/null | grep -v "$slug/index.md"
+done
+grep -c '—' content/blog/hire-track-supplementary-reference/index.md
+```
+
+Expected: build passes, zero broken links, zero em-dashes.
+
+- [ ] **Step 6: Commit**
+
+```bash
+git add -A content/blog/
+git commit -m "content(course): collapse 4 hire-track chapters into 1 supplementary reference page"
+```
+
+---
+
+## Task 6: Demote 4 management chapters to standalone SEO pages
+
+**Files (modify each):**
+- `content/blog/engineering-org-chart-non-technical-founder/index.md`
+- `content/blog/friday-demo-rule-founder-progress/index.md`
+- `content/blog/three-questions-turn-standup-into-proof/index.md`
+- `content/blog/weekly-dev-report-template-founders/index.md`
+
+- [ ] **Step 1: For each of the 4 chapters, add a "supplementary" callout at the top**
+
+Use Edit on each file. Insert the callout between the lead paragraph and the first H2:
+
+```markdown
+> **Supplementary content.** This chapter assumes you have a hired team. If you're still on the [self-serve path](/blog/self-serve-mvp-stack-lovable-supabase-stripe-2026/), bookmark this and return when you graduate to a hired team.
+```
+
+- [ ] **Step 2: Strip the course-nav table from each chapter's bottom**
+
+Each chapter currently ends with a course-nav table (rendered by theme partial reading from YAML). To strip from these specific chapters: add `course_nav: false` to frontmatter (verify the theme partial respects this; if not, add the conditional).
+
+If theme doesn't currently support `course_nav: false`, add a one-line conditional to `themes/beaver/layouts/partials/blog/course-prev-next.html`:
+
+```html
+{{ if not (default false .Page.Params.course_nav) }}{{/* skip if course_nav: false */}}{{ return }}{{ end }}
+```
+
+Wait — current default would be true. Reverse: `{{ if eq (default true .Page.Params.course_nav) false }}{{ return }}{{ end }}`. Verify by reading the partial first.
+
+- [ ] **Step 3: Verify**
+
+```bash
+bin/hugo-build
+# Visually verify: rendered page lacks course-nav table at bottom
+curl -s http://localhost:1313/blog/engineering-org-chart-non-technical-founder/ | grep -c 'course-nav' || echo "course-nav stripped"
+```
+
+- [ ] **Step 4: Commit**
+
+```bash
+git add content/blog/ themes/beaver/layouts/partials/blog/course-prev-next.html
+git commit -m "content(course): demote 4 management chapters to supplementary SEO pages"
+```
+
+---
+
+## Task 7: Demote 3 AI-era hygiene chapters to standalone SEO pages
+
+**Files (modify each):**
+- `content/blog/agency-uses-ai-follow-up-questions/index.md`
+- `content/blog/ai-token-bill-dev-shop-pass-through-cost/index.md`
+- `content/blog/slopsquatting-ai-supply-chain-attack/index.md`
+
+- [ ] **Step 1: Add "supplementary" callout to each (same pattern as Task 6)**
+
+```markdown
+> **Supplementary content.** This chapter is relevant after you've shipped (Module 5+) and your product touches AI in production. Bookmark and return when needed.
+```
+
+- [ ] **Step 2: Set `course_nav: false` in frontmatter of each (same pattern as Task 6)**
+
+- [ ] **Step 3: Verify + Commit**
+
+```bash
+bin/hugo-build
+git add content/blog/
+git commit -m "content(course): demote 3 AI-era hygiene chapters to supplementary SEO pages"
+```
+
+---
+
+## Task 8: Delete Module 0 with 301 redirect
+
+**Files:**
+- Delete: `content/blog/course-map-self-assessment-non-technical-founder-2026/`
+- Modify: `content/blog/tech-for-non-technical-founders-2026/index.md` (frontmatter — add aliases)
+
+- [ ] **Step 1: Add Hugo alias on landing page so old Module 0 URL redirects**
+
+Edit landing page frontmatter. Add this field after `canonical_url:`:
+
+```yaml
+aliases:
+  - /blog/course-map-self-assessment-non-technical-founder-2026/
+```
+
+Hugo's `aliases` field generates a `` redirect on the landing page that catches the old URL.
+
+- [ ] **Step 2: Repair inbound links from Module 0 page**
+
+```bash
+rg -l '/blog/course-map-self-assessment-non-technical-founder-2026/' content/ data/ themes/ 2>/dev/null | grep -v 'course-map-self-assessment-non-technical-founder-2026/index.md'
+```
+
+For each match, replace with `/blog/tech-for-non-technical-founders-2026/` or remove entirely if context allows.
+
+- [ ] **Step 3: Distribute the 9 foundation concepts to chapter openings**
+
+The 9 concepts (Hypothesis, Smoke test, Clickable prototype, Mom Test, Product Brief, Build path, Ownership, Oversight rhythm, Salvage vs rebuild) currently live in Module 0's "Course foundations" section.
+
+For each concept, identify the chapter where it FIRST appears in the spine, and add the definition as a one-paragraph italic intro at the top of the chapter (after the top callout, before the first H2):
+
+| Concept | Add to chapter |
+|---|---|
+| Hypothesis | `form-your-founding-hypothesis-90-minute-sprint` |
+| Smoke test | `smoke-test-landing-page-300-dollar-validation` |
+| Clickable prototype | `clickable-prototype-validation-2-hour-lovable` (NEW — built in Task 16) |
+| Mom Test | `mom-test-ask-about-past-not-future` |
+| Product Brief | `one-page-product-brief-vibe-prd` |
+| Build path | `should-you-hire-2026-decision-tree` |
+| Ownership | `github-aws-database-ownership-checklist` |
+| Oversight rhythm | (skip — chapter demoted in Task 6; concept lives in glossary only) |
+| Salvage vs rebuild | (skip — chapter cut in Task 1; concept lives in glossary only) |
+
+For each chapter in the table, use Edit to insert the concept definition as italic intro paragraph. Pull exact wording from the existing Module 0 file before deleting it.
+
+- [ ] **Step 4: Delete the Module 0 directory**
+
+```bash
+rm -rf content/blog/course-map-self-assessment-non-technical-founder-2026/
+```
+
+- [ ] **Step 5: Verify redirect works**
+
+```bash
+bin/hugo-build
+ls public/blog/course-map-self-assessment-non-technical-founder-2026/index.html
+# Should exist (Hugo generates redirect HTML at the alias path)
+grep 'http-equiv="refresh"' public/blog/course-map-self-assessment-non-technical-founder-2026/index.html
+# Should match (redirect meta tag present)
+```
+
+- [ ] **Step 6: Commit**
+
+```bash
+git add -A content/blog/
+git commit -m "content(course): delete Module 0 with 301 redirect; distribute foundations to chapters"
+```
+
+---
+
+## Task 9: Reframe `should-you-hire-2026-decision-tree`
+
+**Files:**
+- Modify: `content/blog/should-you-hire-2026-decision-tree/index.md`
+
+**Reframe target:** Change the framing from "two equal paths (self-serve vs hire)" to "self-serve is the default; hiring is a ceiling-signal trigger."
+
+- [ ] **Step 1: Dispatch agent with reframe brief + voice gate**
+
+Agent dispatch (general-purpose, sonnet):
+
+```
+Mission: Reframe content/blog/should-you-hire-2026-decision-tree/index.md from "two equal paths" framing to "self-serve is the default; hiring is a ceiling-signal trigger."
+
+Specific changes:
+1. Opening paragraph: change from "Your Brief plus your bank balance picks one of two doors" to "Self-serve with Lovable + Supabase + Stripe is the default for a non-technical founder in 2026. Hiring is what you do when you hit a specific ceiling signal — not the first decision after the Brief."
+2. Decision tree section: keep the questions but reorder so self-serve is "yes path" and hire is "no path with these specific triggers"
+3. Closing: end with "Default: self-serve. Continue to Module 5. The ceiling-signal chapter (vibe-coding-ceiling-signals) tells you when to revisit the hire decision."
+
+CONSTRAINT: This is voice-sensitive content. Run reflexion-reflect skill before handback. Slop detector ≤25/100 per CLAUDE.md.
+
+Don't commit. Hand back the diff for review.
+```
+
+- [ ] **Step 2: Review diff for voice quality + structural correctness**
+
+Verify:
+- Opening paragraph reframed
+- Decision tree reordered (self-serve as default)
+- Closing redirects to Module 5
+- Zero em-dashes
+- Voice rubric pass
+
+- [ ] **Step 3: Commit**
+
+```bash
+git add content/blog/should-you-hire-2026-decision-tree/
+git commit -m "content(course): reframe should-you-hire as ceiling-signal trigger, not parallel path"
+```
+
+---
+
+## Task 10: Reframe `self-serve-mvp-stack-lovable-supabase-stripe-2026`
+
+**Files:**
+- Modify: `content/blog/self-serve-mvp-stack-lovable-supabase-stripe-2026/index.md`
+
+**Reframe target:** Position as the DEFAULT path for Module 5; hire-track becomes optional sidebar reference.
+
+**Required prose (per spec Critical Distinctions section):** Must include verbatim sentence: "You do NOT polish your Module 3 prototype into the MVP. The prototype was throwaway by design. The MVP is built fresh with production rigor."
+
+- [ ] **Step 1: Dispatch agent with reframe brief**
+
+```
+Mission: Reframe content/blog/self-serve-mvp-stack-lovable-supabase-stripe-2026/index.md as the DEFAULT Module 5 path.
+
+Specific changes:
+1. Opening: lead with "If you completed Modules 1-4, your default Module 5 path is to build it yourself with Lovable + Supabase + Stripe. Hiring is a ceiling-signal trigger covered in the supplementary reference."
+2. Add explicit M3-vs-M5 distinction section: "You do NOT polish your Module 3 prototype into the MVP. The prototype was throwaway by design. The MVP is built fresh with production rigor — real auth, real Stripe, real domain, real user data."
+3. Add a "When this path ends" closing section linking to vibe-coding-ceiling-signals (proactive monitoring) and hire-track-supplementary-reference (when ceiling hits)
+
+CONSTRAINT: Voice-sensitive. Run reflexion-reflect. Slop ≤25/100. Verify the verbatim quote in #2 is present.
+
+Don't commit. Hand back diff.
+```
+
+- [ ] **Step 2: Verify required prose present**
+
+```bash
+grep "You do NOT polish your Module 3 prototype" content/blog/self-serve-mvp-stack-lovable-supabase-stripe-2026/index.md
+```
+
+Expected: match found.
+
+- [ ] **Step 3: Commit**
+
+```bash
+git add content/blog/self-serve-mvp-stack-lovable-supabase-stripe-2026/
+git commit -m "content(course): reframe self-serve-mvp-stack as default Module 5 path"
+```
+
+---
+
+## Task 11: Reframe `vibe-coding-ceiling-signals`
+
+**Files:**
+- Modify: `content/blog/vibe-coding-ceiling-signals/index.md`
+
+**Reframe target:** From "rescue diagnostic" to "proactive monthly monitoring habit starting at Week 2 of building."
+
+- [ ] **Step 1: Dispatch agent with reframe brief**
+
+```
+Mission: Reframe content/blog/vibe-coding-ceiling-signals/index.md from rescue framing to proactive monitoring.
+
+Specific changes:
+1. Remove all language implying the build is already broken (e.g., "your codebase is in trouble", "diagnose what went wrong")
+2. Reframe as a habit: "Starting at Week 2 of your build, run this 5-signal check monthly. Each signal that fires earlier saves weeks later."
+3. Reorder signals so the EARLIEST ones (Week 2-detectable) come first
+4. Add a closing section: "If 2+ signals fire in one check, the self-serve path is ending. See [hire track reference]."
+
+CONSTRAINT: Voice-sensitive. Run reflexion-reflect. Slop ≤25/100. No rescue language ("broken", "trouble", "wrong" in present tense referring to the reader's build).
+
+Don't commit. Hand back diff.
+```
+
+- [ ] **Step 2: Verify rescue language removed**
+
+```bash
+rg -i 'rescue|broken|already wrong|trouble' content/blog/vibe-coding-ceiling-signals/index.md
+```
+
+Expected: zero matches in body prose (frontmatter SEO terms can stay if needed).
+
+- [ ] **Step 3: Commit**
+
+```bash
+git add content/blog/vibe-coding-ceiling-signals/
+git commit -m "content(course): reframe vibe-coding-ceiling-signals as proactive monitoring"
+```
+
+---
+
+## Task 12: Reframe `smoke-test-landing-page-300-dollar-validation`
+
+**Files:**
+- Modify: `content/blog/smoke-test-landing-page-300-dollar-validation/index.md`
+
+**Reframe target:** Add Stripe price-button section (Gap 1 from research).
+
+- [ ] **Step 1: Dispatch agent with reframe brief**
+
+```
+Mission: Add a "Price-button on the landing page" section to content/blog/smoke-test-landing-page-300-dollar-validation/index.md.
+
+Specific changes:
+1. After the existing "What goes on the landing page" section, add new H2: "## Add a real price button"
+2. Section content: explain why a Stripe payment link (or "Reserve for $X" form) reveals payment intent in a way a waitlist does not. Cover: setting up a Stripe Payment Link in 5 minutes (no account integration needed), interpreting click vs payment vs form-fill rates, the ≥5% click-to-payment-intent threshold as a go/iterate/kill signal.
+3. Cross-reference the new dedicated chapter: "For deep dive on price hypothesis, see [Price Hypothesis on the Smoke-Test Page] (will be /blog/price-hypothesis-on-smoke-test-page/)."
+
+CONSTRAINT: Voice-sensitive. Run reflexion-reflect. Slop ≤25/100.
+
+Don't commit. Hand back diff.
+```
+
+- [ ] **Step 2: Commit**
+
+```bash
+git add content/blog/smoke-test-landing-page-300-dollar-validation/
+git commit -m "content(course): add price-button section to smoke-test chapter (Gap 1)"
+```
+
+---
+
+## Task 13: Reframe `mom-test-ask-about-past-not-future`
+
+**Files:**
+- Modify: `content/blog/mom-test-ask-about-past-not-future/index.md` (already touched by Task 4 fold)
+
+Note: this task COMPLETES the reframing started in Task 4. Task 4 added the synthesis section; this task ensures the chapter opening properly intros the AI persona pre-validation chapter.
+
+- [ ] **Step 1: Add a forward reference to AI persona pre-validation**
+
+Edit `content/blog/mom-test-ask-about-past-not-future/index.md`. After the lead paragraph, add: "Before you book real interviews, sharpen your question list with [AI personas](/blog/ai-persona-pre-validation-mom-test-prep/). Real interviews are irreplaceable for listening — but Claude personas catch weak questions before you waste a real interview slot."
+
+- [ ] **Step 2: Commit**
+
+```bash
+git add content/blog/mom-test-ask-about-past-not-future/
+git commit -m "content(course): add forward reference to AI persona pre-validation"
+```
+
+---
+
+## Task 14: Reframe `find-10-people-with-problem-outreach-2026`
+
+**Files:**
+- Modify: `content/blog/find-10-people-with-problem-outreach-2026/index.md`
+
+**Reframe target:** Make the recruitment-vs-sales distinction explicit (per spec Critical Distinctions section).
+
+**Required prose:** "This is interview recruitment, not sales. You are asking for time and insight, not money."
+
+- [ ] **Step 1: Dispatch agent with reframe brief**
+
+```
+Mission: Reframe content/blog/find-10-people-with-problem-outreach-2026/index.md to make the recruitment-vs-sales distinction explicit.
+
+Specific changes:
+1. Opening: insert verbatim "This is interview recruitment, not sales. You are asking for time and insight, not money. Different message template, different channels emphasized, different reciprocity. Do not use the Module 6 cold email script here — it will scare interview subjects who don't yet know you have a product."
+2. Verify the existing channel coverage includes 2026 channels: Reddit DMs, Twitter/X DMs, LinkedIn, UserInterviews.com / Respondent.io paid panels ($25-$100 incentive), community Slack/Discord, personal network referrals, cold email to public lists. Add anything missing.
+3. Add the volume target: "30-50 outreach to land 10 interviews. Reply rate ≥20%; show-rate ≥50% of replies."
+
+CONSTRAINT: Voice-sensitive. Run reflexion-reflect. Slop ≤25/100. Verify required verbatim quote present.
+
+Don't commit. Hand back diff.
+```
+
+- [ ] **Step 2: Verify required prose present**
+
+```bash
+grep "This is interview recruitment, not sales" content/blog/find-10-people-with-problem-outreach-2026/index.md
+```
+
+Expected: match found.
+
+- [ ] **Step 3: Commit**
+
+```bash
+git add content/blog/find-10-people-with-problem-outreach-2026/
+git commit -m "content(course): reframe find-10-people with recruitment-vs-sales distinction"
+```
+
+---
+
+## Task 15: Reframe `outbound-without-sales-team`
+
+**Files:**
+- Modify: `content/blog/outbound-without-sales-team/index.md`
+
+**Reframe target:** Make the sales-vs-recruitment distinction explicit.
+
+**Required prose:** "This is sales outbound, not interview recruitment. You are asking for money, not time."
+
+- [ ] **Step 1: Dispatch agent with reframe brief**
+
+```
+Mission: Reframe content/blog/outbound-without-sales-team/index.md to make the sales-vs-recruitment distinction explicit.
+
+Specific changes:
+1. Opening: insert verbatim "This is sales outbound, not interview recruitment. You are asking for money, not time. The 10 people you interviewed in Module 3 may or may not become customers — outreach to them goes through this chapter's sales sequence, not the Module 3 recruitment script."
+2. Verify the existing volume target: "100-200 outreach to land 5-10 customers. Reply rate ≥5%; meeting-to-paid ≥20% of meetings."
+
+CONSTRAINT: Voice-sensitive. Run reflexion-reflect. Slop ≤25/100. Verify required verbatim quote present.
+
+Don't commit. Hand back diff.
+```
+
+- [ ] **Step 2: Verify + Commit**
+
+```bash
+grep "This is sales outbound, not interview recruitment" content/blog/outbound-without-sales-team/index.md
+git add content/blog/outbound-without-sales-team/
+git commit -m "content(course): reframe outbound chapter with sales-vs-recruitment distinction"
+```
+
+---
+
+## Task 16: Write NEW chapter — Price Hypothesis on Smoke-Test Page
+
+**Files:**
+- Create: `content/blog/price-hypothesis-on-smoke-test-page/index.md`
+
+**Brief (full version in 20.08 audit, summary here):**
+- Module 2 chapter
+- Outcome: founder publishes Carrd/Framer page with real Stripe price button
+- Signal: ≥5% click-to-payment-intent
+- Required artifacts: Smoke-Test Page Brief copy template + Stripe setup checklist
+
+- [ ] **Step 1: Dispatch agent with full chapter brief**
+
+```
+Mission: Write content/blog/price-hypothesis-on-smoke-test-page/index.md as a Module 2 chapter teaching newbie non-technical founders to add a real price button to their smoke-test landing page.
+
+Outcome: founder publishes a Carrd or Framer page with a Stripe Payment Link button live, and measures click-to-payment-intent vs form-fills as the demand signal.
+
+Required structure:
+- Frontmatter: title "2.2 · Price Your Hypothesis on the Smoke-Test Page", slug price-hypothesis-on-smoke-test-page, standard JT frontmatter
+- Top callout: "Module 2 · Step 2 of 2 · Tech for Non-Technical Founders 2026"
+- Lead paragraph: why a waitlist signup is a worse signal than a payment-intent click
+- H2: Why price IS the hypothesis (not a launch tactic)
+- H2: Setting up a Stripe Payment Link in 5 minutes (no account integration, no code)
+- H2: What to measure: clicks vs form-fills vs actual payment-intent
+- H2: The ≥5% threshold and what to do at each level (kill, iterate, advance)
+- H2: Going further (when to revisit pricing post-launch)
+- Required artifacts: Smoke-Test Page Brief copy template (inline checklist) + Stripe setup steps (numbered list)
+
+CONSTRAINTS:
+- Voice-sensitive content. Run reflexion-reflect before handback. Slop ≤25/100.
+- Use - not — for all dashes.
+- Newbie ICP: assume reader has not used Stripe before; explain "Payment Link" feature plainly.
+- AI-augmented method: include a Claude prompt for generating the price-button copy variants.
+- No rescue framing.
+- 1500-2500 words (length is byproduct of effective delivery, not a target).
+
+Don't commit. Hand back the file content for review.
+```
+
+- [ ] **Step 2: Review chapter for voice + structure**
+
+Verify:
+- All required H2 sections present
+- Stripe Payment Link instructions are concrete (5-minute setup achievable)
+- ≥5% threshold present and explained
+- Voice rubric pass
+- Zero em-dashes
+
+- [ ] **Step 3: Generate cover image** (defer or use placeholder per existing pipeline)
+
+Use existing `.stitch/design.md` cover-image pipeline. For Phase 1 launch, a placeholder cover is acceptable; cover regeneration can be a Phase 2 task.
+
+- [ ] **Step 4: Commit**
+
+```bash
+git add content/blog/price-hypothesis-on-smoke-test-page/
+git commit -m "feat(course): NEW Module 2.2 chapter - price hypothesis on smoke-test page"
+```
+
+---
+
+## Task 17: Write NEW chapter — AI Persona Pre-Validation (Mom Test Prep)
+
+**Files:**
+- Create: `content/blog/ai-persona-pre-validation-mom-test-prep/index.md`
+
+**Brief:**
+- Module 3 chapter
+- Outcome: founder runs 5-prompt Claude session simulating ICP before booking real interviews
+- Signal: top 3 objections identified BEFORE real interviews
+- Positioning: AI-as-rehearsal (not replacement)
+- Required artifacts: AI Prompt Pack + Objection Tracker template
+
+- [ ] **Step 1: Dispatch agent with full chapter brief**
+
+```
+Mission: Write content/blog/ai-persona-pre-validation-mom-test-prep/index.md as a Module 3 chapter teaching newbie non-technical founders to use Claude personas to sharpen Mom Test interview questions BEFORE booking real interviews.
+
+Outcome: founder has 3 sharpened interview questions per persona, with the top 3 objections to test (not discover) in the real Mom Test interviews.
+
+POSITIONING (BLOCKING — must be explicit and threaded throughout):
+- AI personas are REHEARSAL, not replacement
+- Real interviews stay irreplaceable
+- AI catches weak questions; real customers catch weak hypotheses
+
+Required structure:
+- Frontmatter: title "3.1 · AI Persona Pre-Validation - Sharpen the Mom Test Before You Book Real Interviews", slug ai-persona-pre-validation-mom-test-prep
+- Top callout: "Module 3 · Step 1 of 4 · Tech for Non-Technical Founders 2026"
+- Lead: the cost of a bad real interview ($25-$100 incentive + 40 min + 1 of 10 slots burned) vs the cost of a bad AI rehearsal (free, 5 minutes, no slot wasted)
+- H2: Why this is rehearsal, not replacement (THE ANTI-AI-REPLACEMENT SECTION — Reddit anti-AI reflex pre-empt)
+- H2: Build 3 ICP personas in Claude in 5 minutes
+- H2: Run the rehearsal session (the 5-prompt sequence)
+- H2: What to keep, what to throw out (interpreting AI persona signal)
+- H2: Going further (using AI personas for hypothesis-revision, not just question-revision)
+- Required artifacts: AI Prompt Pack (5 prompts inline) + Objection Tracker template
+
+CONSTRAINTS:
+- Voice-sensitive. Reflexion-reflect before handback. Slop ≤25/100.
+- Newbie ICP. Assume Claude account but no advanced prompt experience.
+- Explicit anti-AI-replacement framing (this is the Reddit downvote risk).
+- Use - not —.
+- 1500-2500 words.
+
+Don't commit. Hand back content for review.
+```
+
+- [ ] **Step 2: Verify positioning is explicit + threaded**
+
+```bash
+rg -c 'rehearsal|not replacement|irreplaceable' content/blog/ai-persona-pre-validation-mom-test-prep/index.md
+```
+
+Expected: ≥4 matches (positioning threaded throughout, not buried in one paragraph).
+
+- [ ] **Step 3: Commit**
+
+```bash
+git add content/blog/ai-persona-pre-validation-mom-test-prep/
+git commit -m "feat(course): NEW Module 3.1 chapter - AI persona pre-validation (rehearsal not replacement)"
+```
+
+---
+
+## Task 18: Write NEW chapter — Clickable Prototype Validation
+
+**Files:**
+- Create: `content/blog/clickable-prototype-validation-2-hour-lovable/index.md`
+
+**Brief:**
+- Module 3 chapter
+- Outcome: founder builds 3-screen Lovable prototype, shows it to 5 of the 10 interviewees
+- Signal: pass/fail per session — does user demonstrate the core flow without coaching?
+- Required artifacts: Prototype Session Script + Lovable Prompt Template
+- Required prose: "This prototype is throwaway. You will discard it after validation. Do not invest in production polish, real auth, or payment integration. The MVP in Module 5 is built differently."
+
+- [ ] **Step 1: Dispatch agent with full chapter brief**
+
+```
+Mission: Write content/blog/clickable-prototype-validation-2-hour-lovable/index.md as a Module 3 chapter teaching newbie non-technical founders to build a 2-hour Lovable clickable prototype as the third validation pillar.
+
+Outcome: founder has a 3-screen Lovable prototype shown to 5 of the 10 interview subjects with pass/fail observation logged.
+
+REQUIRED PROSE (BLOCKING — must appear verbatim near the top): "This prototype is throwaway. You will discard it after validation. Do not invest in production polish, real auth, or payment integration. The MVP in Module 5 is built differently."
+
+Required structure:
+- Frontmatter: title "3.4 · Build a Clickable Prototype in an Afternoon", slug clickable-prototype-validation-2-hour-lovable
+- Top callout: "Module 3 · Step 4 of 4"
+- Lead: why a clickable prototype catches what landing pages and interviews miss (solution-shape signal)
+- H2: This is throwaway (the verbatim required prose section)
+- H2: Build 3 screens in 2 hours with Lovable (concrete walkthrough)
+- H2: Run a silent-observation session with 5 interviewees
+- H2: Pass/fail scoring (the gate signal)
+- H2: What to do with results (revise hypothesis, advance to Module 4, or kill)
+
+Required artifacts: Prototype Session Script (silent-observation facilitation) + Lovable Prompt Template (the prompt that gets you the 3 screens)
+
+CONSTRAINTS:
+- Voice-sensitive. Reflexion-reflect. Slop ≤25/100.
+- Newbie ICP. Assume Lovable account; explain prompt-to-prototype flow plainly.
+- The "throwaway" framing must be threaded, not just in one section.
+- Use - not —.
+- 1500-2500 words.
+
+Don't commit. Hand back content.
+```
+
+- [ ] **Step 2: Verify required prose**
+
+```bash
+grep "This prototype is throwaway" content/blog/clickable-prototype-validation-2-hour-lovable/index.md
+```
+
+Expected: match.
+
+- [ ] **Step 3: Commit**
+
+```bash
+git add content/blog/clickable-prototype-validation-2-hour-lovable/
+git commit -m "feat(course): NEW Module 3.4 chapter - clickable prototype validation (throwaway by design)"
+```
+
+---
+
+## Task 19: Write NEW chapter — Channel Selection Before Outbound
+
+**Files:**
+- Create: `content/blog/channel-selection-before-outbound/index.md`
+
+**Brief:**
+- Module 6 chapter
+- Outcome: founder picks ONE channel from interview evidence before any outreach
+- Signal: 4-week commitment to one channel (not channel-hopping)
+- Required artifacts: Channel Selection Worksheet with interview-evidence scoring
+
+- [ ] **Step 1: Dispatch agent with full chapter brief**
+
+```
+Mission: Write content/blog/channel-selection-before-outbound/index.md as a Module 6 chapter teaching newbie non-technical founders to pick ONE acquisition channel before sending the first outbound message.
+
+Outcome: founder has a written channel decision (one channel for first 4 weeks of outbound) backed by interview evidence (which channel did the 10 Module 3 subjects say they'd discover this product through?).
+
+Required structure:
+- Frontmatter: title "6.1 · Choose Your Channel Before You Send One Message", slug channel-selection-before-outbound
+- Top callout: "Module 6 · Step 1 of 5"
+- Lead: why channel-hopping in week 2 is the most common newbie mistake
+- H2: The 4-week commitment rule (why one channel for 4 weeks beats 4 channels for 1 week each)
+- H2: How to pick from interview evidence (Module 3 interviewees told you which channel — listen)
+- H2: Channel-fit scoring (price point + buyer type + founder time budget = channel)
+- H2: The 4 channels for newbie B2B and B2C (with criteria for each)
+- H2: AI-augmented channel research (Claude prompt to map ICP segment to channel fit)
+
+Required artifact: Channel Selection Worksheet with interview-evidence scoring rubric (inline)
+
+CONSTRAINTS:
+- Voice-sensitive. Reflexion-reflect. Slop ≤25/100.
+- Newbie ICP. Plain language for "channel" (sales channel = how customers find you).
+- Cross-reference outbound chapter (this is the decision; outbound is the tactic).
+- Use - not —.
+- 1500-2500 words.
+
+Don't commit. Hand back content.
+```
+
+- [ ] **Step 2: Commit**
+
+```bash
+git add content/blog/channel-selection-before-outbound/
+git commit -m "feat(course): NEW Module 6.1 chapter - channel selection before outbound"
+```
+
+---
+
+## Task 20: Rebuild `data/course_sequence.yaml` from new spine
+
+**Files:**
+- Modify: `data/course_sequence.yaml`
+
+- [ ] **Step 1: Write the new YAML**
+
+Replace the entire `data/course_sequence.yaml` content with the new 6-module sequence (no Module 0; new chapters in their slots; cuts removed; fold removed; demoted hire-track collapsed to one entry; demoted management + AI-era removed from sequence).
+
+The new sequence (verbatim slugs from the spec):
+
+```yaml
+# Tech for Non-Technical Founders 2026 - chapter sequence (Phase 1 spine)
+# Each entry: slug, title (short for nav), module label
+# Order = reading sequence on the landing page (Module 1 -> end of Module 6).
+# Used by the prev/next partial on chapter pages.
+#
+# Note: floating glossary - "Five Tech Words to Stop Nodding At" (slug five-tech-words-stop-nodding-at)
+# is reference content, accessible from every chapter, not in the linear reading order.
+#
+# Continuation chapters (customers-leaving-churn-triage-not-acquisition,
+# pivot-or-persevere-decision-framework) and supplementary references
+# (hire-track-supplementary-reference, demoted management chapters,
+# demoted AI-era chapters) are linked from Module 6 "Going further" callout
+# but NOT in the linear sequence.
+
+sequence:
+  - slug: form-your-founding-hypothesis-90-minute-sprint
+    title: "1.1 · Form Your Founding Hypothesis"
+    module: "Module 1.1"
+
+  - slug: smoke-test-landing-page-300-dollar-validation
+    title: "2.1 · Smoke-Test the Hypothesis"
+    module: "Module 2.1"
+
+  - slug: price-hypothesis-on-smoke-test-page
+    title: "2.2 · Price Your Hypothesis on the Smoke-Test Page"
+    module: "Module 2.2"
+
+  - slug: ai-persona-pre-validation-mom-test-prep
+    title: "3.1 · AI Persona Pre-Validation"
+    module: "Module 3.1"
+
+  - slug: find-10-people-with-problem-outreach-2026
+    title: "3.2 · Find 10 People With the Problem"
+    module: "Module 3.2"
+
+  - slug: mom-test-ask-about-past-not-future
+    title: "3.3 · The Mom Test (with Synthesis)"
+    module: "Module 3.3"
+
+  - slug: clickable-prototype-validation-2-hour-lovable
+    title: "3.4 · Build a Clickable Prototype in an Afternoon"
+    module: "Module 3.4"
+
+  - slug: one-page-product-brief-vibe-prd
+    title: "4.1 · The One-Page Product Brief"
+    module: "Module 4.1"
+
+  - slug: stop-specifying-features-start-outcomes
+    title: "4.2 · Stop Specifying Features, Start Outcomes"
+    module: "Module 4.2"
+
+  - slug: should-you-hire-2026-decision-tree
+    title: "5.1 · Build It Yourself or Hire (the Default)"
+    module: "Module 5.1"
+
+  - slug: github-aws-database-ownership-checklist
+    title: "5.2 · Day-1 Ownership Audit"
+    module: "Module 5.2"
+
+  - slug: self-serve-mvp-stack-lovable-supabase-stripe-2026
+    title: "5.3 · Build It Yourself: Lovable + Supabase + Stripe"
+    module: "Module 5.3"
+
+  - slug: vibe-coding-ceiling-signals
+    title: "5.4 · Proactive Ceiling Signals (Monthly Check)"
+    module: "Module 5.4"
+
+  - slug: must-have-segment-pmf-test
+    title: "6.0 · The Must-Have Segment Test"
+    module: "Module 6.0"
+
+  - slug: channel-selection-before-outbound
+    title: "6.1 · Choose Your Channel Before You Send One Message"
+    module: "Module 6.1"
+
+  - slug: first-ten-customers-personal-network
+    title: "6.2 · The First Ten From Your Network"
+    module: "Module 6.2"
+
+  - slug: paid-pilot-charge-before-ship
+    title: "6.3 · Charge Before You Ship"
+    module: "Module 6.3"
+
+  - slug: outbound-without-sales-team
+    title: "6.4 · Going Outbound Without a Sales Team"
+    module: "Module 6.4"
+```
+
+Use Write tool with this exact content.
+
+- [ ] **Step 2: Verify Hugo build passes**
+
+```bash
+bin/hugo-build
+```
+
+Expected: build passes, no orphan slugs, no missing entries.
+
+- [ ] **Step 3: Verify chapter prev/next nav works**
+
+```bash
+curl -s http://localhost:1313/blog/form-your-founding-hypothesis-90-minute-sprint/ | grep -A2 'course-prev-next'
+```
+
+Expected: prev = none (Module 1.1), next = smoke-test-landing-page.
+
+- [ ] **Step 4: Commit**
+
+```bash
+git add data/course_sequence.yaml
+git commit -m "data(course): rebuild course_sequence.yaml from new 6-module Phase 1 spine"
+```
+
+---
+
+## Task 21: Rebuild landing page Module index from new spine
+
+**Files:**
+- Modify: `content/blog/tech-for-non-technical-founders-2026/index.md`
+
+- [ ] **Step 1: Replace the entire Module index section**
+
+Find the existing `## Module index` section and replace with the 6-module structure pulled from the new YAML. Each module entry has:
+- H3 with `Module N - `
+- *Output: ...* italic line
+- *Start here if...* italic line
+- Chapter links
+
+Use the spec (20.09 file, "Architecture: 6-module core spine" section) as source of truth for outcomes + start-here-if conditions per module.
+
+After Module 6, add the "Going further" callout:
+
+```markdown
+## Going further (after first paying customer)
+
+These continuation chapters apply once you've passed the Module 6 gate (one paying customer):
+
+- **If your customers are leaving:** [Churn Triage Before Acquisition](/blog/customers-leaving-churn-triage-not-acquisition/)
+- **If a key metric has stalled for 2+ months:** [Pivot or Persevere](/blog/pivot-or-persevere-decision-framework/)
+- **If you've hit the self-serve ceiling and need to hire:** [Hire Track Supplementary Reference](/blog/hire-track-supplementary-reference/)
+- **If your product touches AI in production:** [AI Token Bill](/blog/ai-token-bill-dev-shop-pass-through-cost/) | [Agency AI Questions](/blog/agency-uses-ai-follow-up-questions/) | [Slopsquatting](/blog/slopsquatting-ai-supply-chain-attack/)
+```
+
+- [ ] **Step 2: Update other landing page sections that reference old structure**
+
+- "Take this course if" — verify still accurate
+- "What you walk away with" — already updated to single Founder OS list; reorder items 1-10 to match new module sequence
+- Templates table — remove rows for cut chapters (validated-problem-statement-template, etc.); keep rows for chapters still in scope
+
+- [ ] **Step 3: Verify zero broken links**
+
+```bash
+grep -oE '/blog/[a-z0-9-]+/' content/blog/tech-for-non-technical-founders-2026/index.md | sort -u | while read url; do
+  slug=$(echo "$url" | sed 's|/blog/||;s|/||')
+  test -d "content/blog/$slug" || echo "BROKEN: $url"
+done
+```
+
+Expected: zero BROKEN output.
+
+- [ ] **Step 4: Commit**
+
+```bash
+git add content/blog/tech-for-non-technical-founders-2026/
+git commit -m "content(landing): rebuild Module index from Phase 1 spine + Going further callout"
+```
+
+---
+
+## Task 22: Add "Going further" callout to end of Module 6 last chapter
+
+**Files:**
+- Modify: `content/blog/outbound-without-sales-team/index.md` (last chapter in Module 6 sequence)
+
+- [ ] **Step 1: Append the callout after the existing closing**
+
+Insert before the Further Reading section (or append at end if no Further Reading):
+
+```markdown
+## Going further (after your first paying customer)
+
+You've completed the core 6-module course. Continuation chapters apply once you've signed your first paid pilot:
+
+- **Customers leaving in week 2-4?** → [Churn Triage Before Acquisition](/blog/customers-leaving-churn-triage-not-acquisition/) before you spend on more outbound
+- **Key metric flat for 2+ months?** → [Pivot or Persevere](/blog/pivot-or-persevere-decision-framework/) decision framework
+- **Hit the self-serve ceiling?** → [Hire Track Supplementary Reference](/blog/hire-track-supplementary-reference/) for when to hire and what to look for
+- **Product touches AI?** → [AI Token Bill](/blog/ai-token-bill-dev-shop-pass-through-cost/), [Agency AI Questions](/blog/agency-uses-ai-follow-up-questions/), [Slopsquatting](/blog/slopsquatting-ai-supply-chain-attack/) — supplementary references for AI-era hygiene
+
+The course graduates here. Return to the [course landing page](/blog/tech-for-non-technical-founders-2026/) when you're ready to retake it for a new project.
+```
+
+- [ ] **Step 2: Commit**
+
+```bash
+git add content/blog/outbound-without-sales-team/
+git commit -m "content(course): add Going further callout at end of Module 6"
+```
+
+---
+
+## Task 23: Final verification gates
+
+- [ ] **Step 1: Hugo build passes**
+
+```bash
+bin/hugo-build
+```
+
+Expected: clean build, no warnings.
+
+- [ ] **Step 2: Zero em-dashes in all changed files**
+
+```bash
+git diff --name-only HEAD~22 HEAD | grep '\.md$' | xargs grep -l '—' 2>/dev/null
+```
+
+Expected: zero output.
+
+- [ ] **Step 3: Zero broken inbound links across course content**
+
+```bash
+# Build set of all course slugs from new YAML
+slugs=$(grep -E '^\s+slug: ' data/course_sequence.yaml | sed 's/.*slug: //')
+# Plus floating + supplementary slugs
+extra="five-tech-words-stop-nodding-at hire-track-supplementary-reference customers-leaving-churn-triage-not-acquisition pivot-or-persevere-decision-framework agency-uses-ai-follow-up-questions ai-token-bill-dev-shop-pass-through-cost slopsquatting-ai-supply-chain-attack engineering-org-chart-non-technical-founder friday-demo-rule-founder-progress three-questions-turn-standup-into-proof weekly-dev-report-template-founders"
+
+# Find every /blog/X/ link and verify X exists
+grep -rohE '/blog/[a-z0-9-]+/' content/blog/ | sort -u | while read url; do
+  slug=$(echo "$url" | sed 's|/blog/||;s|/||')
+  test -d "content/blog/$slug" || echo "BROKEN: $url"
+done
+```
+
+Expected: zero BROKEN output.
+
+- [ ] **Step 4: Visual regression**
+
+```bash
+bin/test
+bin/dtest  # Linux/Docker test (per CLAUDE.md mandatory gate)
+```
+
+Expected: visual regression passes for landing + 4 new chapters + 7 reframed chapters. Update baselines if changes are intentional.
+
+- [ ] **Step 5: Voice rubric spot-check on 3 random changed chapters**
+
+```bash
+# Pick 3 changed chapters at random
+git diff --name-only HEAD~22 HEAD | grep 'content/blog/.*index.md' | shuf -n 3
+```
+
+For each, run reflexion-reflect manually or via skill. Spot-check slop score ≤25/100.
+
+- [ ] **Step 6: Final commit (if anything was caught + fixed in steps 1-5)**
+
+```bash
+git add -A
+git commit -m "content(course): final verification fixes for Phase 1 spine launch"
+```
+
+---
+
+## Definition of done (Phase 1 complete)
+
+- ☐ All 23 tasks marked complete with checkbox
+- ☐ 6-module spine live on landing page
+- ☐ 4 new chapters published (price, AI-persona, prototype, channel)
+- ☐ 7 reframed chapters republished with required prose statements verified
+- ☐ 5 cuts removed; 1 fold merged; 10 demotions applied
+- ☐ Module 0 deleted with working redirect (verified via Hugo `aliases:`)
+- ☐ data/course_sequence.yaml reflects new 6-module spine
+- ☐ All chapter pages pass `bin/hugo-build` and `bin/test`/`bin/dtest`
+- ☐ Voice rubric pass on all new + reframed content
+- ☐ Zero broken inbound links across course content
+- ☐ "Going further" callout at end of Module 6 + on landing page
+
+---
+
+## Out of scope for Phase 1 (deferred)
+
+Per spec section "Out of scope for Phase 1":
+- Formal continuation modules 7-8
+- Advanced modules 9-10 for repeatable GTM
+- 6A/6B slug renumbering (defer)
+- Topic ID convention overhaul beyond core 6 modules
+- Course completion analytics infrastructure (manual feedback survey only for v1)
+- Email gate / signup flow
+
+---
+
+## Open items (none blocking — proceed once plan approved)
+
+- Cover image generation for 4 new chapters (use Stitch pipeline post-launch if needed)
+- Final naming for the 4 new chapters' titles (slugs locked; titles refinable during chapter write)
+- Lead-magnet artifacts referenced in chapters (Smoke-Test Page Brief, AI Prompt Pack, Prototype Session Script, Channel Selection Worksheet) — drafts can ship inline as markdown checklists; downloadable versions are Phase 2
+
+---
+
+## Execution dependency graph
+
+```
+Task 1 (cuts) ──┐
+                ├──► Task 2 (link repair) ──► Task 3 (slug fix) ──► Task 4 (fold)
+Task 5 (collapse hire-track) ──► Task 6 (demote mgmt) ──► Task 7 (demote AI-era) ──► Task 8 (Module 0 delete)
+                                                                                          │
+                                              Tasks 9-15 (7 reframes, parallel-safe) ◄────┤
+                                              Tasks 16-19 (4 new chapters, parallel-safe) ◄┤
+                                                                                          │
+                                              Task 20 (YAML rebuild) ◄────────────────────┘
+                                              Task 21 (landing rebuild)
+                                              Task 22 (Going further callout)
+                                              Task 23 (verification gates)
+```
+
+Tasks 9-15 can run in parallel as separate agent dispatches (each is a single-chapter reframe).
+Tasks 16-19 can run in parallel as separate agent dispatches (each is a single new-chapter write).
+Tasks 20-22 must run sequentially (YAML → landing → callout) and AFTER 9-19 complete.
+Task 23 is the final gate.
+
+Estimated total dispatches: ~15-20 (some can be batched).
diff --git a/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/_ARCHIVED_SPRINT-RUNBOOK.md b/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/_ARCHIVED_SPRINT-RUNBOOK.md
new file mode 100644
index 000000000..76c204eba
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/_ARCHIVED_SPRINT-RUNBOOK.md
@@ -0,0 +1,328 @@
+# ⚠️ ARCHIVED — DO NOT EXECUTE
+
+**Archived:** 2026-06-10
+**Why:** This Sprint 1 runbook was written 2026-05-12 for an 8-module blog-post course structure at `content/blog/`. The course has since moved to `content/course/tech-for-non-technical-founders-2026/` with a 5-module spine and is mid-migration to v2 micro-lessons (30.03 spec).
+**Replaced by:** `TASK-TRACKER.md` "Course Migration Schedule" and the cold-agent route in `PROJECT-INDEX.md`. The canonical writer brief template in this file references `content/blog/` paths, archived strategy files, and a completely different course structure. Executing these runbooks would damage the current course.
+**Historical reference only.** Read `30-39-architecture-design/30.03-course-format-requirements-for-creators.md` for the current lesson format spec.
+
+---
+
+# Sprint Runbook - 2605 Course Execution (ARCHIVED)
+
+**Purpose**: Self-contained orchestrator runbook. A separate Claude Code session opens this file, picks the next task, copies the dispatch brief into an Agent call, runs the review checklist on return.
+
+**Last Updated**: 2026-05-12 (Sprint 1 ready to dispatch)
+**Owner**: any session with write access to `content/blog/` and the project tree
+
+---
+
+## 🚀 How to use this runbook
+
+1. Read this file top to bottom on first session entry.
+2. Read `../TASK-TRACKER.md` for current sprint scope.
+3. Identify the next un-spawned task in the active sprint.
+4. Copy the matching dispatch brief (Section "Sprint 1 task briefs" below) into a new Agent call. Use `subagent_type: general-purpose`.
+5. When the agent returns, run the **Review checklist** (Section "Post-return review").
+6. If review passes: mark task complete in TASK-TRACKER, queue next task.
+7. If review fails: surface to user with specific issue list. Do not dispatch next task.
+
+**WIP=1**: only one writer agent at a time per sprint. Sequential dispatches.
+
+---
+
+## 📜 Canonical writer brief template
+
+Every writer agent in the 2605 curriculum receives a brief structured like this. Section S1.1 through S1.3 below fill in the task-specific placeholders.
+
+```
+You are drafting <> for JetThoughts curriculum project 2605: Tech for Non-Technical Founders 2026. Slug: <>. Module · Step: <>. Publish target: <>.
+
+This is a real blog post shipping to production at content/blog/<>/index.md, plus a companion artifact at docs/projects/2605-tech-for-non-technical-founders/50-59-execution/lead-magnets/<>.md. Run the standard JT blog pipeline. Do not edit anything outside the blog post directory + the artifact file.
+
+# CONTEXT - READ THESE FIRST (mandatory, in this order)
+
+1. /Users/pftg/dev/jetthoughts.github.io/docs/workflows/blog-pipeline.md
+2. /Users/pftg/dev/jetthoughts.github.io/docs/90-99-content-strategy/strategy-analysis/90.10-icp-primary-website-target.md
+3. /Users/pftg/dev/jetthoughts.github.io/docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md
+4. /Users/pftg/dev/jetthoughts.github.io/docs/projects/2605-tech-for-non-technical-founders/GOAL-AT-A-GLANCE.md
+5. /Users/pftg/dev/jetthoughts.github.io/docs/projects/2605-tech-for-non-technical-founders/PROJECT-INDEX.md (integration rules 1-10)
+6. /Users/pftg/dev/jetthoughts.github.io/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.01-course-modules.md (your module's input/output/checkpoint)
+7. /Users/pftg/dev/jetthoughts.github.io/docs/projects/2605-tech-for-non-technical-founders/20-29-strategy/20.07-content-plan-tnt-founders-2026.md (your post's row in the 26-post map)
+8. /Users/pftg/dev/jetthoughts.github.io/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/sprint-1/artifact-specs.md (your artifact spec)
+9. <>
+
+# DOCTRINE INHERITANCE (memory files; rules in scope)
+
+Apply ALL of these:
+
+- feedback_curriculum_is_pure_lead_magnet.md (zero JT service CTAs; authorship credit only)
+- feedback_curriculum_viral_shareability.md (contrarian hook + tweetable insight + weekly tactic + artifact)
+- feedback_kiss_simplest_solutions_only.md (simplest method on main path; frameworks only in Advanced sidebars)
+- feedback_courses_are_journeys_not_topic_lists.md (input/output/checkpoint framing per post)
+- feedback_curriculum_posts_as_course.md (top callout + 9-row course-nav table)
+- feedback_no_length_caps.md (cut test per section; no word ceilings)
+- feedback_engagement_first_for_icp.md (effective delivery > template compliance)
+- feedback_infographics_required.md (≥3 handmade-style infographics per post)
+- feedback_jt_tech_stack_preferences.md (Rails/Django/Laravel + full-stack; no React/Node/Java as lead stack)
+- feedback_curriculum_sequence_self_serve_first.md (self-serve first → hire smart → manage well)
+
+# DELIVERABLES
+
+1. content/blog/<>/index.md
+   - Frontmatter: title ≤45 chars, description 150-160 chars, date <>, slug <>, 5 keywords, tags, cover_image: cover.png, metatags.
+   - Top callout (after frontmatter): > **Module <> of <>** · [Tech for Non-Technical Founders 2026](/blog/tech-for-non-technical-founders-2026/) free course.
+     > Input: <>. Output: <>.
+   - Hook (40-80 words, contrarian, distinct anecdote — check distinctness audit in 20.07 §"Distinctness audit").
+   - Why this matters in 2026 (≤120 words).
+   - Body sections per the post's row in 20.07.
+   - One quote-tweetable insight (140-280 chars) — flag it in the report.
+   - A specific tactic the reader executes this week.
+   - Inline reference to the companion artifact.
+   - Bottom: ## Continue the course with the 9-row module table (current module marked) + In Module X mini-list.
+   - Further reading (5+ real external citations).
+   - Authorship credit footer (NO JT service CTAs).
+
+2. docs/projects/2605-tech-for-non-technical-founders/50-59-execution/lead-magnets/<>.md
+   - Per the artifact spec in artifact-specs.md.
+   - Authorship credit footer.
+
+3. ≥3 handmade-style infographics: at least 1 inline SVG + at least 1 Mermaid block. Save SVG files to content/blog/<>/*.svg. Inline Mermaid in markdown.
+
+# REUSE EXISTING JT PATTERNS (mandatory)
+
+Use lean-ctx MCP or rg to find similar JT posts. Read 3+ existing JT posts that match the topic. Match voice + structure.
+
+# RULES (zero tolerance)
+
+- Plain English; founder-to-founder voice.
+- No em dashes (`-` only).
+- No banned words (leverage, unlock, harness, supercharge, robust, seamless, empower, streamline, delve, embark, revolutionize).
+- No rule of three, no signposting, no slogany closings, no shape tells.
+- Zero JT service CTAs anywhere.
+- Length is not a target — cut test per section.
+
+# REPORT BACK
+
+- File paths written (post + artifact + SVGs)
+- Word counts (informational; not a gate)
+- The quote-tweetable insight (one sentence, 140-280 chars)
+- The specific weekly tactic the reader executes
+- 4+ internal JT slugs linked (verified with ls)
+- 5+ external citations
+- Confirmation: zero JT service CTAs; authorship credit present
+- Confirmation: course-frame top callout + 9-row nav table present
+- Anonymized incident used (one sentence; confirm distinct from corpus per distinctness audit)
+- 3 things flagged for human review
+```
+
+---
+
+## 📦 Sprint 1 task briefs (dispatch-ready)
+
+### S1.1 - Module 0.1 Course Map + Self-Assessment
+
+**Placeholder fills**:
+- POST TITLE: "Where Are You in the Founder Journey? Take the 10-Question Self-Assessment"
+- SLUG: `course-map-self-assessment-non-technical-founder-2026`
+- MODULE.STEP: 0.1 (the only post in Module 0)
+- MODULE-POSTS: 1
+- DATE: 2026-07-01
+- ARTIFACT-FILENAME: `self-assessment-worksheet`
+- INPUT: An idea, an instinct, or an ongoing project that feels stuck
+- OUTPUT: Self-diagnosis + your starting module
+- TASK-SPECIFIC SISTER FILES:
+  - Read `20.01-course-modules.md` §"The 10 self-assessment questions + routing logic" — the questions are already specified.
+  - Read the 4 drafted posts to match course-frame style.
+
+**Task-specific guidance**:
+- The post EXPLAINS the 10 questions with one anonymized founder example per pillar (1-2 questions = early stage / 3-5 = mid build / 6-7 = managing team / 8-10 = AI-era risks).
+- The artifact IS the 10 questions in checkbox form + the routing flowchart. Reader prints it, fills in 5 minutes, writes their starting module at top of a Notion doc.
+- This is the COURSE ENTRY POINT. Hook must be strong enough to land readers from cold Reddit/Twitter traffic. Contrarian hook example: "Most non-technical founder courses ask you to commit to a 6-month program before they tell you what you'll learn. This 10-question quiz routes you to your starting module in 5 minutes, then disappears."
+- Distinct anecdote (per distinctness audit): try something like "Three founders we picked up in Q1 2026 thought they needed the same thing - 'help my team ship.' All three actually needed different modules: one needed Module 5 (oversight rhythm), one needed Module 1 (her problem was unvalidated), one needed Module 6 (her team was lying to her face)."
+
+**Dispatch**: copy the canonical brief template above, fill placeholders, spawn `general-purpose` agent.
+
+---
+
+### S1.2 - Module 1.1 Find 10 People with the Problem
+
+**Placeholder fills**:
+- POST TITLE: "Find 10 People With the Problem in 2026 (Without Knowing Anyone)"
+- SLUG: `find-10-people-with-problem-outreach-2026`
+- MODULE.STEP: 1.1 (Step 1 of 3 in Module 1)
+- MODULE-POSTS: 3
+- DATE: 2026-07-08
+- ARTIFACT-FILENAME: `outreach-sequence-template`
+- INPUT: A validated problem you suspect is real (Module 0 routed you here)
+- OUTPUT: 10 ICP interviewees booked for next week
+- TASK-SPECIFIC SISTER FILES:
+  - Read `friday-demo-template.md` and `ownership-checklist.md` for artifact format mirroring.
+
+**Task-specific guidance**:
+- The post teaches the 2026 outreach stack: Reddit/LinkedIn/Discord mining + Clay or Apollo for list building + Lindy AI agent for sequence + paid panels (User Interviews, Respondent) as backup.
+- Specific tools to name: Clay (~$149/mo), Apollo ($49-$149/mo), Smartlead/Instantly (~$37-$94/mo), Lindy, User Interviews, Respondent.
+- The smoke-test landing page as a parallel validation track: Carrd or Framer + £100-200 of paid Google/LinkedIn traffic.
+- Contrarian hook example: "A YC manifesto says you can validate a startup without writing code. They left out the hard part: getting the first 10 strangers to talk to you. Here's the 2026 stack that books 10 ICP interviews in one morning."
+- Distinct anecdote: a founder who tried "I posted in 3 subreddits and got 47 DMs in 24 hours" or "She paid $750 to User Interviews and had 10 calls in her calendar by Friday."
+
+**Dispatch**: WAIT for S1.1 review pass. Then copy canonical brief template, fill placeholders, spawn.
+
+---
+
+### S1.3 - Module 1.2 The Mom Test
+
+**Placeholder fills**:
+- POST TITLE: "The Mom Test: Ask About the Past, Not the Future"
+- SLUG: `mom-test-ask-about-past-not-future`
+- MODULE.STEP: 1.2 (Step 2 of 3 in Module 1)
+- MODULE-POSTS: 3
+- DATE: 2026-07-15
+- ARTIFACT-FILENAME: `mom-test-interview-script`
+- INPUT: 10 interview slots booked (from Module 1.1)
+- OUTPUT: 10 transcripts of honest past-behavior conversations
+- TASK-SPECIFIC SISTER FILES:
+  - Read `agency-ai-five-questions.md` for the "5 questions with Pass/Fail scoring" structural pattern — the Mom Test artifact follows similar.
+
+**Task-specific guidance**:
+- Teach Rob Fitzpatrick's "Mom Test" (book: *The Mom Test*, 2013) WITHOUT making the framework name the lead. Frame as "the technique that prevents your interviewees from being polite."
+- 3 core principles: (1) talk about past behavior not hypothetical, (2) ask for specifics not generalities, (3) listen for emotional language (frustration, hack, workaround).
+- Specific 5-question script: when's the last time X happened? what did you actually do? what did it cost you (time/money/sanity)? how big a deal is this on a scale of 1-10? what have you tried already?
+- Contrarian hook example: "Most customer interviews are useless because they're polite. Your interviewees will tell you the idea is great. They will be lying. Here's the technique that gets them to say what they actually do."
+- Distinct anecdote: a founder who asked "would you pay for this?" and got 8 enthusiastic yeses, then launched and 0 paid.
+
+**Dispatch**: WAIT for S1.2 review pass. Then copy canonical brief, fill, spawn.
+
+---
+
+## 🔎 Post-return review checklist (run after every writer agent returns)
+
+For each returned draft, verify the following in order. Fail any gate → surface to user. Pass all → mark task complete + queue next.
+
+### Mechanical gates (greppable)
+
+```bash
+F=content/blog//index.md
+echo "em-dashes (must be 0):"
+grep -c "—" "$F"
+echo "banned words (must be empty):"
+grep -niE "\b(leverage|unlock|harness|supercharge|robust|seamless|empower|streamline|delve|embark|revolutionize)\b" "$F"
+echo "JT service CTAs (must be empty):"
+grep -niE "Control Audit|JT runs|JetThoughts runs|book a call|schedule a consultation" "$F"
+echo "React/Node/Java as lead stack (must be empty except in 'wrong example' context):"
+grep -niE "\b(react\b|next\.js|node\.?js|java\b|kotlin)\b" "$F" | grep -v "JavaScript\|over-engineered\|jetthoughts.com\|counter-example"
+echo "Top callout present:"
+grep -c "^> \*\*Module" "$F"
+echo "Continue the course nav present:"
+grep -c "^## Continue the course" "$F"
+echo "Authorship footer present:"
+grep -c "Built by JetThoughts as part of the free" "$F"
+```
+
+Expected: 0 em-dashes, 0 banned, 0 CTAs, 1 callout, 1 nav, 1 footer.
+
+### Structural gates (manual read)
+
+- [ ] Contrarian hook in opening 80 words (quote it in your review notes)
+- [ ] One quote-tweetable insight 140-280 chars (quote it)
+- [ ] A specific tactic the reader executes this week (quote it)
+- [ ] ≥3 infographics: ≥1 SVG file in post directory + ≥1 Mermaid block in markdown
+- [ ] Course-frame top callout: Module/Step/Module-of-N/Input/Output all filled
+- [ ] Course-nav table: 9 module rows + In Module X mini-list with current post marked
+- [ ] Anonymized incident (distinct from corpus — check against distinctness audit in 20.07)
+- [ ] 4+ internal JT blog links (verified via `ls content/blog//index.md` for each)
+- [ ] 5+ external citations (real URLs)
+- [ ] Artifact file shipped at `50-59-execution/lead-magnets/.md`
+- [ ] Artifact has authorship footer
+
+### Voice gates (read the draft cold)
+
+- [ ] No "rule of three" rhetorical patterns
+- [ ] No signposting ("First… Second… Third…")
+- [ ] No slogany flips ("X works. Y doesn't.")
+- [ ] No cinematic beat-marking ("Long pause." "Five minutes in…")
+- [ ] Every sentence has a person doing something (no impersonal fragment stacking)
+- [ ] Practitioner-voice anecdote, not therapist-voice
+
+If all gates pass → mark task complete + queue next sprint task.
+
+---
+
+## 📢 Per-chunk announce workflow (build-in-public)
+
+Per the "small chunks + notice ICP in progress" directive (2026-05-12), every approved chunk publishes immediately and gets announced. The course is built in public — readers see momentum.
+
+**When a chunk (post + artifact + cover image) passes all gates:**
+
+1. **Hugo build** + commit to master → post goes live.
+2. **Update the landing page** at `content/blog/tech-for-non-technical-founders-2026/index.md`:
+   - Module table status column: `🔲 Coming` → `🟡 Partial (N of M chapters)` → `🟢 Complete` as the module fills in.
+   - **Do NOT publish a post count** ("X of 26 posts") to readers - they care about modules + reading time, not chapter-by-chapter granularity (memory directive 2026-07-22).
+   - Update the "Status: which modules complete" line at the top of the modules table.
+   - Update "What's live right now" with the new chapter link.
+   - Update "Coming next" to reflect queued chapters.
+   - Bump the "Last updated" date.
+3. **Post the announcement** per `distribution-prep.md` schedule:
+   - Day 0: blog post + landing page update
+   - Day 1: LinkedIn (Paul Keen voice, per `linkedin-post-pipeline.md`) + Twitter thread (JT brand + Paul Keen accounts)
+   - Day 3: Reddit (r/startups + 1 niche sub) + Facebook (1-2 founder groups)
+   - Day 7: Email newsletter feature
+   - Day 14: Reddit 2nd wave if first wave landed
+4. **Notify-list email** (once email-capture is wired up): send a one-paragraph email to the subscribed list — "[Post title] just shipped. Read it here. Download artifact here. Next post: [topic] coming [date]."
+5. **Update TASK-TRACKER** with the published SHA + status.
+
+The build-in-public mechanic: each chunk feels like an event, not a deliverable. ICP sees the course growing in real time. Share velocity compounds because each launch has its own social moment.
+
+**Frequency target**: 1-2 chunks per week. Sprint 1 = 3 chunks over 3 weeks. After Sprint 1, cadence can go to 2/week.
+
+## 🎭 Hook-bank diversity rule (added 2026-07-15 after S1.3 cold-eyes review)
+
+The "A founder we picked up..." anecdote pattern now anchors 8+ posts. Cold-eyes verifier on S1.3 flagged the JT-signature tell is wearing. For all Sprint 2+ writer briefs, the writer must NOT lead the hook with "A founder we picked up in QX 20XX..." pattern.
+
+Rotate hook archetypes across posts:
+- Interview transcript snippet ("'I'd absolutely pay for that.' She said it on Tuesday. She didn't pay.")
+- Raw stat ("Founders who validate with 10+ past-behavior interviews ship 4x faster than founders who validate with hypotheticals.")
+- Direct address ("You are about to send 60 polite LinkedIn DMs. You will book 3 calls. Two will ghost.")
+- Reddit poster ("A founder posted in r/startups last week: 'I've been on the phone with 11 prospects and none of them said no.' She had asked them all the wrong question.")
+- Twitter/X founder ("Lenny Rachitsky tweeted last month: '47% of customer interviews are worthless because the founder asks about the future.'")
+- News-pegged opener ("YC's W26 batch shipped 3 startups with zero customer interviews. Two failed by demo day.")
+- The product-tour reveal ("Open Calendly. Six calls booked. Read the names. Three are your old colleagues. Two are friends-of-friends. One is your mother. Validation is not happening.")
+
+Apply at minimum 2 different archetypes across the next 5 posts.
+
+## 🔁 After Sprint 1 closes
+
+When all 3 Sprint 1 tasks complete + reviewed:
+
+1. Update `TASK-TRACKER.md` → mark Sprint 1 complete; promote Sprint 2 to current.
+2. Sprint 2 tasks (queue):
+   - S2.1: Module 1.3 (Validated Problem Statement post + template) - closes Module 1
+   - S2.2: Module 2.2 (One-Page Product Brief post + Vibe PRD template)
+   - S2.3: Module 2.3 (Stop Specifying Features post; teaches job-story TACTIC without naming framework)
+3. Run the same dispatch pattern (canonical brief template + task-specific placeholders).
+4. Surface to user after Sprint 2 closes for any direction adjustments before Sprint 3.
+
+---
+
+## 📊 Distribution-readiness check
+
+Before publishing any Sprint 1 post, verify the distribution prep:
+- Read `distribution-prep.md` for the target subreddits, Twitter accounts, Facebook groups, and LinkedIn hashtag library for the post's pillar/module.
+- Confirm the post's quote-tweetable insight is ≤280 chars (counts in distribution-prep's tweet template).
+- Confirm the artifact is email-gated (or queued to be) before public sharing.
+
+The post going viral without the artifact gate live is wasted distribution.
+
+---
+
+## 🛑 Stop conditions (surface to user immediately)
+
+Halt and ping the user if:
+- A writer agent returns with JT service CTAs present (zero tolerance, Option C is non-negotiable)
+- A writer agent introduces React / Node / Java as the lead example stack
+- A writer agent reuses an anonymized anecdote already in the corpus (distinctness rule)
+- A writer agent's draft contains em dashes or banned words
+- A mechanical gate fails twice on the same draft (agent isn't applying the brief)
+- The artifact is missing or doesn't follow the spec in `artifact-specs.md`
+- Hugo build fails on the new post
+
+Do NOT auto-spawn the next task if review fails. WIP=1 sequential discipline must hold.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/distribution-prep.md b/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/distribution-prep.md
new file mode 100644
index 000000000..396faf441
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/distribution-prep.md
@@ -0,0 +1,167 @@
+# Distribution Prep - Where to Share Course Content
+
+**Purpose**: the course is a pure lead magnet engineered for viral sharing (memory: `feedback_curriculum_viral_shareability.md`). This file lists the target channels, share-copy templates, and frequency norms so a separate session can ship + distribute without re-deriving the playbook.
+
+**Last Updated**: 2026-05-12
+
+---
+
+## Channel inventory (ranked by ICP fit)
+
+### Reddit (highest share-velocity for non-tech founders)
+
+| Subreddit | Subscribers | Why it fits | Posting cadence |
+|---|---|---|---|
+| **r/startups** | ~1.5M | General founder audience; ICP-E lives here | Once per post, top-of-funnel framing |
+| **r/SaaS** | ~270K | B2B/SaaS founders; especially good for Module 4B-5-6 posts | Once per post, more technical framing OK |
+| **r/Entrepreneur** | ~3.5M | Broadest audience; ICP-E adjacent | Once per Module 0-3 post (less for technical) |
+| **r/EntrepreneurRideAlong** | ~330K | Bootstrap / indie hacker; great for Module 4A self-serve | Once per Module 4A post |
+| **r/nocode** | ~110K | Direct fit for Module 4A (Lovable + Supabase + Stripe) | Once for Module 4A.1 |
+| **r/vibecoding** | ~12K (growing fast in 2026) | Direct fit for Module 4A + Module 7 (AI-era posts) | Once for Module 4A.2, Module 7 posts |
+| **r/cofounder** | ~95K | Module 3.2 (Fractional CTO bridge) audience | Once for Module 3.2 |
+| **r/AskMarketing** | ~280K | Module 0-1 (validate) when reframed as marketing | Once for Module 1.1 (the outreach post) |
+| **r/devops** | ~430K | NOT a fit — actively hostile to non-tech founders | Skip |
+
+**Posting rules per Reddit**: read each sub's rules. Most ban "promotional" posts but allow educational longforms with no service pitch. JT's pure-lead-magnet positioning is the unlock — we can post freely because there's nothing to sell.
+
+**Title pattern that works**: "[Module topic] — what I learned from rescuing 47 founders" or "How [anonymized founder] lost $[X] to [specific mistake]" or "Stop [common bad practice] — here's what works in 2026."
+
+---
+
+### Twitter / X (highest quote-tweet velocity)
+
+| Account / channel | Why | Posting cadence |
+|---|---|---|
+| **Paul Keen (@PaulKeen2)** — JT principal | Founder-voice account; existing follower base of non-tech founders | One thread per post; per `linkedin-post-pipeline.md` voice rules, also publish to LinkedIn |
+| **JetThoughts brand (@jetthoughts)** | Company account; broader reach for course launches | One tweet per post sharing the quote-tweetable insight + course link |
+| **Tagged for visibility** (in threads, when relevant) | @SophiaMatveeva, @DHH, @rwalling (Rob Walling), @jakeknapp (Foundation Sprint author), @teresacatorres (Continuous Discovery) | Tag thoughtfully — only when content genuinely references their work |
+
+**Thread structure that works (per existing JT LinkedIn pipeline)**:
+1. Tweet 1: The quote-tweetable insight (140-280 chars) standalone
+2. Tweets 2-5: Anonymized rescue story with $$$ + tech specifics
+3. Tweet 6: The 3-step tactic the reader executes this week
+4. Tweet 7: "Free template / artifact" with link to artifact download
+5. Tweet 8: Full post link
+
+**Hashtag library** (use 2-3 max per thread):
+- #startup #saas #nontechfounder #vibecoding #founderlife
+- #buildinpublic (Module 4A specifically)
+- #devshop #rescuemymvp (Module 4B, 5, 6 specifically)
+- #LLM #AI (Module 7 specifically)
+
+---
+
+### Facebook (long-form personal stories)
+
+| Group | Audience | Cadence |
+|---|---|---|
+| **Bootstrapped Founders** (~40K members) | Indie hackers + early-stage SaaS | Once per Module 4A or Module 1 post |
+| **SaaS Founders Pro** (~30K) | B2B SaaS specifically | Once per Module 4B / 5 / 7 post |
+| **Y Combinator founders** (private) | YC alums | Skip unless cleared (private group) |
+| **Indie Hackers** (~50K Facebook group + Indie Hackers community) | Bootstrap / no-VC audience | One per Module 4A / 1.1 post |
+
+**Post structure that works on Facebook**:
+1. Long-form opener (personal story, 300-500 words)
+2. The specific tactic the reader can use
+3. Free resource link (artifact download)
+4. NO service pitch (per Option C; group admins ban service spam fast)
+
+---
+
+### LinkedIn (existing JT pipeline)
+
+Per `docs/workflows/linkedin-post-pipeline.md`. Paul Keen voice. The LinkedIn validation sprint for the 10 wrap posts is already in flight via 2510 plan (May 13 - June 17, 2026).
+
+For Sprint 1 (2605 net-new posts), LinkedIn promo follows the same pipeline — one LinkedIn post per blog post, published 1-2 days after the blog post is live.
+
+**LinkedIn voice rules** (from `linkedin-post-pipeline.md`):
+- Paul Keen's flat-conviction voice (no "17 years" credential stamps)
+- Anti-AI patterns: no slogany flips, no "X works. Y doesn't.", no rule of three
+- Use `-` not `—`
+
+---
+
+### Email newsletter (existing JT list)
+
+The JT newsletter goes out weekly. Each new course post is featured in the week's send. The artifact download (email-gated) feeds new subscribers into this list.
+
+Cadence: one course post per week in the newsletter (out of the 26 total, that's a 26-week feature plan; Sprint 1 takes the first 3 weeks).
+
+---
+
+## Share-copy templates (paste-ready)
+
+### Reddit r/startups post template
+
+```
+Title: [Stop X — here's what works in 2026]
+
+Body:
+[300-500 word opening: anonymized rescue story with specific $$$ + tech specifics, no "I" if possible, founder-to-founder voice]
+
+[The specific tactic the reader can execute this week — 3 bullet points]
+
+[Free artifact link to the curriculum landing page OR direct artifact download]
+
+[1-sentence closer: "Wrote a longer version here: [link]"]
+
+No service pitch. Reddit will downvote it.
+```
+
+### Twitter thread template (kickoff tweet)
+
+```
+[The quote-tweetable insight from the post — 140-280 chars, standalone]
+
+🧵 [thread emoji indicator]
+
+[Followed by 5-8 tweets per structure above]
+```
+
+### Facebook group post template
+
+```
+[Long-form personal-story opener, 300-500 words; specific founder names anonymized; concrete dollar amounts; one tech mechanic named]
+
+The tactic: [3 bullets]
+
+Free template: [link]
+
+I'm happy to discuss in comments.
+```
+
+---
+
+## Posting schedule per Sprint 1 post
+
+| Post | Day 0 | Day 1 | Day 3 | Day 7 | Day 14 |
+|---|---|---|---|---|---|
+| Publish blog post | ✅ | | | | |
+| LinkedIn post (Paul Keen) | | ✅ | | | |
+| Twitter thread (Paul + JT accounts) | | ✅ | | | |
+| Reddit r/startups + 1 niche sub | | | ✅ | | |
+| Facebook (1-2 groups) | | | ✅ | | |
+| Email newsletter feature | | | | ✅ | |
+| Reddit 2nd wave (different sub) if first wave landed | | | | | ✅ |
+
+---
+
+## Tracking (manual until analytics ships)
+
+Per post, log to a shared sheet:
+- Reddit share count + upvotes + comments per sub
+- Twitter retweets + likes + thread reads
+- Facebook reactions + shares per group
+- Email open rate + click-through to artifact download
+- Artifact download email captures (gated)
+
+Aggregate weekly. Target per `GOAL-AT-A-GLANCE.md`: ≥25 shares per post within 30 days of publish.
+
+---
+
+## What we don't do
+
+- **No paid amplification** in Sprint 1. The course either earns shares or it doesn't. If post 3 has <25 shares by day 30, the issue is the content, not the budget.
+- **No service pitches** in any distribution copy. Option C is non-negotiable across channels.
+- **No engagement-bait formats** ("hot take" / "unpopular opinion" / "controversial" labels). The contrarian hook lives in the headline, not in marketing-by-meta-framing.
+- **No cross-posting same text to all subs** in the same hour. Reddit's spam detection is sharp; space posts 2-3 days apart per sub.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/mechanical-audit-checklist.md b/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/mechanical-audit-checklist.md
new file mode 100644
index 000000000..13955d409
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/mechanical-audit-checklist.md
@@ -0,0 +1,241 @@
+# Mechanical Audit Checklist
+
+**Purpose**: every greppable + structural gate a 2605 course post must pass before being marked complete. A separate session running review can grep this file's commands instead of re-reading 10 memory files.
+
+**Pairs with**: `docs/workflows/course-chapter-pipeline.md` — the PRE-write + DURING-write guide (structure, voice, ICP-Sam profile, cold-eyes panel). This file is the POST-write audit.
+
+**Usage**: run the bash block at the top against the post file → manually verify the structural gates → manually verify the voice gates → if all pass, mark task complete.
+
+---
+
+## 🤖 Greppable mechanical gates (paste into terminal)
+
+```bash
+F=content/blog//index.md
+
+echo "=== EM-DASHES (must be 0) ==="
+grep -c "—" "$F"
+
+echo ""
+echo "=== BANNED WORDS (must be empty) ==="
+grep -niE "\b(leverage|unlock|harness|supercharge|robust|seamless|empower|streamline|delve|embark|revolutionize|paradigm|cutting-edge|world-class|game-changer|elevate)\b" "$F" || echo "✅ clean"
+
+echo ""
+echo "=== JT SERVICE CTAs (must be empty - Option C) ==="
+grep -niE "Control Audit|JT runs|JetThoughts runs|book a call|schedule a consultation|book a (free )?(call|consultation)|get in touch|contact us" "$F" || echo "✅ no service CTAs"
+
+echo ""
+echo "=== AUTHORSHIP CREDIT FOOTER (must be 1) ==="
+grep -c "Built by JetThoughts as part of the free" "$F"
+
+echo ""
+echo "=== TOP CALLOUT (must be 1) ==="
+grep -c '^> \*\*Module' "$F"
+
+echo ""
+echo "=== CONTINUE THE COURSE NAV (must be 1) ==="
+grep -c '^## Continue the course' "$F"
+
+echo ""
+echo "=== ← YOU ARE HERE MARKER (must be 1+) ==="
+grep -c "← you are here" "$F"
+
+echo ""
+echo "=== REACT/NODE/JAVA AS LEAD STACK (must be empty in main path) ==="
+grep -niE "\b(react\b|next\.js|node\.?js|express|nest\b|angular|vue\b|java\b|kotlin)\b" "$F" | grep -v "JavaScript\|over-engineered\|jetthoughts.com\|counter-example\|hallucinated\|never tried" || echo "✅ no leak"
+
+echo ""
+echo "=== EMOJI IN BODY (must be 0 in body; emoji in frontmatter OK) ==="
+sed -n '/^---$/,/^---$/!p' "$F" | grep -c "[🎯🔥💡⚠️✅❌📊🚀🛡️📋🔍🧪]"
+
+echo ""
+echo "=== INFOGRAPHICS (≥3: SVG files + Mermaid blocks) ==="
+echo "SVG files in post directory:"
+ls content/blog//*.svg 2>/dev/null | wc -l
+echo "Mermaid blocks in post:"
+grep -c '^```mermaid' "$F"
+
+echo ""
+echo "=== INTERNAL JT BLOG LINKS (must be 4+) ==="
+grep -oE '/blog/[a-z0-9-]+/?' "$F" | grep -v 'tech-for-non-technical-founders-2026' | sort -u | wc -l
+
+echo ""
+echo "=== EXTERNAL CITATIONS (must be 5+) ==="
+grep -oE 'https?://[^ )]+' "$F" | grep -v 'jetthoughts.com\|/blog/' | sort -u | wc -l
+```
+
+**Expected outputs**:
+- Em-dashes: 0
+- Banned words: empty / "✅ clean"
+- JT service CTAs: empty / "✅ no service CTAs"
+- Authorship credit footer: 1
+- Top callout: 1
+- Continue the course nav: 1
+- `← you are here` marker: 1 or more (one in module table + one in In Module X mini-list)
+- React/Node/Java leak: empty / "✅ no leak"
+- Emoji in body: 0
+- SVG files: ≥2
+- Mermaid blocks: ≥1
+- Internal JT blog links: 4+
+- External citations: 5+
+
+Fail any one → surface to user. Do not mark complete.
+
+---
+
+## 👁️ Structural gates (manual read)
+
+Verify each item by reading the draft. Note specific line numbers when an item fails.
+
+- [ ] **Contrarian hook in opening 80 words.** Quote it back in your review notes. Test: would a Reddit r/startups reader paste this in a comment? If yes, pass.
+- [ ] **One quote-tweetable insight (140-280 chars).** Single sentence. Stands alone outside the post. Quote it back; count chars.
+- [ ] **Specific weekly tactic.** What does the reader DO this week as a result of reading? Not abstract advice. Quote the specific action sentence.
+- [ ] **Course frame top callout** with: Module · Step · Input · Output. All 4 fields filled. Module/step matches `20.01-course-modules.md` placement.
+- [ ] **Course-nav table at bottom**: 9 module rows (0-7 with 4A/4B as branch) + current module marked + `In Module X` mini-list with current post marked.
+- [ ] **Anonymized incident** in the body. Check against the distinctness audit in `20.07-content-plan-tnt-founders-2026.md` § "Distinctness audit". Should be DISTINCT from $51K / $44K / $78K / $62K / $180K / $95K / $34K / $25K anchors already in the corpus.
+- [ ] **At least 4 internal JT blog links** woven in prose (not just footer). Each verified to exist via `ls content/blog//index.md`.
+- [ ] **At least 5 external citations** with real URLs. No fabricated stats.
+- [ ] **≥3 handmade-style infographics**: ≥1 inline SVG + ≥1 Mermaid block. Visually verify the SVG renders (open in browser) and the Mermaid is syntactically valid.
+- [ ] **Companion artifact** shipped at `50-59-execution/lead-magnets/.md`. Follows the spec in `sprint-1/artifact-specs.md`.
+
+---
+
+## 🎙️ Voice gates (read the draft cold)
+
+Read the post end-to-end before checking these. If you find yourself skimming, that's already a fail.
+
+- [ ] No "rule of three" rhetorical patterns (3+ parallel clauses for emphasis)
+- [ ] No signposting ("First... Second... Third...")
+- [ ] No slogany flips ("X works. Y doesn't." / "It's not Y. It's Z.")
+- [ ] No cinematic beat-marking ("Long pause." / "Five minutes in...")
+- [ ] No noun stacking without human subject ("React + Rails, clean conventions, the demo sailed.")
+- [ ] No "the..." paragraph-opener density > 20%
+- [ ] Every sentence has a person doing something (no impersonal fragment stacking)
+- [ ] Practitioner-voice anecdote (named industry + quarter + dollar + mechanic), not therapist-voice
+- [ ] No essay arc (hook → pivot → thesis → evidence → caveat → close — typical AI shape)
+- [ ] No pivot sentences ("That's the experience of..." / "Here's what's underneath..." / "The bigger problem is...")
+- [ ] No apologetic caveats ("every project is different" / "it depends on the use case")
+- [ ] No fluffy AI narration (dramatic present-tense "The alerts fire correctly. Then someone upgrades...")
+
+---
+
+## 📓 Learnings log + added gates (Module 1 polish, 2026-05-22)
+
+These cases surfaced during the Module 1 (Hypothesis / Smoke-Test / Price) polish pass. Each is now a gate so the next chapters don't repeat it. **AUTO** = caught by `bin/validate-course` (hooked into `bin/hugo-build`). **Manual** = a read-back item below.
+
+| # | Case we hit | Lesson | Enforced by |
+|---|---|---|---|
+| 1 | Chapter opened with rescue/trauma framing ("you already got burned... information asymmetry") | Course ICP is "Sam," the idea-stage pre-spend founder - NOT "Alex," the burned website lead-gen ICP. Rescue framing is off-ICP for course bodies. | Manual: read-back #3 |
+| 2 | "Already burned?" routing block at chapter top interrupted the primary reader | Route burned founders at the LANDING page only; don't staple per-chapter routing blocks. Question inherited elements proactively. | Manual: read-back #5 |
+| 3 | "ICP" used ~22x, never glossed for a newbie | Gloss every acronym/tool at FIRST mention (what it is, in plain words). | Manual: read-back #1 |
+| 4 | "Most founders we joined in 2026..." (fabricated client-cohort year) | Don't stamp client cohorts with a year (untrue + redundant). | AUTO: `year-stamp-fabrication` |
+| 5 | Hardcoded "Carrd or Framer" while the chapter offers more builders | Don't couple to a tool subset in forward refs or meta; name the category. | Manual: greppable tool-coupling |
+| 6 | Rewrote the whole opener for a one-attribute ($300) fix; lost the page's value thesis | Surgical edits: change only the named attribute, never rebalance the page. | Manual: surgical-edit gate |
+| 7 | Budget stance swung free-first → paid-first → balanced (4 round-trips) | Land the principle once at the documented middle; don't swing to the opposite extreme. Free and paid are EQUAL options, reader chooses (see GOAL delivery principle). | Manual: surgical-edit gate |
+| 8 | Added an alias bridge during a "clean" rename | Zero tech debt: for a brand-new URL, remove old refs + update, add NO alias bridge. | Manual: surgical-edit gate |
+| 9 | Stale link LABEL after slug rename (URL updated, text didn't) | After any rename, sweep display labels, not just URLs. | Manual: surgical-edit gate |
+| 10 | Two stacked highlighted blockquote callouts (crowded) | Visual rhythm: the Module-nav banner is the one highlighted block; the opener is plain prose. No two adjacent same-form callouts. | Manual: read-back #4 |
+| 11 | "≥300 paid visits or ≥30 organic" front-loaded into the orientation banner | Progressive disclosure: banners orient; push thresholds/metrics down to where the reader acts on them. | Manual: read-back #2 |
+| 12 | Disclaimer present in only 2 of 18 chapters | Course-wide artifacts are all-or-none. | AUTO: `disclaimer-consistency` |
+| 13 | Em-dashes across 9 chapters | Use "-" not "—" everywhere. | AUTO: `no-em-dash` |
+| 14 | $62K / $38,400 dollar anchors too big for "Sam" | Keep a worst-case ceiling, but lead with a Sam-scale anchor ($500 + a few weekends) so the reader sees themselves. | Manual: read-back #6 |
+| 15 | Signposting ("The pattern holds across...", "What the strong examples share") | Show the evidence; let the reader reach the conclusion. Banned signposting. | Manual: voice gates (above) |
+| 16 | "Founders who..." generalized-actor refrain (7× in one chapter) | Caught by 4-persona cold-eyes panel (2026-05-23). Generalized "Founders who X..." opener as a refrain reads as one consultant voice running a template - not a practitioner. Cap usage at 2-3 instances per chapter; for the rest, rephrase as direct second-person ("Pivot before building and you learn in days...") or name a specific actor (Priya, Marcus). | Manual: read-back #7 (below) |
+| 17 | Course-internal jargon (Magic Lens, Foundation Sprint, Mad Libs blanks, Customer lens) used without inline gloss | Cold readers landing mid-funnel from search/social don't know these terms. Either inline-gloss ("the four hypothesis lenses from Ch 1.1 - customer, problem, approach, money") or rephrase to not need the term ("your weakest hypothesis blank"). | Manual: read-back #1 (acronyms/terms glossed at FIRST mention) |
+| 18 | First-timer tab-closer in tracking / setup sections (GA4 + Pixel + Clarity all stacked = brain shutdown) | When a section installs multiple tools, lead with the **minimum viable** one (Clarity = 4-min install, free forever, biggest signal-per-effort). Demote the others to "add these too if your channel needs it." A first-timer ships the test or doesn't; the kitchen-sink list is what makes them quit. | Manual: read-back #8 (below) |
+| 19 | Per-channel cost spread without an escape hatch when the right channel is too expensive | A LinkedIn-best ICP staring at $1,800-$6,600 with $20K savings closes the tab. After any "the right channel depends on your ICP" table, add a "if the right channel is out of reach: [substitutes at ~10% of cost]" sidebar. The substitutes (organic outreach, Reddit B2B, cold email) give comparable signal at a fraction of the spend. | Manual: read-back #9 (below) |
+| 20 | Recap sections multiplying (schedule table + "Three numbers to memorize" + "Your Monday morning") all doing the same job | The writer doesn't trust the lesson to land, so re-states it 3 ways. Pick one - the most action-oriented one. The reader gets the lesson once, in the format that drives them to act. | Manual: surgical-edit gate (already covered: no rebalancing for redundancy reasons) |
+| 21 | Variant / Advanced sidebar content that duplicates a sibling chapter | If Ch X has a "Variant" that re-covers material the next chapter already teaches in depth, replace the variant with a 1-2 sentence link. Variants belong in a chapter when they're UNIQUE to it; when they duplicate, the link wins. | Manual: surgical-edit gate |
+| 22 | Pad-then-discard listicle ("5 frames; pick 2") | Caught 2026-05-23 by Ch 1.3 cold-eyes panel. If the writer says "here are 5 X; pick the 2 best for you," just ship the 2. The other 3 add scroll-length, force the reader to discard, and signal "I padded this." Exception: when the 3 you'd discard are common-but-wrong choices the reader needs to NOT pick - then frame as a banned-vs-recommended split. | Manual: read-back #10 (below) |
+| 23 | A/B test instructions that assume infrastructure first-timers don't have ("split traffic 50/50") | Sam-blocker on Ch 1.3 (Sunday-night close-the-tab moment). For a first-time founder on Carrd + a $300 ad budget: split-testing requires either two ad sets to two URLs or a tool they don't have (Google Optimize is dead). For the smoke-test stage, instruction should be "pick one variant and ship it" - A/B testing is a post-launch tool. Same logic applies anywhere the chapter asks the reader to do statistically-disciplined experimentation on volume that can't support it. | Manual: read-back #11 (below) |
+| 24 | Multi-chapter forward-reference tease ("find out in Chapter 3.1") | Cold-eyes flagged: a chapter that twice points the reader at a *later* chapter for the real answer reads as "watching a movie that keeps saying 'find out in the sequel.'" Forward-references are fine for context ("when you reach the One-Page Brief in Module 3, you'll use this") but become a tease when the current chapter's promise depends on reading the later one. Either land the answer here, or rephrase as "a post-launch question, not a pre-build one" and stop pointing forward. | Manual: surgical-edit gate |
+| 25 | "## Why this matters" preamble before the lesson | Caught 2026-05-23 by real-human-practitioner voice analysis (Fitzpatrick + McKenzie). Both refuse the preamble; the vignette opener carries the stakes implicitly. Explicit "why this matters" reads as throat-clearing - delete it and let the opener vignette + the first concrete step land the chapter's promise. | Manual: read-back #12 (below) |
+| 26 | Written-artifact taught only by showing the GOOD version with `[brackets]` | Both Fitzpatrick and McKenzie teach by tearing apart the bad version first, then handing over the rewrite. When a chapter teaches a cold message / landing-page copy / interview script / founder-update email, lead with the typical wrong version, diagnose sentence-by-sentence what's wrong, then show the rewrite. The reader learns from the diagnosis, not from copying the answer. | Manual: read-back #13 (below) |
+| 27 | "5 steps with sub-bullets" shape for chapters teaching judgment + craft | Procedural shape (Step 1 / Step 2 / Step 3) reads as textbook / AI. For chapters teaching craft (which question to ask, what to write, when to give up), reshape the sequence as 2-3 reader questions ("How do I X? What do I write? What if Y?"). Steps stay for genuinely sequential procedures (set up Stripe, configure DNS). | Manual: read-back #14 (below) |
+| 28 | Paste-literal strings rendered as prose quotes ("Suggest 3 alternatives more focused on [vertical]") | Caught 2026-05-23 by user. Stripe / Anthropic / MDN convention: a string the reader pastes literally (AI prompt, CLI command, SMS template, search string, hypothesis sentence) goes in `backtick code spans`, not "prose double-quotes." Prose quotes are reserved for dialog or things a person said. Double-quoting a paste-literal string makes the reader unsure whether the quotes are part of what they type. | Manual: read-back #15 (below) |
+| 29 | Prompt template with `[bracketed blanks]` and no upstream pointer to where the inputs come from | If the chapter hands the reader a fill-in-the-blank prompt, every blank must be sourced from somewhere the reader can point to: an earlier section in the same chapter, a named upstream chapter, or a one-line "how to find it in 5 minutes" inline. Caught 2026-05-23: the 2.2 AI ICP map prompt asked for 2 competitor URLs the course never produced - the reader hits the prompt and stalls. | Manual: read-back #16 (below) |
+| 30 | Redundant "free" qualifier on tools the reader already knows are free (Reddit, Gmail, ChatGPT free tier) | Caught 2026-05-23 by user. "free Reddit account, free Gmail" reads as defensive over-explanation and recreates the parallel-block AI tell (free X / free Y / free Z). Strip the "free" qualifier when the tool is commonly known to have a free path (Reddit, Gmail, Twitter, Discord, etc.). Keep "free tier" or "free path" only when it differentiates the tool's tiers (Apollo's free tier, Streak's free tier - both have paid plans the reader does NOT need yet). | Manual: read-back #17 (below) |
+| 31 | Answering a clarifying question by adding a defensive block that restates what's already covered | Caught 2026-05-23 by user immediately after Case 29 fix. When a reader asks "where does input X come from?" the right fix is to add ONLY the guidance for the input that's actually missing, placed where the reader will need it (immediately after the prompt block, not before). Wrong fix is a paragraph that restates "you already have A, B, C" + "for D, do this..." - that recreates the AI parallel-block tell and adds words the reader does not need. Surgical = answer only what's missing; place it at the point of need. | Manual: read-back #18 (below) |
+| 32 | Slogany reveal-twist flip as opener or closer ("X hadn't been Y - Z had been", "It's not about X. It's about Y.", "X wasn't Y - it was Z") | Caught 2026-05-28 by user + 4-persona cold-eyes panel across M1-M3 (9 chapters, 25+ instances). The 2-sentence pivot from negation to assertion reads as a content-marketer punchline shape. Writer reaches for it because the shape feels structured; reader hears it as a slide-deck pull-quote. Fix: state the cause and effect in normal order ("the hypothesis was right; the questions were wrong" → "the hypothesis was probably right and the questions were probably broken; the real interviews confirmed both"). | Manual: read-back #19 (below) |
+| 33 | Cost-stacked tri-list opener ("$X-$Y in incentives, N minutes of calendar, one of M slots") | Caught 2026-05-28 by user. 3 parallel cost/time/count items presented as if from a workshop slide. Reads as didactic, not practitioner. The information is usually useful but the slide-shape parallel structure carries the AI tell. Fix: embed the costs in prose, drop the symmetric serial-list shape, or reduce to the one or two costs that actually matter for the reader's decision. | Manual: read-back #20 (below) |
+| 34 | Cute aphoristic flourish closer ("polite noise", "the kind smile that costs you a year", "the helpful answer is the trap", "Everything else is your mom being nice") | Caught 2026-05-28 by user. Invented metaphor used to package a teaching point at the end of a paragraph. Reads as marketing copy pull-quote, not practitioner observation. Fix: state the concrete mechanic instead ("polite noise" → "the interviewee says 'sure, I'd use it' to be kind, you hang up thinking you got a signal, and you got nothing usable"). | Manual: read-back #21 (below) |
+| 35 | Anonymous-named-founder opener template repeated chapter-after-chapter ("Priya, a FinTech founder...", "Maya, a founder we worked with...", "An ed-tech founder we picked up...", "A consumer-app founder we spoke with...") | Caught 2026-05-28 by 4-persona panel across M1-M3. Module 2 had 4 consecutive chapters opening with the same template shape (named-or-anonymous founder → fabricated number stack → tidy failure → magic-number reframe). Cold-eyes reader: "by chapter 5 it reads as one consultant's case-study generator." Even when each individual vignette is well-written, the repeated shape across the module reads as AI-generated. Fix: vary opener shapes across consecutive chapters - rotate between vignette, direct-instruction, named-research-result, and reader-question openers. No 3+ chapters in a row may share the same opener shape. | Manual: read-back #22 (below) |
+| 25-regression | Banned headings restored after they were removed in a prior pass | Caught 2026-05-28 - Case 25 ("## Why this matters in 2026") regressed in 3 of 9 chapters (CH 2.3, 3.1, 3.2). Banned patterns previously removed are at high risk during revision passes because the writer reaches for the same essay-frame habits. Fix: every revision pass must run `grep -rn "## Why this matters\|Founders who\|Most founders"` across edited chapters before handback. Treat banned-pattern regression as a BLOCKING failure, equivalent to introducing the pattern fresh. | AUTO candidate: extend `bin/validate-course` with `banned-headings` check |
+
+### 👓 New read-back items from the 2026-05-23 cold-eyes panel
+
+- [ ] 7. "Founders who..." / "the founder who..." opener used ≤2 times per chapter (count grep; any more, rephrase to second-person or name a specific actor).
+- [ ] 8. Multi-tool setup sections lead with the **minimum viable** tool (free, fastest install, biggest signal); others demoted to "add if your channel needs it" sidebar.
+- [ ] 9. Any per-channel cost/option table that prices a Sam-relevant option out of reach has an immediate escape-hatch sidebar with 2-3 cheaper substitutes.
+- [ ] 10. No "5 options; pick 2" pad-then-discard listicles - if 3 of them get discarded, ship the 2 that work.
+- [ ] 11. No A/B test instructions ("split traffic 50/50") at the smoke-test stage - smoke-test = pick one variant, ship it; A/B testing is a post-launch tool that requires infrastructure first-timers don't have.
+- [ ] 12. No "## Why this matters" preamble before the lesson. The vignette opener carries the stakes. If the chapter doesn't open with a vignette, write one - don't explain why the chapter matters.
+- [ ] 13. Every chapter that teaches a written artifact (cold message, landing-page copy, interview script, founder-update email) shows the BAD version first + sentence-by-sentence diagnosis + the rewrite. Not just the GOOD version with `[brackets]`.
+- [ ] 14. Chapters teaching judgment + craft are organized as 2-3 reader questions ("How do I X? What do I write? What if Y?") rather than 5 procedural steps. Procedural steps remain for genuinely sequential procedures (set up Stripe, configure DNS).
+- [ ] 15. Paste-literal strings (AI prompts, CLI commands, SMS templates, search strings, hypothesis sentences) are wrapped in `backtick code spans`, not "prose double-quotes." Dialog stays in double-quotes.
+- [ ] 16. Every fill-in-the-blank prompt template the chapter hands the reader has each `[bracketed blank]` sourced from a named upstream section, a referenced chapter, or a one-line "how to find it in 5 minutes" inline. No orphan blanks.
+- [ ] 17. No redundant "free" qualifier on commonly-known-free tools (Reddit, Gmail, Twitter, Discord, ChatGPT free tier). Keep "free tier" only when the tool has paid tiers the reader doesn't need yet (Apollo, Streak, etc.) and the differentiation matters.
+- [ ] 18. When fixing a Case-29-style prompt-input gap, add ONLY the guidance for the missing input, placed at the point of need (immediately after the prompt block). Never add a "you already have X, Y, Z + for W do this" defensive block - that restates what's already covered AND recreates the parallel-block AI tell.
+
+### 👓 New read-back items from the 2026-05-28 4-persona M1-M3 audit
+
+- [ ] 19. No slogany reveal-twist flips ("X hadn't been Y - Z had been", "It's not about X. It's about Y.", "X wasn't Y - it was Z") in opener or closer position. State the cause and effect in normal order; let the reader supply the contrast.
+- [ ] 20. No cost-stacked tri-list openers ("$X-$Y in A, N B, one of M C"). Embed the costs in prose, drop the symmetric serial-list shape, or reduce to the one or two costs that drive the reader's decision.
+- [ ] 21. No cute aphoristic flourish closers ("polite noise", "the helpful answer is the trap", "Everything else is your mom being nice"). State the concrete mechanic instead.
+- [ ] 22. Opener-shape rotation: no 3+ consecutive chapters in a module may open with the same template shape (anonymous-founder vignette, year-stamp cohort, named-research-result, etc.). Vary between vignette, direct-instruction, research-result, and reader-question openers.
+- [ ] 23. Banned-pattern regression sweep: before handback, run `grep -rn "## Why this matters\|Founders who\|Most founders\|Founders we worked with"` across edited chapters; banned patterns previously removed are at high risk during any revision pass.
+
+### 🧑‍🔬 Cold-eyes panel agent mapping (BLOCKING - use specialized agents, not general-purpose)
+
+When dispatching the 4-persona cold-eyes critic panel (per CLAUDE.md content cold-eyes review gate), the agents MUST be:
+
+| Persona | Specialized agent | Why |
+|---|---|---|
+| AI-feel / shape-tell detector | `voltagent-biz:content-marketer` | Content strategy + native slop-pattern detection |
+| Voice guide enforcer | `voltagent-biz:technical-writer` | Documentation voice/tone enforcement |
+| ICP reader (Sam) | `voltagent-biz:ux-researcher` | Persona-based UX research; purpose-built for "does this work for this reader?" |
+| Cold-eyes pedagogical fresh reader | `tutorial-engineer` | Pedagogical evaluation - "does this teach a fresh learner?" |
+
+Defaulting to `general-purpose` for this panel is a process failure (caught 2026-05-23 on the Module 2 panel - the writer had memory `feedback_agent_selection_bias` and ignored it). The findings will still surface, but specialized agents bring their domain prompts, references, and quality bars without the dispatcher having to inline them.
+
+### ✂️ Surgical-edit gate (when REVISING an existing chapter)
+
+- [ ] Changed ONLY the sentences containing the attribute the user named; did not rewrite/rebalance the surrounding page.
+- [ ] Named the page's thesis in one line first; confirmed it is unchanged after the edit.
+- [ ] Grepped my own replacement text for the pattern I was removing (year-stamp, tool name, em-dash, alias, rescue framing) - did not re-introduce it.
+- [ ] On a rename: removed old refs + updated display labels (not just URLs); added NO alias bridge for a brand-new URL.
+- [ ] On a stance correction: landed at the documented middle, did not swing to the opposite extreme.
+
+### 👓 ICP-reader read-back gate (read the edited chapter AS "Sam", before handback)
+
+- [ ] 1. Every acronym/tool/term glossed at FIRST mention, in plain words.
+- [ ] 2. Orientation blocks (Module banner, summaries) ORIENT only - no thresholds/metrics/mechanics front-loaded.
+- [ ] 3. Tone is value-first, not sales/rescue/trauma. Reader is pre-spend Sam, not burned Alex.
+- [ ] 4. Visual rhythm: no two adjacent same-form callouts (e.g. two stacked blockquotes).
+- [ ] 5. No inherited element (routing block, disclaimer, callout) preserved unquestioned.
+- [ ] 6. Dollar/scale anchors relatable to Sam (lead with $500-scale; a big worst-case is fine as a ceiling, not the lead).
+
+> Mirror of the agent-side memory `feedback_minimal_edit_scope_no_page_bombing` and `feedback_icp_reader_readback_progressive_disclosure`, and the BLOCKING rules in project `CLAUDE.md`. Keep all three in sync if any changes.
+
+---
+
+## 🚦 Three outcomes
+
+After running all gates:
+
+1. **All gates pass** → mark task complete in TASK-TRACKER → run cover-image generation (per `sprint-1/cover-image-specs.md`) → commit → queue next sprint task.
+
+2. **1-2 gates fail (easy fixes)** → surface specific failures to user with the exact line numbers + suggested fixes. Don't auto-fix; let user decide. Do not mark complete.
+
+3. **3+ gates fail OR a "zero tolerance" gate fails (JT CTA / em-dash / banned word / React/Node/Java leak)** → surface to user with full failure list. Recommend re-spawning the writer with a stricter brief. Do not mark complete. Halt sprint.
+
+---
+
+## 🔁 If review fails twice on the same draft
+
+Halt the sprint. Surface to user with:
+- The failure pattern (which gates the agent keeps missing)
+- The agent's report-back text
+- A diagnosis: is the brief unclear, the agent confused, or the doctrine impossible to apply?
+
+The WIP=1 sequential rule means a stuck task blocks the rest of the sprint. Better to escalate than to keep re-spawning the same agent against the same brief.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/sprint-1/artifact-specs.md b/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/sprint-1/artifact-specs.md
new file mode 100644
index 000000000..314e987d7
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/sprint-1/artifact-specs.md
@@ -0,0 +1,171 @@
+# Sprint 1 Artifact Specs
+
+**Purpose**: format + content gates for the 3 Sprint 1 artifacts. A writer agent producing these reads this file once and produces a consistent deliverable without re-deriving structure.
+
+**Sister format reference**: every artifact mirrors the structure of the 5 shipped lead magnets in `../lead-magnets/`. Read at least `friday-demo-template.md` and `ownership-checklist.md` before drafting.
+
+---
+
+## Common structure (mandatory for all 3 artifacts)
+
+Every artifact MD file follows this skeleton:
+
+```markdown
+# [Title - clear, concrete, action-oriented]
+
+[One-line subhead in italic - explains what the founder does with it.]
+
+[Optional 1-paragraph "Why this exists" - one anonymized incident showing the cost of NOT having this artifact. Distinct from the 5 sister-artifact anecdotes (62K MVP / 180K B2B / 95K marketplace / 34K AI agency / 78K SaaS milestone).]
+
+## How to use this
+
+[≤120 words. When to run it (Friday afternoon, alone, in 30 minutes). What to bring. What you should DO with what you produce.]
+
+## The [thing] - copy and paste / fill in
+
+[The actual template / script / checklist. Copy-pasteable Slack/email block when appropriate. Numbered or table format.]
+
+## What good looks like vs what bad looks like
+
+[2-3 bad/good pairs with named technical evidence. Show how a failing answer looks vs a passing answer.]
+
+## What to do after
+
+[3 bullets max. The actions the founder takes after filling in the artifact.]
+
+---
+
+Built by JetThoughts as part of the free Tech for Non-Technical Founders 2026 curriculum. See the full curriculum at [/blog/tech-for-non-technical-founders-2026/](/blog/tech-for-non-technical-founders-2026/).
+```
+
+**Mandatory rules (apply to all 3)**:
+- Plain English, founder-to-founder voice.
+- No em dashes (`-` only).
+- No banned words (leverage, unlock, harness, supercharge, robust, seamless, empower, streamline, delve, embark, revolutionize).
+- No emoji in body.
+- ≥1 internal link to an existing JT blog post (verified with `ls content/blog//index.md`).
+- 1 link to the curriculum landing page at footer.
+- 1 anonymized practitioner anecdote (distinct from the 5 lead-magnet anecdotes already in the corpus).
+- Authorship credit footer as above.
+- Length: not a target; the cut test per section determines what stays.
+
+---
+
+## Artifact 1 — Self-Assessment Worksheet *(Sprint 1.1, Module 0)*
+
+**Path**: `docs/projects/2605-tech-for-non-technical-founders/50-59-execution/lead-magnets/self-assessment-worksheet.md`
+
+**Purpose**: A 5-minute checkbox quiz that routes the reader to their starting module in the 8-module course. Reader prints it, fills it in alone, writes their starting module at the top of a Notion doc.
+
+**Required content**:
+
+1. **Title**: "Where Are You in the Founder Journey? The 10-Question Self-Assessment"
+2. **Subhead**: "Five minutes alone with a checklist tells you which module to start with."
+3. **Why this exists**: distinct anecdote — three founders who all said "help my team ship" but actually needed three different modules. (See `SPRINT-RUNBOOK.md` §S1.1 for the example phrasing.)
+4. **How to use it**: 5 minutes, alone, before coffee. Bring a pen. Mark each question Y/N or with the multiple-choice answer. Write your routing result on top of a fresh Notion doc.
+5. **The 10 questions (verbatim from `20.01-course-modules.md` §"The 10 self-assessment questions + routing logic")**:
+   - Each question gets: checkbox · question text · routing line ("No → Module 1. Yes → Q2.")
+   - Use a markdown table for the 10-question block.
+6. **The routing summary**: 2-3 sentences summarizing which question types route where. Visual reference: a Mermaid flowchart in markdown showing the question paths feeding into Module 1/2/3/4A/4B/5/6/7.
+7. **What good looks like vs what bad looks like**: 2 pairs.
+   - Q1 good vs bad: "I talked to 10 people who all have this problem" vs "I asked 3 friends who said it sounds cool"
+   - Q5 good vs bad: "I own the GitHub org under my email" vs "My contractor created the GitHub org under his Gmail"
+8. **What to do after**: 3 bullets.
+   - Write your starting module + the next deliverable you'll produce at the top of your Notion doc
+   - Read that module's first post tonight
+   - Re-take this quiz in 60 days to confirm you progressed
+
+**Length expectation**: 800-1400 words is typical for this artifact type; the cut test rules.
+
+---
+
+## Artifact 2 — Outreach Sequence Template *(Sprint 1.2, Module 1.1)*
+
+**Path**: `docs/projects/2605-tech-for-non-technical-founders/50-59-execution/lead-magnets/outreach-sequence-template.md`
+
+**Purpose**: The 2026 stack for finding + booking 10 ICP interviewees in one morning. Reader downloads, copies the outreach sequence, runs it Monday morning, has 10 calls in their calendar by Friday.
+
+**Required content**:
+
+1. **Title**: "Find 10 People With the Problem — The 2026 Outreach Sequence Template"
+2. **Subhead**: "Reddit + LinkedIn + Clay + Lindy + paid panels = 10 interviewees by Friday."
+3. **Why this exists**: distinct anecdote — a founder who tried "I'll just ask my LinkedIn network" (got 3 polite no's), pivoted to the 2026 stack, booked 12 calls in 4 days.
+4. **How to use it**: Run this Monday morning. Budget: 4 hours + $200-$500 in tools/panels. Outcome: 10 booked calls by Friday.
+5. **The sequence (5 steps; the artifact's main body)**:
+   - **Step 1 — Mine where they're already complaining** (Reddit subreddits + LinkedIn searches + Discord servers; concrete subreddit names per ICP type)
+   - **Step 2 — Build the ICP list** (Clay $149/mo or Apollo $49-$149/mo; 50-100 contacts; criteria checklist)
+   - **Step 3 — Run the sequence** (Smartlead or Instantly $37-$94/mo + Lindy AI agent for sequence + calendar booking; sample 3-email sequence with subject lines)
+   - **Step 4 — Backup via paid panels** (User Interviews $50-$150/interviewee; Respondent for B2B; when to use)
+   - **Step 5 — The parallel smoke-test landing page** (Carrd/Framer + £100-200 paid traffic; conversion-rate signal)
+6. **Copy-pasteable templates inline**:
+   - 3 sample LinkedIn DM openers
+   - 3 sample cold email subject lines
+   - 1 sample Reddit "I'm researching X" comment
+   - 1 sample Calendly booking page copy
+7. **What good looks like vs what bad looks like**: 2 pairs.
+   - Good DM: specific, references their public post, asks for 20 min on a specific problem
+   - Bad DM: generic "love to pick your brain about your industry"
+8. **What to do after**:
+   - Score the responses: aim 30%+ accept rate by Wednesday
+   - If <10% accept: rewrite the opener with sharper specificity
+   - Move to the Mom Test artifact for the actual interview script
+
+**Internal links**: at least one to an existing JT post on B2B outreach or founder communication.
+
+**Length expectation**: 1200-1800 words is typical.
+
+---
+
+## Artifact 3 — Mom Test Interview Script *(Sprint 1.3, Module 1.2)*
+
+**Path**: `docs/projects/2605-tech-for-non-technical-founders/50-59-execution/lead-magnets/mom-test-interview-script.md`
+
+**Purpose**: The 5-question script that prevents polite-yes answers. Reader keeps it open on a second screen during interview, asks exactly these questions, gets honest past-behavior data instead of hypothetical agreement.
+
+**Required content**:
+
+1. **Title**: "The Mom Test Interview Script — Ask About the Past, Not the Future"
+2. **Subhead**: "Five questions that get the interviewee to tell you what they actually did, not what sounds polite."
+3. **Why this exists**: distinct anecdote — a founder who got 8 enthusiastic "yes I'd pay for that" responses, launched, and 0 people actually paid. Rob Fitzpatrick's framework (book: *The Mom Test*, 2013) referenced as the technique, but NOT named in the headline.
+4. **How to use it**: Open the script on a second screen during the call. Read questions as written. Listen for emotional language (frustration, hack, workaround). Take notes by hand. Score 1-10 at the end.
+5. **The 5 questions (the artifact's main body)**:
+   - **Q1: "Tell me about the last time [problem context happened]. Walk me through what you did."** — anchors in past behavior, not hypothetical.
+   - **Q2: "What did that cost you — in time, money, or sanity?"** — quantifies the pain.
+   - **Q3: "What have you tried already to fix this?"** — surfaces existing workarounds and what didn't work.
+   - **Q4: "On a scale of 1-10, how big a problem is this for you compared to everything else on your plate?"** — calibrates urgency.
+   - **Q5: "Who else on your team feels this? How do they handle it?"** — surfaces the buying committee + alternative solutions.
+   For each question: copy-pasteable phrasing + 1 follow-up + Pass / Fail signals + what good vs bad answer looks like.
+6. **The 3 emotional-language flags** to listen for (frustration / workaround language / urgency expressions).
+7. **What good looks like vs what bad looks like**: 2-3 pairs.
+   - Good Q1 answer: "Last Tuesday at 9pm I spent 40 minutes copying numbers from 3 spreadsheets into a deck for the board. I called my CFO and she did it for me."
+   - Bad Q1 answer: "Yeah, I usually struggle with reporting."
+8. **What to do after**:
+   - Score each interview 1-10 on the pain intensity (Q4 + emotional language flags)
+   - If 7+ scores in 10 interviews, the problem is validated. Move to the Validated Problem Statement (Module 1.3).
+   - If <5 scores in 10 interviews, the problem isn't strong enough. Re-evaluate; consider pivoting.
+
+**Internal links**: at least one to a JT post on customer research / founder discovery, plus one to the upcoming Module 1.3 post (forward link).
+
+**Length expectation**: 1200-1800 words.
+
+---
+
+## Distinct anecdote anchors (avoid duplicating)
+
+Already used in the corpus:
+- $62K MVP / Stripe behind feature flag (Friday demo template)
+- $180K B2B fintech / GitHub org locked (ownership checklist)
+- $95K marketplace / 38K LOC Rails (salvage decision tree)
+- $34K AI agency / secrets in database.yml (AI 5-questions)
+- $78K SaaS / 4-of-5 milestones on broken staging (SOW reading guide)
+- $51K refactoring / 14 months nodding (Five Tech Words post)
+- $44K/month team-of-4 (Org Chart post)
+- $25K/month, 47 standups (Three Questions post)
+
+Sprint 1 artifacts must introduce 3 NEW anecdotes. Avoid the dollar anchors above. Avoid the technical mechanisms above (no more "GitHub org locked," no more "database.yml secrets," no more "feature flag broken").
+
+Suggested fresh anchor angles (pick any, vary):
+- A founder who paid $1,500 for a Survey Monkey "validation" that taught her nothing
+- A solo founder who DM'd 47 Twitter strangers and got 12 honest no's
+- An ex-PM who spent 6 weeks on Reddit r/SaaS reading posts before writing one comment
+- A founder who used UserInterviews + paid $1,200 for 8 interviews + closed her first 3 customers from the interview pool
diff --git a/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/sprint-1/cover-image-specs.md b/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/sprint-1/cover-image-specs.md
new file mode 100644
index 000000000..1d797b356
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/50-59-execution/sprint-1/cover-image-specs.md
@@ -0,0 +1,85 @@
+# Sprint 1 Cover Image Specs
+
+**Purpose**: define the Stitch HTML cover-image specs for the 3 Sprint 1 posts. Each post's cover.png renders from a 6-slot HTML template per `.stitch/design.md`. This file gives the writer / cover-image-generator agent the exact slot fills.
+
+**Design system reference**: `.stitch/design.md` (JetVelocity — obsidian dark, Ruby red #cc342d, neon purple #a855f7).
+
+**Workflow**: write the HTML at `.stitch/designs/-cover.html` → render via chrome-devtools (2400×1260 viewport) → downsample to `content/blog//cover.png` via ImageMagick.
+
+---
+
+## Cover 1 — Module 0.1 Course Map + Self-Assessment
+
+**Slug**: `course-map-self-assessment-non-technical-founder-2026`
+**HTML path**: `.stitch/designs/course-map-self-assessment-cover.html`
+**Final PNG**: `content/blog/course-map-self-assessment-non-technical-founder-2026/cover.png`
+
+**Slot fills**:
+
+| Slot | Content |
+|---|---|
+| Title (large, top-left) | Where Are You / In the Founder / Journey? |
+| Subtitle | 10 questions · 5 minutes · routes you to your starting module |
+| Category badge | Course Map · Free |
+| Visual centerpiece | Stylized flowchart/decision-tree visual with 8 module boxes on right; Q1-Q10 cluster on left with arrows feeding into module boxes. Obsidian dark background. Ruby-red arrows on the YES paths, neon-purple on NO paths. |
+| Chips (3 floating) | "8 modules" / "Free" / "5-minute self-assessment" |
+| Status indicator | Course Entry Point |
+
+**Voice**: course-onboarding, not aggressive. The cover signals "this is where you start," not "BUY THIS COURSE."
+
+---
+
+## Cover 2 — Module 1.1 Find 10 People With the Problem
+
+**Slug**: `find-10-people-with-problem-outreach-2026`
+**HTML path**: `.stitch/designs/find-10-people-outreach-cover.html`
+**Final PNG**: `content/blog/find-10-people-with-problem-outreach-2026/cover.png`
+
+**Slot fills**:
+
+| Slot | Content |
+|---|---|
+| Title | Find 10 People / With the Problem / in 2026 |
+| Subtitle | Reddit + Clay + Lindy + paid panels = 10 interviewees by Friday |
+| Category badge | Module 1 · Validate |
+| Visual centerpiece | A weekly calendar visual showing 5 days (Mon-Fri) with calendar slots filling in: Mon empty / Tue 2 slots / Wed 5 slots / Thu 8 slots / Fri 10 slots. Each slot a small avatar circle. Ruby-red highlights on the slots booked via paid panels; neon-purple on Reddit-sourced. |
+| Chips | "Clay · $149/mo" / "Lindy AI agent" / "10 calls by Friday" |
+| Status indicator | Sprint 1 / Module 1 |
+
+**Voice**: practical-tactics. The cover signals "this teaches the actual booking sequence."
+
+---
+
+## Cover 3 — Module 1.2 The Mom Test
+
+**Slug**: `mom-test-ask-about-past-not-future`
+**HTML path**: `.stitch/designs/mom-test-cover.html`
+**Final PNG**: `content/blog/mom-test-ask-about-past-not-future/cover.png`
+
+**Slot fills**:
+
+| Slot | Content |
+|---|---|
+| Title | The Mom Test: / Ask About the Past, / Not the Future |
+| Subtitle | 5 questions that stop your interviewees from being polite |
+| Category badge | Module 1 · Validate |
+| Visual centerpiece | A speech-bubble visual: two side-by-side bubbles. Left bubble (ruby-red border, "BAD"): "Yeah, I'd totally pay for that!" Right bubble (forest-green border, "GOOD"): "Last Tuesday at 9pm I spent 40 minutes copying spreadsheets..." Arrow between them labeled "the Mom Test." |
+| Chips | "5 questions" / "Past behavior > hypothetical" / "Score 1-10" |
+| Status indicator | Sprint 1 / Module 1 |
+
+**Voice**: contrarian-tactical. The cover signals "this prevents the lying-by-politeness trap."
+
+---
+
+## Generation order
+
+After each Sprint 1 post is drafted + reviewed, the cover-image step runs as the LAST gate before publish:
+
+1. Read this file for the slot fills.
+2. Write the HTML at `.stitch/designs/-cover.html` using the existing `.stitch/designs/reading-sow-clause-by-clause-cover.html` as a structural template (it's the most recent shipped cover).
+3. Render with chrome-devtools at 2400×1260 viewport.
+4. Downsample via ImageMagick to standard cover dimensions.
+5. Save to the post's bundle directory as `cover.png`.
+6. Confirm frontmatter references match: `cover_image: cover.png` + `metatags.image: cover.png`.
+
+If the cover-image-generator agent finds it cannot render (chrome-devtools unavailable, etc.), it surfaces to the user. The cover is NOT mandatory for first draft delivery — the agent can ship the markdown without the cover, and the cover renders in a separate downstream step.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/GOAL-AT-A-GLANCE.md b/docs/projects/2605-tech-for-non-technical-founders/GOAL-AT-A-GLANCE.md
new file mode 100644
index 000000000..97511a59d
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/GOAL-AT-A-GLANCE.md
@@ -0,0 +1,167 @@
+# Tech for Non-Technical Founders 2026 — Goal At-A-Glance
+
+**ONE-PAGE EXECUTIVE SUMMARY** for agents and stakeholders.
+
+**Project ID**: 2605-tech-for-non-technical-founders
+**Created**: 2026-05-12
+**Last restructured**: 2026-06-10 (Stale-doc cleanup: /blog/ → /course/ path fix, ICP clarified to Sam, chapter count updated, v2 inventory added)
+**Status**: 🟢 v1 (long-form course) shipped · 🔄 v2 pilot lessons iterating to ideal · 🔲 Phase 2 gated behind pilot perfection
+**Owner**: JT content team
+**Parent**: 2510-seo-content-strategy (extends, does not replace)
+
+---
+
+## 🔀 STRATEGIC PIVOT (2026-06-07) — READ FIRST
+
+**v1 status**: Long-form course shipped end-to-end (5 modules · 18 chapters · 15 artifacts · 22+ iterations of Sam-loop polish). Live and functional.
+
+**The problem with v1**: 40.08 gap report scored all 21 chapters against the canonical 8-part micro-lesson template (30.03 spec). **0 of 21 chapters score above 2/8.** The format is wrong for Sam — long-form chapters (2,000-4,500 words each) violate the micro-learning research (Cathy Moore's Action Mapping, Carroll's Minimalist Instruction, Fogg's B=MAP, NN/g F-pattern). The 16 iterations of surgical polish caught real defects but cannot fix the structural format gap.
+
+**v2 direction**: 20-25 micro-lessons (400-600 words each, 5-10 min read + 5-15 min do). Per-lesson 8-part template (Hook → Outcome → Concept → Visual → Do-Now → Error Recovery → Reflection → Bridge). Same 6 artifacts, same emotional arc — radical compression, not scope reduction. See `30-39-architecture-design/30.03-course-format-requirements-for-creators.md` for the canonical spec.
+
+**Migration plan (see `TASK-TRACKER.md` "Course Migration Schedule")**:
+- ✅ **Phase 0 / Option C** (shipped 2026-06-07): Quickstart + FAQ + "What not to learn" + 6 Sam recommendations from 40.07
+- 🔄 **Phase 1** (iterating 2026-06-08+): 2 pilot lessons (1.2a, 1.2b) being iterated to ideal quality. Strategy: pilot-first, then scale. Phase 2 gated behind: (1) both pilots pass all 6 Sam-review tests, (2) 5-Sam real-founder validation confirms template, (3) 30.03 §7 QA passes, (4) iteration refinements documented.
+- 🔲 **Phase 2** (2-4 weeks, gated): Module-by-module full migration (M1 → M2 → M3 → M4 → M5)
+- 🔲 **Phase 3** (cross-cutting polish, gated): bridges + reflection + visual discipline + viral loop
+
+**What we stopped**: Iter 17+ surgical loop on v1 long-form chapters. Each Iter-N round was catching diminishing-return defects. The structural format gap is solved by migration, not by line edits.
+
+**For cold AI agents picking up the work**: Start at PROJECT-INDEX.md → "For a micro-lesson migration agent" route. The 30.03 spec is the canonical authority on lesson structure. The 40.09 QA report shows the 8-part template applied correctly to the Mom Test 3-lesson sample.
+
+---
+
+## 🎯 THE GOAL (30-second summary)
+
+Publish a **free 5-module course that takes a non-technical founder from idea to first paying customer** in the most effective way for 2026 — and lets them run the whole thing on **$0 budget** if they want. The course is structured as **5 modules with input → output → checkpoint → artifact per module**. The reader compiles a personal "Founder OS" by working through the modules.
+
+**Course promise**: From idea to first paying customer in the most effective way for 2026. You walk away with: validated hypothesis, live smoke-test landing page, signed validated problem statement, Product Brief, build decision, live MVP (self-serve or hired), **and one signed paid pilot**.
+
+**Course philosophy**: Don't hire engineers if you don't have to. If you must hire, hire surgically. Don't ship more product before someone pays. The course teaches the SIMPLEST method that works for solo non-tech founders and presents free and paid tool options as equal choices the reader picks based on situation (see Delivery Principles below). Tool spend is bounded and channel-dependent (the smoke-test ad budget, for example, ranges from $300-$600 on Meta to $1,800-$6,600 on LinkedIn for the same 300-visit floor) - not a single global anchor. Structured frameworks (Foundation Sprint, JTBD Canvas, Shape Up, Impact Mapping) are demoted to optional "Advanced" sidebars.
+
+**Positioning sentence**: A free competing curriculum to YC Startup School (free), Sophia Matveeva's Tech for Non-Technical Founders ($2,500-$3,500 one-time, verified 2026-05-22), Drew Falkman's Vibe Coding (~$1,000 Maven cohort, price gated/unverified), and the Kukoyi 2017 book — the only one that maps the full 5-module journey (form hypothesis + smoke-test → validate problem → write product brief → choose and run the build → close first paid pilot) without selling itself. Sequence matches Click's Foundation Sprint (lightweight Experiment before heavier Design Sprint prototype), Steve Blank Customer Development (Discovery before Validation), and the Mom Test (interviews-first for deep validation).
+
+**JT positioning** (Option C: Pure Lead Magnet, no selling): the course does NOT pitch JT services. Zero "book a Control Audit" CTAs, zero "schedule a consultation," zero service offers. Authorship credit stays at the footer ("Built by JetThoughts as part of the free curriculum"). Lead capture works via email-gated artifact downloads only. See `feedback_curriculum_is_pure_lead_magnet.md`.
+
+**Engineered for viral sharing (v1 long-form posts):** every post needs a contrarian hook, a quote-tweetable insight (140-280 chars), a specific tactic the reader can use this week, and a free downloadable artifact. See `feedback_curriculum_viral_shareability.md`. **v2 micro-lessons** follow 30.03 §2 template (1 visual max, 400-600w bands).
+
+---
+
+## 📊 KEY METRICS DASHBOARD
+
+Success metric: **share velocity + email captures + page-1 SEO** — NOT consultation bookings (course is a pure lead magnet, no service CTAs).
+
+| Metric | Baseline | 6-Month Target | Source of Truth |
+|---|---|---|---|
+| Course chapters published | 18 v1 + 2 v2 pilot live | 20-25 v2 micro-lessons + companion pages | `data/course_sequence.yaml` |
+| Course landing page | live | optimized for Sam-first fast path | hugo build |
+| Page-1 rankings on course keywords | 0 | 8+ across founder-focused keywords | GSC |
+| Email captures from artifact downloads | 0 | 500+ across 7 honest artifacts | site analytics |
+| Reddit / Twitter / Facebook shares per post | 0 | ≥25 shares per post within 30 days of publish | manual + Buffer/social tracking |
+| Course completion signal (readers who hit ≥3 modules) | 0 | measurable via path tracking | analytics |
+
+**Quality gates (non-negotiable)**: every post passes the JT voice rules (90.11), the multi-persona review, the slop detector ≤25/100, the shape-tell critic, the cold-eyes final pass. Every post carries the course frame (module callout + bottom course-nav). Every post includes ≥3 handmade-style infographics. Zero word-count caps; cut test per section. Tech examples default to Rails/Django/Laravel + full-stack pattern. **Zero JT service CTAs.** **Every post has a contrarian hook + one quote-tweetable insight + a specific weekly tactic + a downloadable artifact.**
+
+---
+
+## 🛣️ THE 5 MODULES (current spine)
+
+Each module has an **input** (what the reader brings from the previous module), an **output** (the deliverable they walk away with), a **checkpoint** (signal they can move on), and an **artifact** (template/worksheet they fill in). Source of truth: `data/course_sequence.yaml` with `goal:` field per chapter.
+
+| # | Module | Output you walk away with | Chapters |
+|---|---|---|---|
+| 1 | **Hypothesis & Smoke Test** | One-sentence Founding Hypothesis + live landing page with Stripe price button. $0 path: Carrd/Neeto free + organic share. | 3 |
+| 2 | **Validate the Problem** | 10 Mom Test interview transcripts + signed validated problem statement + 2-hour clickable prototype shown to 5 subjects. | 4 |
+| 3 | **Product Brief** | One-page Vibe PRD ready to hand to Lovable or a hired junior. Outcome-shaped, not feature-shaped. | 2 |
+| 4 | **Choose Your Build** | Build decision (self-serve or hire) + Day-1 ownership audit + live MVP at staging URL (Lovable + Supabase + Stripe under $50/mo). | 4 |
+| 5 | **First Paying Customer** | First signed paid pilot ($500 Stripe deposit) + repeatable outbound machine. Free-tier tool stack. | 5 |
+
+**Total: 1 overview (Chapter 0) + 18 v1 long-form chapters + 2 v2 pilot micro-lessons + 1 glossary** ("Five Tech Words to Stop Nodding At"). Start at [How This Course Works](/course/tech-for-non-technical-founders-2026/how-this-course-works/) for the full route at a glance: 5-module flow, AI tool stack, SIPOC system map, and module gates.
+
+### 📦 Current Inventory (canonical count)
+
+| Category | Count | Source of truth |
+|---|---|---|
+| Linear course chapters (v1) | 18 | `data/course_sequence.yaml` (excl. Ch 0 + glossary) |
+| Chapter 0 (overview) | 1 | `content/course/.../how-this-course-works/` |
+| Glossary | 1 | `content/course/.../five-tech-words-stop-nodding-at/` |
+| v2 pilot micro-lessons live | 2 | `smoke-test-build-page/` + `smoke-test-wire-tracking/` |
+| Companion/supplementary pages | ~30 | Not in linear sequence; linked from Module 5 gate |
+| Content directory entries (total) | 56 | `ls content/course/tech-for-non-technical-founders-2026/` |
+| Artifacts/templates | 15 | Vibe PRD, Friday Demo, Ownership Checklist, SOW Guide, etc. |
+| SVG illustrations | ~15+ | Per-lesson visual micro-aids |
+| Cover images (spine, "Curriculum 2026" badge) | 14 | 2400×1260 Stitch-generated |
+| Cover images (companion, "Curriculum NN/30" stale) | ~30 | P3 regen tracked in TASK-TRACKER |
+| Validation gates | 4 | `bin/validate-course` (chapter-number, title-yaml, internal-links, table-width). 3/4 pass. |
+| Project docs (active) | 31 | `docs/projects/2605-tech-for-non-technical-founders/` (excl. 11 archived) |
+| PM health report | 1 | `40-49-review/40.10-senior-pm-health-report-2026-06.md` |
+
+**Going further (after Module 5 gate)**: continuation chapters for churn triage, pivot or persevere, hire-track supplementary reference, management chapters (Friday Demo Rule, Weekly Dev Report, etc.), and AI-era chapters (Agency AI Questions, Token Bill, Slopsquatting). These are NOT in the linear sequence.
+
+**Sequence rationale** (decided 2026-05-20): Module 1 packages Hypothesis + Smoke-Test together because Click's Foundation Sprint produces both as one output ("a clear hypothesis you can validate" via lightweight experiment). The smoke-test landing page is a positioning artifact + price test (free on Neeto/Carrd), not a paid-ads demand gate. Deeper Customer Discovery (interviews) happens in Module 2 with the landing page as the conversation opener. Sequence matches Click → Steve Blank Customer Development → Mom Test. See `20-29-strategy/20.10-sequence-decision-validate-vs-smoke-test.md`.
+
+---
+
+## 💡 DELIVERY PRINCIPLES
+
+- **Effectiveness first; free and paid presented as equal options.** For each step, show both a free path and a paid path and let the reader choose what fits their situation - never prioritize free over paid (cheap) or push paid over free (greedy). Most readers have some budget; the goal is the most effective route to the outcome, not the cheapest one. Don't over-weight the money dimension - it's one input the reader decides on, not the theme of the chapter.
+- **Simplest method on main path.** Foundation Sprint, JTBD Canvas, Shape Up, Continuous Discovery, Impact Mapping, Empathy Mapping, Design Sprint all relegated to optional "Advanced" sidebars.
+- **Course is a journey, not a topic list.** Every module's chapters share input/output/checkpoint/artifact framing. The artifacts compile into the reader's Founder OS.
+- **Engagement-first delivery (v1 long-form).** No word-count caps; cut test per section determines what stays. **v2 micro-lessons** follow 30.03 §1.6 word count bands (400-600w standard, 500-900w tool).
+- **≥3 handmade-style infographics per v1 post** (Excalidraw aesthetic, Mermaid + SVG mix). **v2 micro-lessons cap at 1 visual per lesson** (30.03 §2.4, cognitive load theory).
+- **Tech stack defaults to Rails / Django / Laravel + full-stack-developer-ships-end-to-end pattern** in examples. No React/Node/Java as the lead example stack.
+- **Course frame in every post**: top callout (Module X · Step N of M) + bottom course-nav table.
+- **Zero parallel slugs to 2510 plan.** Curriculum framing added via callout, not by creating duplicates.
+
+---
+
+## 🚀 EXECUTION STATUS
+
+### ✅ Shipped (as of 2026-05-20)
+- 18 v1 long-form chapters across 5 modules (see `data/course_sequence.yaml`) + 2 v2 pilot micro-lessons (1.2a, 1.2b) + 14+ companion/supplementary pages + Quickstart + FAQ + 'What not to learn'
+- Course landing page at `/course/tech-for-non-technical-founders-2026/`
+- 14 spine-chapter covers (Stitch-generated, "Curriculum 2026" badge, 2400×1260)
+- 15 artifacts / lead magnets (Vibe PRD Template, Friday Demo Template, Ownership Checklist, SOW Reading Guide, etc.)
+- Theme partial `course-prev-next.html` auto-renders nav from YAML
+- Course-chapter visibility filter excludes spine from `/blog/` index
+
+### 🔲 Open work (see TASK-TRACKER.md)
+- **P1**: Burned-founder fast path on landing page, Founder Control Dashboard artifact, downloadable PDF templates, companion-post FAQ collection, rescue-path routing audit
+- **P2**: Skip-to-action anchor links, burned-founder Module 2 callouts, TL;DR summaries, completion criteria per chapter, tighten practical proof
+- **P3**: Cover regen for ~30 companion posts, Wizard of Oz Concierge MVP, echo chamber warning (done in Ch 5.3), Loom outreach, Engineering as Marketing
+
+### Phase pipeline
+- LinkedIn promotion per post (Paul Keen voice) — ongoing
+- Course completion path tracking — pending analytics setup
+- Quarterly refresh sweep for AI-era posts — Q1 2027 first refresh
+
+---
+
+## ⚠️ TOP RISKS
+
+| Risk | Mitigation |
+|---|---|
+| Re-introducing complexity via "improvements" | Memory feedback `feedback_kiss_simplest_solutions_only.md` lives in every agent brief; Advanced frameworks stay in sidebars |
+| Spine drift after future restructures | P1: build 4 source-of-truth validators (chapter-number consistency, title-YAML byte match, internal-link existence, mobile-table width) per Kaizen Muda analysis |
+| 2510 LinkedIn validation sprint already in flight - schedule conflicts | The wrap posts ship per 2510 calendar; the 2605 curriculum framing is added retroactively. Zero schedule conflicts. |
+| AI-era posts (Going further) decay fast | Date-stamp every AI-era post + Q1 2027 refresh trigger |
+| ICP-E (burned founder) bouncing on validation curriculum when they need rescue | Routed at the entry point: the landing page "If Your Team Is Already Failing" fast path sends burned readers to Ownership Audit / Friday Demo / Weekly Report / Salvage-Rebuild before any validation work. Chapter bodies are written to the primary course ICP (Sam, first-timer); the per-chapter routing block on Ch 1.1 was removed 2026-05-22 (it taxed the primary reader and duplicated the landing-page router). **Alex (burned founder) is the website lead-gen ICP (90.10), NOT the course design target (40.06 Sam).** |
+
+---
+
+## 🔗 NAVIGATION
+
+- **PM health report (canonical inventory + RAG dashboard)**: `40-49-review/40.10-senior-pm-health-report-2026-06.md`
+- **Source of truth (chapter order + goals)**: `../../data/course_sequence.yaml`
+- **Research**: `10-19-research/10.01-course-program-landscape.md` + `10.02-curriculum-sequence-synthesis.md` + `10.08-validation-tools-analysis-2026.md`
+- **Reviews**: `40-49-review/40.03-sipoc-course-logic.md` (canonical SIPOC) + `40-49-review/40.04-execution-readiness-sweep-2026-06.md` + `40-49-review/40.05-multi-perspective-icp-review-2026-06.md` + `40-49-review/40.06-sam-customer-journey-report-2026-06.md` + `40-49-review/40.07-sam-experience-improvement-report-2026-06.md`
+- **Course format spec (creators)**: `30-39-architecture-design/30.03-course-format-requirements-for-creators.md` — canonical micro-learning requirements, lesson template, gap analysis, migration guide
+- **Strategy**: `20-29-strategy/20.01-course-modules.md` + `20.02-positioning-vs-courses.md` + `20.10-sequence-decision-validate-vs-smoke-test.md`
+- **Open work**: `TASK-TRACKER.md` (single source of truth for all active tasks)
+- **Low-impact ideas**: `LOW-IMPACT-IDEAS-BANK.md` (deferred, dropped, and P3 ideas)
+- **External research**: `../../docs/_research/` (Russian-language market research)
+- **Voice**: `../../90-99-content-strategy/strategy-analysis/90.11-voice-guide.md`
+- **ICP (course design target):** Sam (first-timer non-technical founder, no burn history, no PM background). Definitive doc: `40-49-review/40.06-sam-customer-journey-report-2026-06.md`.
+- **ICP (website lead-gen):** Alex (burned founder). Defined in `../../90-99-content-strategy/strategy-analysis/90.10-icp-primary-website-target.md`. NOT the course design target.
+
+> **Note**: The parent content plan (`2510-seo-content-strategy/20-29-strategy/20.07-content-plan-icp-e-q2-2026.md`) is the site-level SEO calendar. The course shipped independently on its own timeline and does not depend on that plan. The archived `_ARCHIVED_20.07-content-plan-tnt-founders-2026.md` was a 26-post site-level content draft, not a course plan.
diff --git a/docs/projects/2605-tech-for-non-technical-founders/LOW-IMPACT-IDEAS-BANK.md b/docs/projects/2605-tech-for-non-technical-founders/LOW-IMPACT-IDEAS-BANK.md
new file mode 100644
index 000000000..53da2f49f
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/LOW-IMPACT-IDEAS-BANK.md
@@ -0,0 +1,94 @@
+# Low-Impact Ideas Bank — 2605 Tech for Non-Technical Founders
+
+**Created**: 2026-06-04 (post-consolidation)
+**Last Updated**: 2026-06-05 (post-validation-tools re-research — 17 items applied, 8 deferred/skipped)
+**Purpose**: Collect all dropped, deferred, P3, and low-priority ideas that have been mentioned across reviews, research, and feedback but aren't actively tracked in TASK-TRACKER.md. This prevents ideas from being lost and gives future agents a single place to find them.
+
+**How to use**: When starting a new work cycle, scan this bank for ideas that have become relevant due to new context, user direction, or data.
+
+---
+
+## Applied (moved to course chapters)
+
+| Idea | Where Applied | Date |
+|---|---|---|
+| IdeaProof ensemble validation (10.08) | Ch 2.2 — Advanced sidebar after AI critic block | 2026-06-04 |
+| Reddinbox/Pushshift Reddit mining (10.08) | Ch 2.3 — Monitoring tools variations section | 2026-06-04 |
+| Loom video audit tactic (10.08) | Ch 5.5 — Advanced personalization section | 2026-06-04 |
+| Engineering as Marketing channel (10.08) | Ch 5.2 — 5th channel option + callout | 2026-06-04 |
+| Echo chamber warning (10.08) | Ch 5.3 — Inline callout after opening paragraph | 2026-06-04 |
+| Wizard of Oz Concierge MVP (10.08) | Ch 4.3 — Callout before build instructions | 2026-06-04 |
+| ValidatorAI devil's advocate (10.08) | Ch 2.1 — Optional sidebar after technique section | 2026-06-04 |
+| OpinionX stack-ranking (10.08) | Ch 3.2 — Optional sidebar after rewrite section | 2026-06-04 |
+| WorthBuild lead-gen (10.08) | Ch 5.2 — Optional tool in AI critic block | 2026-06-04 |
+| Psychological barriers / free subdomain fear (RU research) | Ch 1.2 — Inline callout in Read the Numbers section | 2026-06-04 |
+| Burned-founder callout (40.05) | Ch 2.1 — Inline callout after module header | 2026-06-04 |
+| Skip-to-action anchor links (40.05) | Ch 1.1, 3.2, 4.3 — Inline skip links | 2026-06-04 |
+| Ch 5.5 premature reading gate (40.06) | Ch 5.5 — Stronger gate language after module header | 2026-06-04 |
+
+| Ch 4.3 split into two sub-pages (40.05) | Ch 4.3a (Tools & Setup) + Ch 4.3b (Build Phases) | 2026-06-04 |
+| VenturusAI strategic frameworks (10.08) | Ch 1.1 — Specialized alternatives sidebar (free, SWOT/PESTEL/Porter's Five Forces) | 2026-06-05 |
+| DimeADozen validation reports (10.08) | Ch 1.1 — Specialized alternatives sidebar ($9 Starter, 7-section brief) | 2026-06-05 |
+| Preuve AI data-backed validation (10.08) | Ch 1.1 — Specialized alternatives sidebar (free, 50+ live data sources) | 2026-06-05 |
+
+---
+
+## From Reviews (40-49) — Remaining
+
+### 40.04 Execution-Readiness Sweep
+- **Vendor pricing facts**: Annual refresh cadence (Lovable, Supabase, Stripe, etc.). Deferred — add to TASK-TRACKER when a refresh is due.
+- **Cross-post anchor regression**: When M2.1 synthesis anchor URL changes, update 6 downstream chapters in the same commit. Process note, not a task.
+- **Session-limit agent fanout pattern**: 25% of dispatched agents die mid-run. Process note, not a task.
+
+### 40.05 Multi-Perspective ICP Review
+- **Module 2 friction observations**: Ch 2.2 (AI Personas) reposition as optional sidebar. Deferred — structural change, revisit after reader data.
+- **Ch 2.4 silent-observation script emotional resistance**. Deferred — needs user testing data.
+- **Module 4.3 length**: ✅ Applied — split into Ch 4.3a (Tools & Setup) + Ch 4.3b (Build Phases).
+- **Module 5.2 channel worksheet**: ✅ Already applied — "Fast-path exit" callout exists inline in Ch 5.2 (skip-the-worksheet path for founders whose interviews already named a channel).
+
+### 40.06 Sam Customer Journey Report
+- **Mermaid diagram mobile rendering**: Static PNG fallbacks for mobile. Deferred — technical implementation needed.
+- **Template supplementary chapter risk**: "When you need this" timing guide for 9 linked templates. Deferred — structural change.
+
+---
+
+## From Research (10-19) — Remaining
+
+### 10.08 AI Validation Tools Analysis
+- **VenturusAI**: ✅ Applied — Ch 1.1 specialized alternatives sidebar (free tier, SWOT/PESTEL/Porter's Five Forces).
+- **DimeADozen**: ✅ Applied — Ch 1.1 specialized alternatives sidebar ($9 Starter report).
+- **Preuve AI**: ✅ Applied — Ch 1.1 specialized alternatives sidebar (free tier, 50+ live data sources with source linking).
+
+### From Russian-Language Research (`docs/_research/`)
+- **Build in Public**: Distribution channel via X/LinkedIn. Skip — requires founder personality fit, too niche.
+
+---
+
+## Dropped from TASK-TRACKER
+
+| Idea | Why Dropped | Context |
+|---|---|---|
+| Time-badge on every chapter header | Contradicts ADR §1 (no speculative effort estimates) | TASK-TRACKER 2026-06-02 |
+| Per-chapter routing blocks for burned founders | Duplicated landing-page fast path; taxed primary ICP reader | TASK-TRACKER 2026-05-22 |
+
+---
+
+## Paused / Deferred
+
+| Idea | Status | Context |
+|---|---|---|
+| Post-ship retrospective (40.02) | Deferred — requires 2+ weeks of live data | Moved to `_DEFERRED_40.02-post-ship-retrospective.md` |
+| Cover image regen for ~30 non-spine companion posts | P3 — regen via chrome-devtools at 2400×1260 if posts stay in active rotation | TASK-TRACKER P3 |
+| Quarterly refresh sweep for AI-era posts | Q1 2027 trigger | GOAL-AT-A-GLANCE |
+| **v2 Lesson 1.2a Plan B: split by builder path** | Deferred — Plan A is single Mixo-only lesson (`smoke-test-build-with-mixo`); if reader data shows ≥30% Sam-readers fall back to Carrd, split into two parallel lessons (AI path + manual path) so each reader follows one coherent workflow without the other crowding the page. Trigger: reader survey / analytics showing Carrd-fallback rate. | Pivot decision 2026-06-08 (this session). Originally pilot was split as Generate-Elements + Hero-Ship; user rejected as ICP-confusing; merged into single Mixo workflow with Carrd as one-line `If this fails` fallback. |
+| **External 5-Sam validation pilot kit** | Deferred until course complete — DO NOT execute during template iteration. Trigger: v2 migration shipped across all 22 lessons + landing/FAQ/glossary aligned + Paul approves v2 template as locked + we want external validation BEFORE public promotion. Kit skeleton: `40-49-review/_DEFERRED_external-validation-pilot-kit.md`. | Direction set 2026-06-11: pilot is INTERNAL editorial review (Paul reviews & approves the v2 template), NOT external recruitment. External validation lives post-launch only. |
+
+---
+
+## Cross-Reference
+
+- **Active work**: `TASK-TRACKER.md` (this directory)
+- **Canonical architecture**: `30-39-architecture-design/30.02-adr-content-execution-readiness.md`
+- **All reviews**: `40-49-review/`
+- **All research**: `10-19-research/`
+- **Applied items**: See table above — 17 items moved from bank to course chapters
diff --git a/docs/projects/2605-tech-for-non-technical-founders/PROJECT-INDEX.md b/docs/projects/2605-tech-for-non-technical-founders/PROJECT-INDEX.md
new file mode 100644
index 000000000..949930188
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/PROJECT-INDEX.md
@@ -0,0 +1,211 @@
+# Project 2605 - Master Index
+
+**Project**: Tech for Non-Technical Founders 2026
+**Status**: 🟢 v1 (long-form) shipped + 🟡 v2 (micro-lesson) pilot in flight
+**Last Updated**: 2026-06-10 (Stale-doc cleanup: integration rules v1/v2 split, ICP clarified to Sam, archived 10.06, archived SPRINT-RUNBOOK + 50.01, path fixes)
+**Parent**: `../2510-seo-content-strategy/`
+
+This is the **single navigation hub** for the 2605 project. Read top-to-bottom on first visit.
+
+---
+
+## 🚀 IMMEDIATE ACTION - START HERE
+
+**v1 (long-form) is shipped**: 5 modules, 18 chapters, live at `/course/tech-for-non-technical-founders-2026/`.
+**Strategic pivot (2026-06-07)**: v2 (micro-learning format) is the next iteration based on `30.03-course-format-requirements-for-creators.md`. All 21 v1 chapters score 1.0-1.5/8 against the 8-part template (per 40.08 gap report). The 5 micro-lesson exploration drafts (Mom Test 3-lesson sequence + paid-pilot + mom-test-5-questions) were removed 2026-06-08 to start the migration from a clean slate; the **Quickstart and FAQ pages remain in `content/course/...`** as the v2 entry points already wired into the landing.
+
+**Currently in flight**: Phase 1 pilot COMPLETE (2026-06-08). Phase 2 (module-by-module migration) next. Phase 0 (mechanical quick wins) deferred until after pilot lessons finish.
+
+Post-ship work is tracked in `TASK-TRACKER.md` (see "Course Migration Schedule" section for the 4-phase rollout). Review docs in `40-49-review/`.
+
+### For a micro-lesson migration agent (Phase 1-2 of TASK-TRACKER "Course Migration Schedule")
+
+```
+1. Read TASK-TRACKER.md — "Active Phase" + "Next sprint candidates". Pick ONE task.
+2. Read 30-39-architecture-design/30.03-course-format-requirements-for-creators.md — CANONICAL spec for the v2 format. §2 = 8-part template (non-negotiable). §2.7 = case-study-at-module-end rule. Appendix A = worked example.
+3. Read 40-49-review/40.08-chapter-template-gap-report.md — every v1 chapter scored against the spec. Use as the "starting state" map.
+4. Reference 40-49-review/_ARCHIVED_40.09-mom-test-micro-lesson-qa-report.md ONLY for the QA methodology pattern (criterion-by-criterion binary scoring).
+5. Read the pilot lessons as the canonical implementation pattern:
+   - content/course/tech-for-non-technical-founders-2026/smoke-test-build-page/ (Lesson 1.2a - agnostic AI-builder workflow, Mixo as worked example, ~870w; Sam-glossing pushed over the 800w pilot ceiling deliberately - jargon decode beats word count)
+   - content/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/ (Lesson 1.2b - heavy gloss pass for snippet/head tag/heatmap/session recording/pixel/GA4/incognito, ~640w)
+6. Open the v2 production pages already wired into the landing: content/course/tech-for-non-technical-founders-2026/quickstart/ + .../faq/
+7. Voice gates: no em-dashes (use `-` not `—`); no "Founders who"/"Most founders"/"## Why this matters"/"ICP-E"; no template labels visible in published content; ZERO case studies inside lesson body (they live at module-end walkthrough page). The `See it in action` footer link is added in the SAME commit that publishes the module's walkthrough page - never before; otherwise the lesson promises a page that does not exist.
+8. After every micro-lesson rewrite: run bin/validate-course + em-dash sweep + Hugo build + mobile viewport check at 375px.
+9. Atomic unit = 1 lesson. Write, validate, commit. THEN move to next. Never batch.
+10. After each commit: update TASK-TRACKER.md "What just shipped." Before stopping: commit + push TASK-TRACKER.
+```
+
+### For an executing writer / task agent (single-session shortcut on v1 long-form)
+
+```
+1. Read TASK-TRACKER.md — identify the highest-priority un-spawned task (P1 items first).
+2. If task references a new chapter or revision: open the target file at content/course/...
+3. Run the gates in 50-59-execution/mechanical-audit-checklist.md after writing/editing.
+4. Pass → mark task complete in TASK-TRACKER.md.
+5. Fail → surface specific failures to user. Stop.
+6. Before shipping any revision, run voice-regression sweep: grep -rn "## Why this matters\|Founders who\|Most founders\|Founders we worked with" across edited files.
+```
+
+### Files a fresh session reads for post-ship tasks
+
+| File | Purpose |
+|---|---|
+| `30-39-architecture-design/30.03-course-format-requirements-for-creators.md` | **CANONICAL v2 spec** — micro-learning course format requirements, 8-part lesson template, core/optional tagging, gap analysis, migration guide. The authoritative answer to "how should I structure this lesson?" |
+| `40-49-review/40.08-chapter-template-gap-report.md` | **DIAGNOSTIC** — every v1 chapter scored 1.0-1.5/8 against the 30.03 template. The "starting state" map for migration. |
+| `40-49-review/_ARCHIVED_40.09-mom-test-micro-lesson-qa-report.md` | **QA METHODOLOGY PATTERN** — the audited lessons were removed 2026-06-08 (start v2 from clean slate). The criterion-by-criterion binary scoring structure is preserved as the canonical QA template for any new phase. |
+| `TASK-TRACKER.md` | Live queue of pending post-ship improvements (P1-P3) + Course Migration Schedule (Phase 0-3 rollout) |
+| `40-49-review/40.01-m1-m3-audit-2026-05-28.md` | Banned-pattern regression findings — permanent gates now in CLAUDE.md + 90.11 voice guide |
+| `40-49-review/40.03-sipoc-course-logic.md` | SIPOC course-logic validation — supplier-input-process-output-customer map, continuity validation, quality gates, 10/10 score |
+| `40-49-review/40.04-execution-readiness-sweep-2026-06.md` | June 2026 retrospective — time/money sweep + 13 critic-flagged gap closures + 9 tool-input fixes across 18 chapters |
+| `40-49-review/40.05-multi-perspective-icp-review-2026-06.md` | 4-lens ICP-aligned review (Burned/First-Time/Skim-First/Crisis) — 3 recommendations tracked in TASK-TRACKER |
+| `40-49-review/40.06-sam-customer-journey-report-2026-06.md` | Single-ICP Sam narrative — 18-chapter emotional arc, trust scores, recalibrated scoring methodology |
+| `40-49-review/40.07-sam-experience-improvement-report-2026-06.md` | Sam-first improvement recommendations (6 items, all marked Done in TASK-TRACKER 2026-06-07) |
+| `30-39-architecture-design/30.02-adr-content-execution-readiness.md` | **CANONICAL** — content policy (no speculative time/money), binary anchor thresholds per chapter, Module 2 two-pass framing rationale, 4-persona critic gate, Tier 1/2/3 punch list shape |
+| `10-19-research/_ARCHIVED_10.06-icp-persona-course-walkthrough.md` | (ARCHIVED 2026-06-10) Alex (burned founder) walkthrough. Archived because the course ICP is Sam (first-timer). Historical reference — use 40.06 for Sam, 90.10 for Alex website ICP. |
+| `10-19-research/_ARCHIVED_10.07-icp-sam-persona-course-walkthrough.md` | (ARCHIVED) — Superseded by 40.06 (Sam journey) + 40.07 (recommendations). |
+| `50-59-execution/mechanical-audit-checklist.md` | Greppable + structural + voice gates every post must pass |
+| `50-59-execution/distribution-prep.md` | Reddit/Twitter/Facebook/LinkedIn channels + share-copy templates + posting schedule |
+
+### For a strategy / review agent
+
+```
+1. Read GOAL-AT-A-GLANCE.md.
+2. Read 30-39-architecture-design/30.02-adr-content-execution-readiness.md — the canonical threshold-anchor table + content policy. ALL chapter edits must respect the anchors in section 2.
+2a. Read 40-49-review/40.04-execution-readiness-sweep-2026-06.md — what landed in the June 2026 sweep and the open follow-ups.
+2b. Read 40-49-review/40.01-m1-m3-audit-2026-05-28.md — understand what was caught and fixed.
+3. Read 40-49-review/40.06-sam-customer-journey-report-2026-06.md — definitive Sam ICP document.
+4. Read TASK-TRACKER.md — verify P1 items reflect the audit + ICP findings.
+6. Read 40-49-review/40.03-sipoc-course-logic.md — understand module continuity and structural constraints before proposing sequence edits.
+7. Read 20-29-strategy/20.02-positioning-vs-courses.md.
+8. Cross-reference against ../2510-seo-content-strategy/20-29-strategy/20.07-content-plan-icp-e-q2-2026.md.
+9. If retrospective is due: populate 40-49-review/40.02-post-ship-retrospective.md.
+```
+
+---
+
+## 📋 CORE DOCUMENTS
+
+### 🎯 Goals & Planning
+
+| File | Purpose |
+|---|---|
+| `GOAL-AT-A-GLANCE.md` | One-page summary, metrics, three-phase plan, delivery principles |
+| `TASK-TRACKER.md` | Live status of every course post + artifact |
+| `PROJECT-INDEX.md` | This file |
+
+### 🔎 Research (10-19)
+
+| File | Purpose |
+|---|---|
+| `10-19-research/10.01-course-program-landscape.md` | 19-program inventory, coverage matrix, gap analysis, voice intelligence |
+| `10-19-research/10.02-curriculum-sequence-synthesis.md` | Synthesis of 3 research inputs; why module structure beats pillar structure |
+| `10-19-research/10.03-2026-ecosystem-research-ru-source.md` | Russian-language source research on 2026 ecosystem (Sophia Matveeva, Drew Falkman, FI Vibecode, AI-Augmented Developer profile). English wrapper header explains contents. Originally at `docs/Курс для нетехнических основателей 2026.md`, moved 2026-05-12. |
+| `10-19-research/10.04-competitor-courses-2026-forum-validated.md` | Competitor course reviews from founder forums (Indie Hackers, Reddit, Hacker News) |
+| `10-19-research/10.05-content-organization-patterns-2026.md` | Gloria Mark / Pew 2026 / NN/g attention-span research; cognitive-load patterns for content structure |
+| `10-19-research/_ARCHIVED_10.06-icp-persona-course-walkthrough.md` | (ARCHIVED) Alex (burned founder) walkthrough. Use 40.06 for Sam. |
+| `10-19-research/_ARCHIVED_10.07-icp-sam-persona-course-walkthrough.md` | (ARCHIVED) — Superseded by 40.06 (Sam journey) + 40.07 (recommendations). |
+| `10-19-research/10.08-validation-tools-analysis-2026.md` | AI validation tools gap analysis & recommendations (June 2026). Sources: Russian-language market research (`docs/_research/`) + web research. Maps 6 gaps to course modules, ranks by ROI. |
+
+### 💡 Ideas Bank
+
+| File | Purpose |
+|---|---|
+| `LOW-IMPACT-IDEAS-BANK.md` | Aggregated dropped, deferred, and P3 ideas from all reviews and research. Scan when starting a new work cycle. |
+
+### 🔍 Reviews (40-49)
+
+| File | Purpose |
+|---|---|
+| `40-49-review/40.01-m1-m3-audit-2026-05-28.md` | Banned-pattern regression findings — permanent gates now in CLAUDE.md + 90.11 voice guide |
+| `40-49-review/40.03-sipoc-course-logic.md` | SIPOC course-logic validation — 10/10 score, mermaid diagrams, artifact chain, quality gates |
+| `40-49-review/40.04-execution-readiness-sweep-2026-06.md` | Sweep retrospective — 13 gap closures + 9 tool-input fixes + open follow-ups |
+| `40-49-review/40.05-multi-perspective-icp-review-2026-06.md` | 4-lens ICP review (Burned/First-Time/Skim-First/Crisis) — 3 recommendations in TASK-TRACKER |
+| `40-49-review/40.06-sam-customer-journey-report-2026-06.md` | Single-ICP Sam narrative — 18-chapter emotional arc, trust scores, recalibrated scoring |
+| `40-49-review/40.11-sam-simulation-pilot-lessons-2026-06.md` | Sam simulation report — Iter 19 pilot lessons. Beat-by-beat reader simulation, 5 themes, 5 surgical fixes applied. Strong recommendation: 5-Sam validation pilot before Phase 2. |
+| `40-49-review/_DEFERRED_40.02-post-ship-retrospective.md` | Post-ship retrospective — DEFERRED until 2+ weeks of live data |
+
+### 🧭 Strategy (20-29)
+
+| File | Purpose |
+|---|---|
+| `20-29-strategy/20.01-course-modules.md` | The 5 modules with input/output/checkpoint/artifact (REPLACES old pillars doc) |
+| `20-29-strategy/20.02-positioning-vs-courses.md` | Why this beats YC Startup School, Sophia Matveeva, Drew Falkman, Kukoyi book |
+| `20-29-strategy/20.11-course-migration-roadmap.md` | **CANONICAL** — dependency-aware Now/Next/Later roadmap for v2 micro-lesson migration. Task-level dependency graph, parallelization map, risks. Generated from `.agent/tasks.json`. |
+| `20-29-strategy/_ARCHIVED_20.07-content-plan-tnt-founders-2026.md` | ~~The 26-post map, 11 artifacts...~~ **ARCHIVED** — shipped course uses 5-module spine. Historical reference only. |
+
+### 🛠️ Execution (50-59)
+
+| Sub-dir | Purpose | Status |
+|---|---|---|
+| `50-59-execution/mechanical-audit-checklist.md` | Greppable + structural + voice gates every post must pass | Active |
+| `50-59-execution/distribution-prep.md` | Reddit/Twitter/Facebook/LinkedIn channels + share-copy templates | Active |
+| `50-59-execution/_ARCHIVED_SPRINT-RUNBOOK.md` | (ARCHIVED 2026-06-10) Sprint 1 runbook — DO NOT EXECUTE | Superseded by TASK-TRACKER migration schedule |
+| `50-59-execution/_ARCHIVED_50.01-phase-1-implementation-plan.md` | (ARCHIVED 2026-06-10) Phase 1 plan — DO NOT EXECUTE | Superseded by TASK-TRACKER migration schedule |
+| `50-59-execution/landing-page/` | Curriculum index page draft | Not yet authored; ships after Module 5 |
+
+### Blog post drafts (in main repo — companion pages, not course spine)
+
+| Slug | Module | Status |
+|---|---|---|
+| `content/blog/five-tech-words-stop-nodding-at/` | 2.1 | ✅ drafted |
+| `content/blog/engineering-org-chart-non-technical-founder/` | 5.1 | ✅ drafted |
+| `content/blog/reading-sow-clause-by-clause/` | 4B.4 | ✅ drafted + cover image |
+| `content/blog/three-questions-turn-standup-into-proof/` | 5.3 | ✅ drafted |
+
+---
+
+## 🔗 EXTERNAL DEPENDENCIES (read these too)
+
+| File | Why |
+|---|---|
+| `../../90-99-content-strategy/strategy-analysis/90.10-icp-primary-website-target.md` | ICP-E definition, pains, white-space features |
+| `../../90-99-content-strategy/strategy-analysis/90.11-voice-guide.md` | Voice rules, banned words, anti-AI patterns |
+| `../../90-99-content-strategy/thoughtbot-style-analysis-2025-10-15.md` | Tech post structural standards |
+| `../../workflows/blog-pipeline.md` | The 7-step blog writing workflow |
+| `../../workflows/proof-signal-portfolio.md` | Distinct proof signals per post (avoid repetition) |
+| `../../workflows/linkedin-post-pipeline.md` | Promo channel for each course post |
+| `../2510-seo-content-strategy/20-29-strategy/20.07-content-plan-icp-e-q2-2026.md` | Parent content plan; 10 wrap slugs integrate here |
+
+---
+
+## 🚨 INTEGRATION RULES (zero tolerance)
+
+### v2 micro-lesson conventions (authoritative — see 30.03)
+
+**For all v2 micro-lessons, 30.03 is the canonical authority.** These rules distill the key points:
+
+A. **8-part template mandatory.** Every lesson follows §2.1-2.8: Hook → Outcome → Concept → Visual → Do-Now → Error → Reflection → Bridge. Visual is optional; all other parts required.
+
+B. **Word count bands.** Standard lessons: 400-600 words. Tool-as-worked-example lessons: 500-900 words. Per 30.03 §1.6.
+
+C. **One visual per lesson.** Maximum 1 informational SVG/Mermaid per micro-lesson. Per 30.03 §2.4 (cognitive load theory).
+
+D. **No case studies inside lesson bodies.** Case studies live at module-end walkthrough pages only. Per 30.03 §2.7.
+
+E. **Zero template-label H2s.** Never use "## Do this now" / "## If this fails" / "## Why this matters" as H2s.
+
+F. **Every term glossed at first mention.** Sam knows nothing. Define MVP, PMF, ICP, CTA, DPA, ARR, MRR, etc. inline.
+
+### v1 long-form conventions (for companion/reference pages)
+
+**These rules apply to v1 long-form companion pages and blog posts, NOT to v2 micro-lessons:**
+
+1. **No parallel slugs.** 10 of 26 course posts wrap existing 2510 slugs. The 2605 project DOES NOT create new slugs for these.
+
+2. **No duplicate artifacts.** Lead magnets are the SAME artifacts the 2510 plan references. One canonical version, multiple link entry points.
+
+3. **Every course post carries the course frame.** Top callout + bottom course-nav table.
+
+4. **Simplest method on main path.** Advanced frameworks (Foundation Sprint, JTBD Canvas, Shape Up, etc.) relegated to optional "Advanced" sidebars.
+
+5. **No length caps for v1 long-form.** Word counts are not targets, ceilings, or floors. Length is byproduct of effective delivery. Cut test per section. **Note: v2 micro-lessons DO have word count bands (see 30.03 §1.6).**
+
+6. **≥3 handmade-style infographics per v1 post** (Mermaid + sketchy SVG mix, Excalidraw aesthetic, JT brand colors). **Note: v2 micro-lessons cap at 1 visual per lesson (30.03 §2.4).**
+
+7. **Tech-stack defaults**: Rails / Django / Laravel + full-stack-developer-ships-end-to-end.
+
+8. **All voice rules from `90.11` apply.** No special exemptions.
+
+9. **ZERO JT service CTAs anywhere in the course** (Option C: Pure Lead Magnet).
+
+10. **Every v1 post engineered for viral sharing.** Contrarian hook in opening 80 words, quote-tweetable insight (140-280 chars), specific weekly tactic, downloadable artifact. Shareable headline structure. **Note: v2 micro-lessons follow the 8-part template, not these viral-sharing rules.**
diff --git a/docs/projects/2605-tech-for-non-technical-founders/TASK-TRACKER.md b/docs/projects/2605-tech-for-non-technical-founders/TASK-TRACKER.md
new file mode 100644
index 000000000..d6ce58c7e
--- /dev/null
+++ b/docs/projects/2605-tech-for-non-technical-founders/TASK-TRACKER.md
@@ -0,0 +1,347 @@
+# Task Tracker - 2605 Tech for Non-Technical Founders
+
+**Last Updated**: 2026-06-10 (Stale-doc cleanup: Phase 0 deferred, Phase 1 completion notes, 10.06 archived, path fixes)
+
+## Active Phase: v2 Migration Pilot
+
+**Current sprint focus:** validate the v2 micro-lesson format on Module 2 before fanning out to the rest. See "Course Migration Schedule" section below for the 4-phase rollout. Cold AI agents should read `30.03-course-format-requirements-for-creators.md` + `40.08-chapter-template-gap-report.md` + `40.09-mom-test-micro-lesson-qa-report.md` before touching any v2 lesson.
+
+**What just shipped (2026-06-08):**
+- ✅ Phase 1 pilot RESTRUCTURED into ONE Mixo-only golden-path lesson:
+  - `smoke-test-build-page` — agnostic AI-builder workflow (Mixo as worked example, Manus AI and Durable named as equivalents, Carrd as manual-mode fallback): paste hypothesis → polish 4 copy blocks → swap hero → add disclaimer → publish → stranger test. Title and slug deliberately tool-agnostic so the lesson outlives any one tool.
+  - `smoke-test-wire-tracking` — Clarity + ad-platform pixel + optional GA4, ~430 words (unchanged from earlier pilot)
+- ✅ Deleted prior two-lesson split (`smoke-test-pick-builder-ship-page` + `smoke-test-ship-page`) - ICP review found audit framing + manual-path/AI-path conflation confused Sam; 6-element table positioned as audit gate but Mixo doesn't output labeled elements
+- ✅ Both lessons pass: Hugo build, validate-course (7/7), em-dash sweep (zero), word count in 500-800 band
+- ✅ Spec updates: 30.03 §2.7 mandates ONE case study per MODULE at module-end (slug `module-N-walkthrough-`); lesson bodies stay case-study-free; `See it in action` footer link added in SAME commit that publishes the walkthrough page (never before - placeholder URL reads as broken promise). AGENT-PROMPTS scaffolding file deleted - cold-agent workflow now lives inline in TASK-TRACKER + 30.03 + PROJECT-INDEX route.
+- ✅ Plan B (split-by-path: separate AI lesson + manual lesson) parked in LOW-IMPACT-IDEAS-BANK with trigger condition (reader data showing ≥30% Carrd-fallback rate)
+- ✅ Option C wired into landing: Quickstart + FAQ links in "Start here" callout, "What this course does NOT cover" section added with 7 explicit exclusions
+
+**Phase 1 pilot findings (record for cold agents):**
+
+| Observation | What it means for Phase 2 |
+|---|---|
+| Real time-per-lesson: ~25 min for the first draft + ~20 min for review/cuts ≈ 45 min/lesson | Phase 2 estimate of "~45-60 min per lesson" holds. Module 1 (3 remaining lessons × ~45 min) = ~2.5 hr realistic, not the original "~3-4 days." Earlier estimates were padded. |
+| Two-case-studies-per-lesson pattern produced ~30% word-count drag on the 400-600 budget | Superseded 2026-06-08: case studies now live at module-end walkthrough page only (30.03 §2.7); lesson bodies are case-study-free. |
+| Split-by-step pattern (audit lesson + ship lesson) confused Sam: audit framing assumed Mixo outputs labeled 6-element list, but Mixo outputs a complete page Sam can't easily map to the 6 elements | Workflow-shaped lessons (one Mixo session = one lesson) beat framework-shaped lessons (audit then ship). Match the cognitive split to the reader's actual session boundaries, not to teacher-imposed pedagogical phases. |
+| Concept blocks naturally drift to ~310 words when GA4-style "industry standard" addendums creep in | Watch for "overkill but include for completeness" content. Cut or move to optional sidebar. The 300-word cap is enforced, not aspirational. |
+| Template labels (1. Hook, 2. Outcome, etc.) NEVER leak into published content when the writer reads the lesson aloud at the end | Read-aloud check before commit is a cheap insurance. Adds <60s, prevents the worst kind of regression. |
+| Step 2 of Do-Now in Lesson 1.2a originally combined all 6 elements into one ~95-word paragraph | Bullets beat paragraphs in Do-Now steps. Mobile scanability is the deciding factor. |
+| ICP-fit case-study selection: Mia worked for 1.2a (B2C "use what you have" theme), Tomas worked for 1.2b (B2B "invisible builder blind spot" theme) | Strict alternation would have put Tomas in 1.2a where Mia's "scrappy founder uses real screenshot" lands harder. ICP-fit picking is the right rule. |
+
+**Phase naming note:** This doc uses "Phase 0" for the remaining mechanical quick wins (outcome sentences, success checks, Stuck? boxes — see migration schedule below). The completed surgical improvements are called "Option C" (matching 30.03 §8.4-8.5). These are separate work streams.
+
+**Next sprint candidates** (pick one):
+1. **Phase 2 — Module 1 full migration** — migrate remaining M1 chapters (1.1, 1.2b, 1.3) using pilot template (~2-3 days)
+2. **Wire micro-lessons into navigation** — add the 2 pilot lessons to course_sequence.yaml as draft entries for preview
+3. **Phase 0 mechanical sweep** — deferred until pilot lessons complete (~2-3 hours).
+
+## Current Active Scope
+
+This tracker is the **single source of truth** for all post-ship improvements. Recommendations from review files (40.04, 40.05, 40.06) and research (10.08) have been consolidated here.
+
+Current source of truth:
+
+- Chapter order: `data/course_sequence.yaml`
+- Project context and integration rules: `PROJECT-INDEX.md`
+- ICP lens: `docs/90-99-content-strategy/strategy-analysis/90.10-icp-primary-website-target.md`
+- Voice lens: `docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md`
+- Research: `10-19-research/10.08-validation-tools-analysis-2026.md`
+- Course overview: Chapter 0 (`how-this-course-works`) + landing page (`_index.md`)
+- Course format requirements: `30-39-architecture-design/30.03-course-format-requirements-for-creators.md` (canonical spec for course creators)
+- Low-impact ideas: `LOW-IMPACT-IDEAS-BANK.md` (this directory)
+
+---
+
+## ICP Practicality Improvement Backlog
+
+Review lens: the course ICP - a non-technical founder going from idea (or half-built MVP) to first paying customer, who mostly has NOT hired yet. Burned/already-hired founders are a secondary audience routed to the rescue chapters (4.1/4.2) and the landing "If Your Team Is Already Failing" fast path - do not write validation/build chapter bodies to the burned founder. (Distinct from the website lead-gen ICP in `90.10-icp-primary-website-target.md`.)
+
+Current practicality score: 7.5/10.
+Target: 8.5/10 before launch.
+
+| Priority | Task | Status | Notes |
+|---|---|---|---|
+| ✅ Done 2026-05-20 | Fix course landing module map | Done | Landing page module list merged to 5 modules (commit 32e064dd). Stale "Proactive Ceiling Signals" title fixed. |
+| ✅ Done 2026-05-20 | Fix stale module/chapter numbering in companion pages | Done | Global `Module N.X` → `Chapter N.X` rename across 28 .md + 2 SVGs + YAML; 6-module → 5-module spine renumber; 3 companion pages (operating-kit, pivot-or-persevere, churn-triage) Module 7 references resolved. GOAL-AT-A-GLANCE rewritten to 5-module spine. 20.07 content plan marked superseded. |
+| ✅ Done 2026-05-20 | Repair missing artifact link | Done (no-op) | Audit confirmed `/blog/founding-hypothesis-worksheet/` is not linked from any chapter. The tracker entry was stale from a prior cleanup pass. |
+| ✅ Done 2026-05-20 | Remove unfulfilled download/email promises | Done (already correct) | Audit confirmed `first-paying-customer-operating-kit` already says "There is no email signup; when a template is downloadable, the link appears inline below. We will not promise files we cannot ship today." Matches course philosophy. |
+| ✅ Done 2026-05-20 | Build 4 source-of-truth validators (Kaizen Muda outcome) | Done | All 4 validators implemented as `bin/validate-course` + `lib/course_validators.rb` (with test/unit/course_validators_test.rb): (1) chapter-number-consistency, (2) title-yaml-match, (3) internal-link-existence, (4) table-width. Hooked into `bin/hugo-build` as pre-flight check. Globs updated to handle nested `content/course///` structure. 3 of 4 pass after course-namespace migration; 1 (internal-link-existence) has 24 pre-existing broken-citation violations to non-existent research articles - separate follow-up. |
+| P1 | Add "Burned founder fast path" to landing | Planned | Emergency route: Ownership audit -> Friday demo -> weekly report -> salvage/rebuild -> switch dev shops -> AI risk. Put before the full course table. (Per-chapter routing added to Ch 1.1 on 2026-05-20.) |
+| P1 | Create downloadable PDF templates + restore "Free templates" section on landing | Planned | 2026-05-21: removed "Free downloadable templates" H2 + 14-row table from `_index.md` because the links pointed to in-browser chapter pages, not actual PDF downloads. The chapter pages still exist (Outreach Sequence Template, Mom Test Interview Script, Validated Problem Statement Template, Vibe PRD Template, Build Path Decision Worksheet, GitHub/AWS/DB Ownership Checklist, Self-Serve Stack Walkthrough, Where-to-Hire Map 2026, Hiring Interview Script, SOW Reading Guide, First-Paying-Customer Operating Kit, Friday Demo Template, Salvage vs Rebuild Decision Tree, "We Use AI" 5-Question Script). When the 14 PDFs are precreated, restore the landing section with the correct framing (PDF + browser-page link side by side). Cover image chip "TEMPLATES 14 free" stays unchanged - it remains accurate because the template chapter pages still exist as free in-browser resources. |
+| P1 | Add Founder Control Dashboard artifact | Planned | One-page control system for access, demos, reports, SOW, budget, AI risk, and salvage score. Tie the strongest ICP-E chapters together. |
+| P1 | Make every artifact copy-pasteable | Done | Each template page needs on-page scripts/checklists, not only descriptions of future assets. Prioritize SOW, DPA, outreach, hiring interview, ownership, Friday demo. All 6 done 2026-06-02: outreach quick-ref checklist, SOW agency email + pre-sign checklist, hiring interview pre-interview + polite-no emails, ownership audit spreadsheet + recovery email, Friday demo follow-up + skipped-twice message, DPA one-page template skeleton. |
+| ✅ Done 2026-05-22 | Separate early-founder path from rescue path | Done | Decision reversed: chapter-level routing blocks removed, not rolled out. The Ch 1.1 "Already burned? / Already hired?" block was deleted 2026-05-22 - it interrupted the primary idea-stage ICP reader with two "leave this page" callouts before the hook, and duplicated the landing-page "If Your Team Is Already Failing" fast path (the real entry-point router for burned founders). Do NOT add per-chapter routing blocks to other module-start chapters; route burned founders at the landing page only. |
+| ✅ Done 2026-06-02 | Add AI critic/simulator blocks per module | Done | Standardize where AI helps: critique artifact, simulate customer/vendor/advisor, find contradictions. State what AI cannot prove. One block per module = 5 blocks (new 5-module spine). M1.1: crystallized AI tools sidebar. M2.2: framed chapter as canonical AI simulator. M3.2: AI-as-peer callout standardized. M4.3: NEW build-review prompts (audit brief, check RLS, detect overengineering). M5.2: AI channel research framed as critic layer. Commit df9a537e.
+| P1 | Roll manual-minimum sidebar to other tool-heavy chapters | Partial | 2026-05-20: 3 chapters got $0-budget callouts (Ch 1.2 smoke-test, Ch 4.3 self-serve-mvp-stack, Ch 5.5 outbound). Ch 2.2 already had manual-minimum sidebar. Audit remaining chapters (Ch 5.3, 5.4) for any unaddressed paid-tool friction. |
+| SUPERSEDED | Add "Skip to the action" anchor links to longest chapters (40.05 Rec #1) | Superseded by 40.07 Rec #1 (2026-06-07) | Replaced by refined 40.07 version: targets M4.3a, M1.2a, M3.2 (narrowed from M1.1, M3.2, M4.3). See P2 item below for current. |
+| DEFERRED | Add burned-founder acknowledgment callouts in Module 2 (40.05 Rec #2) | Deferred (2026-06-07) | **DEFERRED by user direction.** Burned-founder ICP improvements tabled as an idea. The course ICP is Sam (the idea-stage first-timer), NOT Alex (burned founder). See 40.07 for Sam-first alternative recommendations. |
+| P2 | Add TL;DR summaries to all chapters — phased rollout (40.05 Rec #3) | Planned | Add 2-3 line TL;DR after Input/Output callout: what you'll do, why it matters, deliverable, where it goes next. Phase 1: 5 chapters + browser-use verification. Phase 2: fan out remaining 13. ~5 min per chapter. See 40.05 §Top 3 Recommendations #3. |
+| P2 | Add completion criteria to every chapter | Planned | Each chapter should end with "Done when / Next click / If blocked" so the founder knows when to move on. Template: `## Done when` + checklist + `## Next click` + conditional routing. 18 chapters. |
+| P2 | Tighten practical proof in weaker modules | Planned | Early validation and market-type chapters need more concrete founder examples, exact time boxes, and decision thresholds. |
+| P2 | Collapse outreach-sequence-template variant runs | Planned | 2026-05-23 audit found 3 variant groups rendered as 3 separate blockquote boxes each (LinkedIn DM openers ×3, cold-email subject lines ×3, possibly Day 1/3/7 email sequence ×3). Merge each group into ONE blockquote (use `>` blank-line separators) per the no-stacked-quotes rule. Lower priority because it's an artifact/template page, not a numbered linear chapter. |
+| P2 | De-stack + rebalance "$0 path" callouts (outbound, self-serve-mvp) | Planned | 2026-05-23: two chapters still have a "$0 path / $0 outbound stack" blockquote callout immediately under the Module banner (top-stack). Bundle with the deferred Module 4/5 budget-rebalance pass - de-stack to plain prose AND rebalance the framing per `feedback_budget_stance_free_and_paid_equal` (free and paid as equal options, reader chooses; don't lead with "$0 first"). |
+| P3 | Add Wizard of Oz Concierge MVP path to Ch 4.3 (10.08 Gap #2) | Planned | Add Tally + Zapier + Airtable as $0 no-code backend alternative to Lovable build for founders who should validate deeper before coding. Documented in 10.08-validation-tools-analysis-2026.md §Gap 2. |
+| P3 | Add echo chamber warning to Ch 5.3 and Ch 2.3 (10.08 Gap #3) | Planned | Warn that warm network is for SALES (valid) not VALIDATION (invalid echo chamber). Add cross-reference from Ch 2.3 warning against interviewing only other founders. Documented in 10.08 §Gap 3. |
+| P3 | Add Loom video outreach tactic to Ch 5.2 or 5.5 (10.08 Gap #4) | Planned | 10-minute personalized B2B video audits with higher conversion than cold email. Low effort, high differentiation. Documented in 10.08 §Gap 4. |
+| P3 | Add Engineering as Marketing to Ch 5.2 (10.08 Gap #5) | Planned | Free No-Code micro-tools (calculators/checklists) for $0 CAC organic SEO. Distinct from content marketing. Documented in 10.08 §Gap 5. |
+| Dropped | Add time-badge to each chapter header | Dropped (2026-06-02) | Each chapter needs a "**Time**: ~45 min" badge at the top so the reader can plan their session. 18 chapters. Dropped per user direction — time anchoring contradicts the ADR §1 policy of avoiding speculative effort estimates. |
+| P1 | Build companion-post FAQ collection | New (ICP walkthrough _ARCHIVED_10.06) | Create a curated FAQ linking 8 companion posts as "read next" sidebars in relevant chapters. Currently only linked via course-frame nav. |
+| P1 | Rescue-path routing audit | New (ICP walkthrough _ARCHIVED_10.06) | Audit all 5 module-start chapters for consistent burned-founder rescue-path routing. Chapter 1.1 had routing blocks added then removed; ensure uniform approach across spine. |
+| P3 | Cover image regen audit for non-spine posts | Planned | 2026-05-20: 14 spine covers regenerated to clean "Curriculum 2026" badge. ~30 companion-post covers still have "Curriculum NN/30" stale counter. Regen via chrome-devtools at 2400×1260 if posts stay in active rotation. |
+| ✅ Done | Update decision doc 20.10 with Click correction | Done | Decision block added at top of 20.10.md (2026-05-20) marking Recommendation section as superseded. TASK-TRACKER entry updated 2026-05-29. |
+| ✅ Done 2026-06-04 | Add Sam customer journey report (40.06) with trust score methodology | Done | Single-ICP narrative spanning all 18 chapters + landing page. 3 entry-point doors. Per-chapter trust scores with emotional arc. Double-dip U-curve visualization. Appendix D: 19-row recalibrated trust score table with calibration constraints. Commit 63fb7d73. |
+| ✅ Done 2026-06-07 | Add Sam experience improvement report (40.07) | Done | 6 actionable Sam-first recommendations across 18 chapters. Burned-founder ICP framing removed per user direction. Recommendations logged here for triage. See `docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.07-sam-experience-improvement-report-2026-06.md`. |
+| ✅ Done 2026-06-07 | Archived 10.07 Sam walkthrough | Done | Superseded by 40.06 (definitive Sam reference) and 40.07 (canonical recommendations). Renamed to `_ARCHIVED_10.07-icp-sam-persona-course-walkthrough.md` with cross-reference note to 40.06 + 40.07. |
+| ✅ Done 2026-06-07 | Published 30.03 course format requirements for creators | Done | Consolidated micro-learning spec + gap analysis + migration guide. Canonical requirements for course format design. See `30-39-architecture-design/30.03-course-format-requirements-for-creators.md`. |
+| ✅ Done 2026-06-10 | Applied 5 Sam-simulation surgical fixes to pilot lessons | Done | Added Mixo re-prompt hint (1.2a Step 2), Mixo head-tag path (1.2b), domain question (1.2a Step 5), non-Chrome incognito shortcuts (1.2a Step 5), preview-mode script-blocking note (1.2b Step 4). ~80 words total. Sam simulation report: 40.11. |
+| 🔲 P1 | 5-Sam Validation Pilot — recruit 3-5 real founders, watch Clarity recordings | Planned (DEFERRED until course complete) | Pivoted 2026-06-11: "pilot" in 2605 work = INTERNAL editorial template review (Paul-as-reviewer), NOT external recruitment. External kit deferred to post-course-completion at `40-49-review/_DEFERRED_external-validation-pilot-kit.md`. Original research questions preserved there for revival. |
+| 🔲 P1 | Course-wide voice cleanup sweep (post-pilot-lock) | Planned | After 1.2a + 1.2b pilot template is locked: apply the same voice rules across all other lessons (1.1, 1.2c, 1.3, M2-M5, walkthroughs, _index). Specifically: (a) strip scattered budget mentions per voice guide rule "Never mention price/budget except in direct comparison"; (b) consolidate 3+ interchangeable tool listings to one example per voice guide rule "Never list 3+ interchangeable tools when one is the obvious lead"; (c) rename 1.2b title "Wire Tracking Before You Spend a Dollar" → "Wire Tracking Before Traffic Starts" (touches 13+ files: lessons, _index, walkthrough, GOAL-AT-A-GLANCE, TASK-TRACKER, data/course_sequence.yaml); (d) migrate closure blocks to the 30.03 §2.9 4-slot pattern (`Done` / `You have now` / `Next` / `If blocked`); (e) rewrite Output/Outcome lines in Sam-voice (binary observable behavior, not Paul-business-speak). Gate: Phase 2 M1 migration starts AFTER this cleanup so the migrated lessons inherit the locked voice. |
+
+**5-Sam Pilot steps:**
+
+| Step | Action | Est. time |
+|---|---|---|
+| 0.1 | Recruit 3-5 idea-stage founders (indie-hackers, Reddit r/startups, personal network). Screening: no tech background, has an idea they haven't validated, reads on phone. | ~2 hours |
+| 0.2 | Post pilot lesson URLs (1.2a + 1.2b). Install Clarity on these pages. Instruct Sam to read both lessons and follow the Do-Now steps. | ~30 min |
+| 0.3 | Wait 3-5 days for Sams to complete. Watch Clarity session recordings + heatmaps. Record: completion rate, time-on-page, scroll depth, stall points, rage-clicks. | ~2 hours |
+| 0.4 | Synthesize findings: compare simulation predictions vs real behavior. Update Phase 2 template with any blind spots found. | ~1 hour |
+| 0.5 | Decision gate: if ≥3 Sams complete with no systemic stall point, fan out to Phase 2. If same stall point appears in ≥2 Sams, fix template first. | ~30 min |
+
+**Gate:** All 5 research questions have answers from real data. Template updated with findings. Only then proceed to Phase 2 M1 migration. |
+
+**Phase naming note:** This pilot uses "0.1-0.5" step numbering to distinguish it from the deferred Phase 0 mechanical quick wins.
+| ✅ Done 2026-06-07 | Add "Skip to the action" anchor links to longest chapters (40.07 Rec #1) | Done | Anchor-link callout added to M4.3a (6 links), M1.2a (4 links), M3.2 (4 links). Serves skim-first Sam. |
+| ✅ Done 2026-06-07 | Reduce builder comparison fatigue in M1.2a (40.07 Rec #2) | Done | Builder list restructured as decision tree: Mixo (start here) → Manus AI (fallback) → Durable/NeetoSite/Carrd (only if experienced). Eliminated the "Default vs Fallback" two-tier framing. |
+| ✅ Done 2026-06-07 | Add "First-timer fast path" to landing page (40.07 Rec #3) | Done | Callout added after hero section on `_index.md`: "New founder, no team, no trauma? Skip the diagnostic. Start at Chapter 1.1." |
+| ✅ Done 2026-06-07 | Reposition M2.2 (AI Persona) as optional (40.07 Rec #4) | Done | Implemented option 2: added "Skip this if you've interviewed before" callout to M2.2 + tagged [OPTIONAL] on landing page module index. M5.2 also tagged [OPTIONAL] per 40.06 trust scores. |
+| ✅ Done 2026-06-07 | Add "Stuck? Try this" boxes per module for first-timers (40.07 Rec #5) | Done | Stuck boxes added to M1.2a (builder paralysis), M2.3a (too-few-names), M3.2 (feature-list creep), M4.3a (12-rules overwhelm), M5.4 (asking-for-money terror). Placed after existing "If blocked" sections. |
+| ✅ Done 2026-06-07 | Move M4.3 AI critic block before the 12 rules (40.07 Rec #6) | Done | AI critic block (3 Claude prompts for build audit, RLS check, scope leak detection) moved before the 12 rules section. Sam hits the actionable prompts first; 12 rules are the reference checklist after. |
+| ✅ Done 2026-06-07 | Create one-page Quickstart (30.03 Option C) | Done | New page: `/quickstart/` — problem statement, promise, minimal path (core lessons only per module), gate thresholds, Start-here button. |
+| ✅ Done 2026-06-07 | Create FAQ page (30.03 Option C) | Done | New page: `/faq/` — 15 Q&A across all 5 modules + general questions. Typical blockers: Stripe verification, Mom Test scores <7, builder paralysis, 12-rules overwhelm, asking for money. |
+| ✅ Done 2026-06-07 | Create "What not to learn" section (30.03 Option C) | Done | Added to `_index.md` after "This is not for you if" — 7 explicitly excluded topics (coding, hiring CTO, VC, team mgmt, marketplace/mobile/AI, legal, SEO/marketing at scale).
+
+---
+
+## Closed today (2026-05-20)
+
+| Done | Notes |
+|---|---|
+| 3-cycle UI/UX polish across 18 spine chapters | 94 issues fixed across Groups A-F |
+| SEO frontmatter trims | 7 chapters trimmed for title ≤60 / desc ≤170 |
+| YAML title alignment | vibe-coding-ceiling-signals YAML matched file title |
+| Cover image regen | 14 spine covers, "Curriculum 2026" badge, ai-persona slogany dropped |
+| Module → Chapter nomenclature | Global sweep across content/blog + YAML + 2 SVGs (28 .md files) |
+| Ch 1.1 shame recovery paragraphs | 3 paragraphs after intro callout addressing burned-founder shame |
+| Ch 1.1 non-linear routing | Top-of-page block: "Already burned?" / "Already hired?" route to 5.2 / 5.1 |
+| Ch 1.1 Magic Lenses Money skip guidance | Pre-revenue founders can leave Money lens blank until smoke test data lands |
+| Ch 2.2 manual-minimum sidebar | $0 alternative to the $300-500/mo tool stack before the 5-step sequence (was Ch 3.2 pre-merge) |
+| Verified: "We..." opener density already at 0% in Ch 2.2 + Ch 5.3 (Group B polish caught this) |
+| **5-module spine merge** | Module 1 (1 chapter) + Module 2 (2 chapters) merged into 3-chapter Module 1 (Hypothesis & Smoke-Test). All downstream modules shifted down by 1. Slug-stable. |
+| YAML `goal:` field | Added one-sentence outcome per chapter to `data/course_sequence.yaml` (18 entries) |
+| $0-budget reframe | Top-of-chapter callouts in Ch 1.2 (smoke-test: Neeto/Carrd free + organic), Ch 4.3 (self-serve-mvp-stack: Lovable+Supabase+Stripe free tiers, under $50 to first customer), Ch 5.5 (outbound: Apollo free + Gmail mail-merge + Loom free + Calendly free) |
+| Module 2↔3 sequence swap DECIDED | Kept current order. Re-read Click's "Experiment" chapter: it's the lightweight landing-page-class test, NOT the heavier Design Sprint prototype + 5-user test. Our spine matches Click: Foundation (1.x) → Validate deeper (2.x) → Build. The reviewer's swap argument was anchored on "$300-500 ad spend before talking to anyone" — fixed by the $0-budget reframe instead of restructure. Decision doc: 20.10-sequence-decision-validate-vs-smoke-test.md |
+
+---
+
+## Course Migration Schedule (8-Part Template Rollout)
+
+**Reference docs:** 30.03 §8 (migration guide), 40.08 (gap report — all 21 chapters at 1.0-1.5/8), Appendix A micro-lesson example
+
+### Scheduling Principles
+
+Six principles drive this schedule. The wrong order wastes hours; the right order compounds learning.
+
+1. **Mechanical before creative.** Edits that follow a formula (add one outcome sentence, convert a table to a numbered list) require zero design brain. Do them all first while the mental model of the template is fresh. Creative rewrites (splitting a 3,000-word chapter into 4 micro-lessons) need the template to be second nature.
+
+2. **Complete one module end-to-end before fanning out.** The trap: add hooks to all 21 chapters, then outcomes to all 21, then concept blocks to all 21. You never see a single lesson fully working until the last pass. Instead: finish Module 1 (4 chapters → micro-lessons) completely. Ship it. Learn what broke. Apply those lessons to Module 2. Each module gets better.
+
+   **Exception: Phase 0 mechanical edits.** Adding one-sentence outcomes, success checks, and Stuck? boxes is purely formulaic — pull a YAML field, add a table row, name a common stall point. No design brain required. Fanning these out to all 21 chapters in one pass is safe and efficient. The principle applies to Phase 2 creative rewrites, where the risk of inconsistent bridges and broken handoffs is real.
+
+3. **Pilot before scale.** The first micro-lesson rewrite takes 3× longer than the fifth because you're discovering the real constraints — how 300 words actually feels, where Mermaid diagrams break on mobile, whether the bridge dependency actually holds. Do a 1-chapter pilot, measure the real time, recalibrate the estimates, then scale.
+
+4. **Top-of-funnel first.** Module 1 is where students decide to stay or leave. Improvements here have the highest conversion leverage. It's also the simplest module (no Supabase, no Stripe webhooks, no cold outreach). Start here to build momentum.
+
+5. **Dependency order within modules.** Never rewrite a chapter that depends on artifacts from a chapter you haven't rewritten yet. The bridge handoff (template §2.8) requires both lessons to be stable. Rewrite modules in linear order: 1 → 2 → 3 → 4 → 5.
+
+6. **High-complexity last.** Module 4 (Supabase wiring, Stripe webhooks, RLS policies) and Module 5 (paid pilot negotiation, cold outbound sequences) are the hardest to compress into 300-word concept blocks. By the time you reach them, you've done 10+ micro-lessons in simpler modules. The template is muscle memory.
+
+---
+
+### Phase 0: Remaining Quick Wins (DEFERRED — postponed until pilot lessons complete)
+
+> **Naming note:** This "Phase 0" is the mechanical quick-wins pass (outcome sentences, success checks, Stuck? boxes). It is separate from **Option C** (Quickstart, FAQ, "What not to learn," 6 Sam fixes) which is complete per 30.03 §8.4. See 30.03 §8.5 for the consolidated web delivery roadmap.
+
+**Status:** Deferred. Postponed until pilot lessons complete per user direction (2026-06-10). These are mechanical edits that don't require rewriting chapters — do them in one focused session when ready.
+
+| Step | Action | Chapters | Est. time |
+|---|---|---|---|
+| 0.1 | Add one-sentence outcomes | 21 | ~42 min |
+| 0.2 | Add success checks to "What to do next" tables | 21 | ~42 min |
+| 0.3 | Roll out Stuck? boxes to remaining chapters | 16 (5 already done) | ~80 min |
+
+**How:** Pull the `goal` field from `data/course_sequence.yaml` for each chapter's YAML frontmatter. Format: "After this chapter you will be able to: [goal]." Place after the Input/Output callout. For success checks: add a final row to each "What to do next" table — "✅ Success check:" with a verifiable condition. For Stuck? boxes: name the most common first-timer stall point for that chapter, give a concrete fix, place after existing "If blocked."
+
+**Gate:** Hugo build passes. No content rewrites — these are mechanical additions.
+
+---
+
+### Phase 1: Pilot Micro-Lesson Rewrite (✅ COMPLETE 2026-06-08, ~3 hours actual)
+
+**Status:** ✅ DONE. Chapter 1.2a (Smoke Test Build) migrated to 2 micro-lessons. Real time-per-lesson ~45 min (first draft + review). Template refinements + pilot findings recorded in "What just shipped" block above. Phase 2 can now proceed using the validated pattern.
+
+| Step | Action | Est. time |
+|---|---|---|
+| 1.1 | Select pilot chapter | 5 min |
+| 1.2 | Split chapter into 2-3 micro-lessons (concept boundaries) | 30 min |
+| 1.3 | Write all 8 parts for each micro-lesson | 2 hours |
+| 1.4 | Build Hugo, fix lint issues, verify on mobile viewport | 30 min |
+| 1.5 | Code review + final polish | 30 min |
+| 1.6 | Write post-pilot notes: actual time-per-lesson, surprises, template refinements | 15 min |
+
+**Recommended pilot:** Chapter 1.2a (Smoke Test Build). Reasons:
+- Lowest word count (2,364) → easiest to split
+- Already at 1.5/8 (Stuck? box + anchor links + visual)
+- Simple domain (landing page, not database schemas)
+- Top of Module 1 — the first module gets rewritten first anyway
+- Natural split points: builder choice → page elements → tracking setup
+
+**Alternative if 1.2a is too tool-dependent:** Chapter 2.1 (Mom Test, 2,931 words). The 5 micro-lesson exploration drafts (Mom Test 3-lesson sequence + paid-pilot + mom-test-5-questions) were removed 2026-06-08 to start the migration from a clean slate. The pilot would be a fresh rewrite using 30.03 Appendix A as the canonical pattern.
+
+**Gate:** One chapter fully migrated. Real time-per-lesson measured. Template refinements documented. Only then proceed to Phase 2.
+
+---
+
+### Phase 2: Module-by-Module Full Migration (~2-4 weeks, raises median to 6.5+/8)
+
+**Status:** Not started. Rewrite all remaining chapters module by module, completing each module fully before moving to the next.
+
+#### Module 1 — Hypothesis & Smoke Test (~3-4 days)
+
+4 chapters → ~5 micro-lessons. Simplest content, highest leverage.
+
+| Chapter | → Micro-lessons | Key split |
+|---|---|---|
+| 1.1 Founding Hypothesis | ~2 lessons | Mad Libs frame → 4-lens scoring |
+| 1.2a Smoke Test Build | ~2 lessons | Builder choice + page elements → tracking setup |
+| 1.2b Smoke Test Run | ~1 lesson | Ad setup + reading conversion rate + go/iterate/kill (can fit 300-word concept block) |
+| 1.3 Price Hypothesis | ~1 lesson | Stripe Payment Link setup + price interpretation |
+
+**Module 1 exit gate:** All 5 micro-lessons follow 8-part template. Hugo build ✓. Mobile viewport ✓. Bridge chain integrity verified (1.1 → 1.2a → 1.2b → 1.3 → M2 intro).
+
+#### Module 2 — Validate the Problem (~4-5 days)
+
+5 chapters → ~6 micro-lessons. Medium complexity — the content is interview scripts and outreach, not technical. But it's the longest module.
+
+| Chapter | → Micro-lessons | Key split |
+|---|---|---|
+| 2.1 Mom Test | ~2 lessons | 5-question script → scoring rubric + synthesis decision |
+| 2.2 AI Personas [OPTIONAL] | ~1 lesson | One standalone optional lesson — skip-safe |
+| 2.3a Find People | ~1 lesson | ICP sharpening + community discovery + search strings |
+| 2.3b Outreach | ~1 lesson | Outreach templates + booking cadence |
+| 2.4 Clickable Prototype | ~1 lesson | Lovable prototype build + 5-user test signals |
+
+**Module 2 exit gate:** All 6 micro-lessons follow template. Core path (2.1 → 2.3a → 2.3b → 2.4) produces validated problem statement without 2.2. Bridge chain verified.
+
+#### Module 3 — Design from Evidence (~2-3 days)
+
+2 chapters → ~3 micro-lessons. Shortest module, fastest to rewrite.
+
+| Chapter | → Micro-lessons | Key split |
+|---|---|---|
+| 3.1 Product Brief | ~2 lessons | Problem statement → user + build + metric + no-go rows |
+| 3.2 Outcomes Check | ~1 lesson | Feature audit → outcome mapping → decision |
+
+**Module 3 exit gate:** All 3 micro-lessons follow template. The brief-to-outcomes handoff is tight — the bridge from 3.1 names exactly which rows 3.2 audits.
+
+#### Module 4 — Build It Yourself (~4-5 days)
+
+5 chapters → ~6 micro-lessons. **Highest technical complexity.** Supabase RLS, Stripe webhooks, SQL self-tests, 12 build rules. This is where the 300-word concept block constraint is hardest to satisfy.
+
+| Chapter | → Micro-lessons | Key split |
+|---|---|---|
+| 4.1 Hire Decision | ~1 lesson | Decision tree → path selection |
+| 4.2 Ownership Audit | ~1 lesson | 12-item checklist → recovery email |
+| 4.3a Stack Tools | ~2 lessons | What each tool does → pre-flight rules |
+| 4.3b Build Phases | ~2 lessons | Phases 1-2 (UI + auth) → Phases 3-4 (Stripe + deploy) |
+| 4.4 Ceiling Signals [OPTIONAL] | ~1 lesson | One standalone optional lesson |
+
+**Module 4 exit gate:** All 6 micro-lessons follow template. Technical concept blocks pass the ≤300-word check. RLS + webhook concepts distilled to 3 sentences each. Bridge chain verified. Optional 4.4 skip-safe.
+
+#### Module 5 — First Paying Customer (~4-5 days)
+
+5 chapters → ~6 micro-lessons. Highest emotional stakes — asking for money, cold outreach, PMF testing. The paid pilot DPA template is the hardest single block to compress.
+
+| Chapter | → Micro-lessons | Key split |
+|---|---|---|
+| 5.1 PMF Test | ~1 lesson | Survey setup → 40% threshold interpretation |
+| 5.2 Channel Selection [OPTIONAL] | ~1 lesson | One standalone optional lesson |
+| 5.3 Personal Network | ~1 lesson | 8-name audit → outreach motion |
+| 5.4 Paid Pilot | ~2 lessons | DPA template → Stripe deposit + kickoff cadence |
+| 5.5 Cold Outbound [OPTIONAL] | ~1 lesson | Filter → personalize → Loom → Calendly pipeline |
+
+**Module 5 exit gate:** All 6 micro-lessons follow template. DPA template split into concept block (<300 words) + do-this-now steps. Bridge chain verified. Win recap + share prompt on final lesson. Completion Toolkit bundle linked.
+
+---
+
+### Phase 3: Cross-Cutting Polish Pass (~2-3 days)
+
+**Status:** Not started. After all 5 modules are rewritten, do a single pass across all lessons to ensure consistency.
+
+| Step | Action | Est. time |
+|---|---|---|
+| 3.1 | Verify every bridge names a specific dependency (not just "Next: Ch X") | ~1 hour |
+| 3.2 | Verify core path alone produces all 6 artifacts without touching optional lessons | ~30 min |
+| 3.3 | Verify emotional arc (40.06 trust curve) is preserved across micro-lessons | ~1 hour |
+| 3.4 | Verify all 6 artifacts are bundled in final Completion Toolkit reference | ~30 min |
+| 3.5 | Mobile viewport test on all lessons (375px iPhone SE) | ~1 hour |
+| 3.6 | Full Hugo build + validate-course + link checker | ~30 min |
+| 3.7 | Update landing page module maps to reflect new lesson structure | ~30 min |
+| 3.8 | Update Quickstart to reflect micro-lesson path | ~30 min |
+| 3.9 | Final code review | ~30 min |
+
+**Phase 3 exit gate:** All lessons pass template QA checklist (30.03 §7). Hugo build ✓. validate-course ✓. Mobile viewport ✓. Emotional arc preserved. Core path produces all artifacts.
+
+---
+
+### Total Estimated Effort
+
+| Phase | Description | Est. time | Cumulative median score |
+|---|---|---|---|
+| Phase 0 | Quick wins (mechanical) | ~2 hours | 1.0 → ~2.5/8 |
+| Phase 1 | Pilot micro-lesson rewrite | ~4 hours | Proof of concept |
+| Phase 2 | Module-by-module full migration | ~2-4 weeks | 2.5 → ~6.5+/8 |
+| Phase 3 | Cross-cutting polish pass | ~2-3 days | 6.5 → 7.0+/8 |
+| **Total** | | **~3-5 weeks** | **1.0 → 7.0+/8** |
+
+> **Day estimates in Phase 2 include:** writing + Hugo build verification + mobile viewport check + bridge chain verification per module. Not pure writing time — the overhead of splitting chapters, designing bridge dependencies, and compressing concept blocks is baked in.
+
+> **Why the range:** Phase 2 is `2-4 weeks` based on pilot data from Phase 1 (~45 min per lesson real time). The 30.03 Appendix A example took ~30 min for one lesson; at 20-25 lessons, that's 15-19 hours of pure writing. But splitting chapters, designing bridges, compressing concept blocks, and fixing mobile issues adds overhead. The 2-week estimate assumes 4 lessons/day (sustainable pace after pilot); the 4-week estimate allows for Module 4's technical complexity and Module 5's emotional-stakes rewrites.
+
+---
+
+### Risk Mitigation
+
+| Risk | Mitigation |
+|---|---|
+| Phase 2 stretches past 4 weeks | Ship module-by-module. Each module is independently shippable — Module 1 can go live while Module 2 is still being written. Never block the whole release on the last module. |
+| Phase 0 work is deferred until after pilot lessons complete | Phase 0 costs ~2-3 hours. Deferred per user direction (2026-06-10) so pilot momentum is not interrupted. Execute when pilot lessons are stable and Phase 2 begins. |
+| Technical chapters (4.3a, 4.3b) can't compress to 300 words | Allow 400-word concept blocks for technical chapters with hard constraints (RLS, webhooks). The template says ≤300; the spirit is "no bloat." A 400-word block that genuinely needs the space is better than a 300-word block that omits a critical concept. Flag these as exceptions in the rewrite notes. |
+| Bridges break when upstream lesson changes | The Phase 3 bridge audit catches these. Do NOT try to get bridges right on first pass — expect them to need adjustment when the full chain is visible. |
+| Phase 1 pilot diverges from 30.03 Appendix A worked example | 30.03 Appendix A is the canonical pattern. If Phase 1 discovers the pattern needs refinement, update 30.03 (with user approval) — do not let the pilot silently set a different precedent. |
+| Mobile viewport issues discovered late | The Phase 3 viewport test is a safety net, not the primary check. Test each module's lessons on mobile as part of the module exit gate. Don't defer all mobile testing to the end. |
+
+---
+
+## Practicality Model Chapters
+
+Preserve these as the standard for future edits:
+
+- Ownership audit
+- Friday demo
+- Weekly report
+- SOW review
+- Salvage/rebuild
+- Switch dev shops
+- AI agency questions
+- AI token bill
+- Slopsquatting gate
diff --git a/docs/visuals/running-case-studies.md b/docs/visuals/running-case-studies.md
new file mode 100644
index 000000000..8084e2bbf
--- /dev/null
+++ b/docs/visuals/running-case-studies.md
@@ -0,0 +1,105 @@
+# Running Case Studies — Course Thread
+
+Two founders run through all 5 modules. Each chapter includes a "Case Study" callout showing how the chapter's technique applies to Tomas (B2B SaaS) and Mia (B2C marketplace). This creates simulated interactivity — the ICP reader watches a founder like them apply the technique and see the result.
+
+**Format per chapter**: A `> **Case Study:**` blockquote at the end of the main body (before "Further reading"), showing the outcome for both founders. Keep each entry ≤4 sentences. Reference the concrete detail from the case profile below.
+
+**Rule**: Case studies are sidebar callouts, NOT chapter openers. Never open a chapter with a case study — this triggers the voice-guide template-fatigue rule. The case study goes after the technique is taught, not before.
+
+---
+
+## Case 1: Tomas — B2B SaaS (Accounting/FinTech)
+
+| Detail | Value |
+|---|---|
+| **Name** | Tomas |
+| **Background** | Ex-accountant, 4 years at a mid-size firm. Left to start a company. Non-technical. |
+| **Idea** | **ReconcileBot** — automated invoice reconciliation for mid-size accounting firms (50-200 employees). Auto-matches Stripe transactions against QuickBooks invoices, flags discrepancies in 90 seconds instead of 2 hours. |
+| **Burn story** | Paid a dev shop $60K over 8 months for an MVP. Delivered a buggy dashboard with hardcoded data. GitHub org, AWS account, and domain were all under the agency's accounts. Tomas had no admin access. Fired them. |
+| **Current state** | Has the idea validated through his network (ex-colleagues complain about this weekly), but zero evidence. $80K savings left. No team. No product. Distrustful of agencies. |
+| **Personality** | Detail-oriented, skeptical, numbers-driven. Wants proof before spending. Reads contracts line by line. Would rather build it himself than trust another agency. |
+| **ICP match** | Direct match for the course. Burned by a devshop, non-technical, has an idea, needs a linear route. |
+
+## Case 2: Mia — B2C Marketplace (EdTech)
+
+| Detail | Value |
+|---|---|
+| **Name** | Mia |
+| **Background** | Former special-ed teacher, 8 years in public schools. Left to solve a problem she saw daily. Non-technical. |
+| **Idea** | **TutorMatch** — marketplace connecting parents of kids with learning disabilities (dyslexia, ADHD, dyscalculia) to vetted specialized tutors. Search by specialty + location, parent reviews, booking/payment. |
+| **Burn story** | Hired a freelance team on Upwork for $45K over 6 months. Built a half-finished WordPress site with a broken booking system. The team ghosted. Mia owns the domain and WordPress install, but the code is a mess. |
+| **Current state** | Has a half-built site that doesn't work. Strong network of parent communities and teacher contacts. $45K savings left. No team. Cautious after being burned. |
+| **Personality** | Community-driven, passionate, people-first. Tends to trust people too quickly — her burn came from hiring the cheapest Upwork team without checking references. Wants to help parents NOW, not build tech. |
+| **ICP match** | Direct match. Burned by freelancers, non-technical, has a half-built product, needs validation + a path forward. |
+
+---
+
+## Full 5-Module Arc
+
+### Module 1 — Hypothesis & Smoke Test
+
+| Chapter | Tomas outcome | Mia outcome |
+|---|---|---|
+| **1.1** · Form Hypothesis | Founding Hypothesis: "Mid-size accounting firms (50-200 employees) waste 15+ hours/month reconciling Stripe against QuickBooks by hand. ReconcileBot auto-matches invoices in 90 seconds and flags the 5% that need a human." Scored 4/5 on customer, 4/5 on problem, 3/5 on approach, 3/5 on money. Weakest blank: money — doesn't know if they'll pay $200/mo or $2,000/mo. | Founding Hypothesis: "Parents of kids 8-14 with dyslexia/ADHD spend 20+ hours finding specialized tutors who understand their kid's condition. TutorMatch connects them to vetted specialists in 48 hours with parent reviews." Scored 5/5 on customer, 4/5 on problem, 3/5 on approach, 3/5 on money. Weakest blank: approach — doesn't know if parents prefer search-by-specialty or search-by-location. |
+| **1.2a** · Build the Page | Builds a Carrd page with Mixo. Headline: "Reconcile Stripe & QuickBooks in 90 seconds." Hero visual: a 15-second Loom of him pretending to reconcile — manually clicking between two screens while shaking his head. Installs Clarity + LinkedIn pixel. | Builds a NeetoSite page. Headline: "Find a tutor who actually understands dyslexia — 48 hours." Hero visual: a screenshot of her old WordPress booking system with a red X over it. Installs Clarity + Meta pixel. |
+| **1.2b** · Run It & Read Signal | Runs LinkedIn ads at $6 CPC. Spends $1,800 for 300 visits targeting "Controller" and "CFO" job titles at firms with 50-200 employees. Conversion rate: 8% (24 signups). Strong signal — moves to Module 2. | Runs Meta ads at $0.90 CPC. Spends $400 for 300 visits targeting "parent of school-age child" + "learning disability" interests. Conversion rate: 3.5% (11 signups). Lands in the "iterate the message" band. Rewrites her headline from "Find a tutor" to "Your kid's dyslexia tutor — 48 hours, parent-reviewed." Re-tests: 6.5%. Strong signal — moves to Module 2 with a tested headline. |
+| **1.3** · Price Hypothesis | Adds a Stripe price button: "$200/mo — early access." 5% of visitors click the price button (15 of 300). Of those, 3 complete the $1 pre-sale. Weak price signal — the market won't pay $200/mo without seeing the product first. Notes this for Module 5 paid pilots. | Adds a Stripe price button: "$25/mo — early access." 6% of visitors click (18 of 300). Of those, 6 complete the $1 pre-sale. Stronger price signal than Tomas — parents are used to paying for tutoring. |
+
+### Module 2 — Validate the Problem
+
+| Chapter | Tomas outcome | Mia outcome |
+|---|---|---|
+| **2.1** · Mom Test | Runs 10 interviews with accounting firm controllers he found on LinkedIn. Key answers: Q1 — "Last Monday I spent 2 hours exporting QuickBooks to CSV, then matching in Excel. I do it every week." Q2 — "My CFO bills $200/hr and spent 4 hours on it last week. That's $800." Q3 — "I tried Zapier but it breaks every time the invoice format changes." Q4 — "8 out of 10. Only hiring is higher on my plate." Scored 8/10 on 7 interviews. Validated. | Runs 10 interviews with parents from Facebook groups. Key answers: Q1 — "Last Tuesday I spent 3 hours Googling 'dyslexia math tutor near me,' called 4 numbers, 2 were disconnected, 1 had a 6-month waitlist." Q2 — "I missed a client deadline because I was on hold with a tutoring center. That cost me a $2,000 project." Q3 — "I joined 3 Facebook groups and posted 'does anyone know a tutor?' I got 12 replies, half were spam." Q4 — "9 out of 10. The only thing higher is my son's IEP meeting next month." Scored 9/10 on 8 interviews. Strongly validated. |
+| **2.2** · AI Persona Prep | Runs his draft questions through a Claude persona — a skeptical accounting firm controller who has been pitched 3 "automation tools" this year and rejected all of them. The persona flags 2 leading questions. Sharpens them. | Runs her draft questions through a Claude persona — a parent of a 10-year-old with ADHD who has been burned by a tutoring app before. The persona flags 1 question that assumes the parent has time to search. Adds a question about "what happened the last time you tried to book a tutor during a workday?" |
+| **2.3a** · Where to Look | AI ICP map identifies: r/Accounting (300K members), Controller-specific LinkedIn groups, AICPA conference attendees. Builds a 30-name list of controllers who posted about "manual reconciliation" or "month-end close pain" on LinkedIn in the last 90 days. | AI ICP map identifies: Facebook parent groups (ADHD Parent Support, Dyslexia Moms Unite), r/ParentingADHD, local school district special-ed coordinators. Builds a 30-name list of parents who posted about "can't find a tutor" or "tutoring waitlist" in the last 60 days. |
+| **2.3b** · What to Say | Sends the 3-message sequence to 30 controllers on LinkedIn. Message 1 references their specific post about month-end close. Books 12 interviews from 30 reaches (40% — high because Tomas was an accountant and speaks the language). | Sends the 3-message sequence to 30 parents via Facebook DM. Message 1 references their specific post about tutoring frustration. Books 14 interviews from 30 reaches (47% — high because Mia was a teacher and parents trust her). |
+| **2.4** · Clickable Prototype | Builds a 2-hour Lovable prototype: a simple dashboard showing a mock reconciliation — Stripe transactions on the left, QuickBooks invoices on the right, a "match" button in the middle. Shows it to 5 interviewees. 4 say "when can I use this?" 1 says "the match button is confusing — what happens when it's wrong?" | Builds a 2-hour Lovable prototype: a tutor search page with filters (specialty, location, availability) and mock tutor profiles with reviews. Shows it to 5 parents. 4 say "I'd use this tomorrow." 1 says "I need to see reviews before I book — can you add that?" |
+
+### Module 3 — Design from Evidence
+
+| Chapter | Tomas outcome | Mia outcome |
+|---|---|---|
+| **3.1** · Product Brief | Drafts a 1-page brief. Section 1 (Problem): 8 of 10 controllers spend 2+ hours/week on manual reconciliation. Section 2 (Core 3 Jobs): (1) auto-match Stripe to QuickBooks, (2) flag the 5% exceptions that need a human, (3) generate a before/after reconciliation report for month-end close. Section 3 (Outcomes): reduces reconciliation from 2 hours to 90 seconds. Section 4 (Out of Scope): no ERP integrations yet, no multi-currency, no invoice generation — just matching. | Drafts a 1-page brief. Section 1 (Problem): 9 of 10 parents can't find a vetted dyslexia/ADHD tutor in under a week. Section 2 (Core 3 Jobs): (1) search tutors by specialty + location, (2) read parent reviews before booking, (3) book + pay in one flow. Section 3 (Outcomes): reduces time-to-tutor from 20+ hours to 48 hours. Section 4 (Out of Scope): no in-person tutoring coordination, no school district partnerships yet, no tutor training materials. |
+| **3.2** · Quality-check | Rewrites 3 feature-nouns as job stories: "When a Stripe transaction has no matching QuickBooks invoice, I want to see the top 3 candidate matches so I can confirm the right one in one click — not scan 200 line items." Passes the outcome filter: 4 of 5 sections are outcomes, not features. | Rewrites 3 feature-nouns as job stories: "When I search for a math tutor for my 10-year-old with dyslexia, I want to filter by 'dyslexia-trained' and see reviews from other parents of dyslexic kids — not scroll through 50 generic math tutors." Passes the outcome filter: 5 of 5 sections are outcomes. |
+
+### Module 4 — Build It Yourself
+
+| Chapter | Tomas outcome | Mia outcome |
+|---|---|---|
+| **4.1** · Should You Hire? | Runs the decision tree. Validated hypothesis? Yes. Mid-complexity? Yes — needs Stripe API + QuickBooks API + matching logic. Has $200K+ for a team? No — $80K savings. Result: **Fractional CTO bridge** (box 3). Hires a fractional CTO at 5 hrs/week for architecture review, then builds the core himself in Lovable. | Runs the decision tree. Validated hypothesis? Yes. Simple MVP? Yes — search + profiles + booking. 4-8 weeks free? Yes. Result: **Self-serve build** (box 2). Builds the whole thing herself in Lovable + Supabase + Stripe. |
+| **4.2** · Ownership Checklist | Before starting the build, audits all 12 items. Finds: GitHub org is under his personal email (good), but he has no AWS account at all (bad — needs to create one), and his domain is auto-renewing on the registrar he forgot the password to. Spends a Friday fixing all three. Now owns everything. | Before starting the build, audits all 12 items. Finds: owns the domain (good), has a personal GitHub but no org (fixes — creates one), Supabase account under her email (good). Has no secrets manager (creates a 1Password vault). Spends a Friday afternoon. Now owns everything. |
+| **4.3a** · Self-Serve Stack: Tools | Since Tomas chose Fractional CTO bridge, his CTO reviews the self-serve stack and greenlights: Lovable (UI), Supabase (auth + DB), Stripe (payments), n8n (QuickBooks API connector). The CTO writes the RLS policies and the API integration patterns. Tomas builds the UI. | Picks the full self-serve stack: Lovable (UI), Supabase (auth + DB), Stripe (booking payments). Reads the 12 rules checklist. Passes all 12. Starts building. |
+| **4.3b** · Self-Serve Stack: Build | Phase 1 (Lovable UI): builds the reconciliation dashboard in 2 weeks. Phase 2 (Supabase auth): fractional CTO sets up RLS policies — each firm sees only their own data. Phase 3 (Stripe): CTO integrates Stripe subscriptions + QuickBooks API via n8n. Phase 4 (deploy): ships to a custom domain. 6 weeks total. 5 green lights passed. | Phase 1 (Lovable UI): builds the tutor search + profile pages in 1 week. Phase 2 (Supabase auth): sets up parent login + tutor login. Phase 3 (Stripe): integrates booking payments. Phase 4 (deploy): ships to a custom domain. 4 weeks total. 5 green lights passed. |
+| **4.4** · Ceiling Signals | At ~50 firms (paying customers), 2 ceiling signals fire: (1) the reconciliation matching logic has race conditions — a Stripe webhook fires while the QuickBooks sync is running, producing duplicate matches. (2) n8n API connector breaks every time QuickBooks changes their API response format. Graduates from self-serve to fractional CTO → hired team. The fractional CTO was already in place, so the transition is smooth. | At ~200 parents (registered users), 2 ceiling signals fire: (1) search performance degrades — the Supabase query that filters tutors by specialty + location takes 4 seconds at 200 tutors. (2) the booking flow doesn't handle timezone edge cases — a parent in California books a tutor in New York and the confirmation email shows the wrong time. Graduates from self-serve to fractional CTO. Hires one at 5 hrs/week to fix the search query and timezone logic. |
+
+### Module 5 — First Paying Customer
+
+| Chapter | Tomas outcome | Mia outcome |
+|---|---|---|
+| **5.1** · Must-Have Segment | Runs the Sean Ellis survey on his 24 smoke-test signups. Segments by firm size: firms with 50-150 employees score 45% "very disappointed" without it. Firms with 150-200 score 28% — they have in-house tools. Narrows to firms with 50-150 employees. | Runs the Sean Ellis survey on her 21 smoke-test signups. Segments by child age: parents of kids 8-14 with dyslexia score 52% "very disappointed." Parents of kids 14+ score 31% — they've already found workarounds. Narrows to parents of kids 8-14 with dyslexia/ADHD. |
+| **5.2** · Channel Selection | Channel scoring: LinkedIn (9/10 — controllers are there), cold email (8/10 — accounting firms list emails publicly), Reddit (5/10 — r/Accounting is active but noisy). Commits to LinkedIn + cold email. Scoring: 8.0/10. | Channel scoring: Facebook groups (9/10 — parents are there daily), school district referrals (7/10 — slow but high-trust), Instagram (5/10 — visual but hard to target). Commits to Facebook groups + school referrals. Scoring: 8.0/10. |
+| **5.3** · First Ten Customers | 50-name network list: 5 champions (ex-colleagues who complained about reconciliation for years), 10 hot (controllers he met at AICPA conferences), 15 warm (LinkedIn connections in accounting), 20 cold (strangers on r/Accounting). Sends Monday. Gets 8 pilot conversations from 50 messages. 5 say yes. | 50-name network list: 5 champions (teacher friends who have dyslexic kids), 10 hot (parents from her Facebook groups who posted about tutoring), 15 warm (former students' parents), 20 cold (parents who liked her Facebook page). Sends Monday. Gets 12 pilot conversations from 50 messages. 7 say yes. |
+| **5.4** · Paid Pilot | Signs a Design Partner Agreement with 3 accounting firms. Deposit math: B2B financial software → $2,500 deposit (refundable if product doesn't ship within 90 days). Writes the DPA with the deposit clause. 2 of 3 sign and pay within 48 hours. Revenue: $5,000 in committed deposits. | Signs a Design Partner Agreement with 4 parents. Deposit math: B2C parent marketplace → $50 deposit (refundable). Writes a simplified DPA. 4 of 4 sign and pay. Revenue: $200 in committed deposits. Lower deposit, higher volume — consumer math. |
+| **5.5** · Outbound | Runs LinkedIn cold outreach to 30 controllers at firms NOT in his network. Uses the 3-message cold email variant. 12% reply rate (4 replies). Books 2 pilot conversations. 1 signs a paid pilot at $2,500. Paid pilot count: 3 total (2 from network, 1 from cold outreach). Annualized: $30,000 in committed pilot revenue. Goes to investor meetings with evidence. | Runs Facebook group cold outreach to 30 parents NOT in her network. 28% reply rate (8 replies — parents are responsive in community groups). Books 5 pilot conversations. 2 sign at $50. Paid pilot count: 6 total (4 from network, 2 from cold outreach). Monthly recurring: $300 from paid pilots. Goes to pitch a seed round with 6 paying customers. |
+
+---
+
+## Implementation Pattern
+
+In each chapter, add this callout after the main body (before "Further reading"):
+
+```markdown
+> **Case Study: Tomas & Mia**
+>
+> **Tomas** (ReconcileBot, B2B SaaS): [1-2 sentences showing this chapter's technique applied to Tomas, with a concrete outcome.]
+>
+> **Mia** (TutorMatch, B2C marketplace): [1-2 sentences showing this chapter's technique applied to Mia, with a concrete outcome.]
+```
+
+**Rules:**
+- Keep each founder entry to 1-2 sentences. The full arc lives in this reference document; the callout is the scene, not the whole movie.
+- **Exception**: The first-chapter callout (Ch 1.1) can run 3-4 sentences per founder — it introduces them for the first time. All subsequent chapters use the 1-2 sentence rule.
+- Reference concrete numbers when available (prices, percentages, counts).
+- Show the outcome, not just the action. "Got 8% conversion" not "ran the test."
+- Place AFTER the "Done when / Next click / If blocked" footer, BEFORE "Further reading."
+- Do NOT put case studies in the chapter opener or TL;DR — those are reserved for the technique, not the example.
diff --git a/docs/visuals/svg-excalidraw-style-guide.md b/docs/visuals/svg-excalidraw-style-guide.md
new file mode 100644
index 000000000..22e2ca72a
--- /dev/null
+++ b/docs/visuals/svg-excalidraw-style-guide.md
@@ -0,0 +1,390 @@
+# Excalidraw-Style SVG Guide — Course Visuals
+
+Canonical spec for all inline SVGs in the JetThoughts course. Follow these conventions when creating new SVGs. Existing SVGs that don't match should be migrated over time (see Migration Guide below).
+
+## Creative North Star
+
+Hand-drawn whiteboard diagrams that a founder would sketch on a napkin. Imperfect, casual, warm. The roughness signals "this was made by a person, not a design tool." Never polished, never perfect — SVG filters simulate pen-on-paper jitter.
+
+---
+
+## Starter Template
+
+Copy this into a new `.svg` file and replace the placeholder content:
+
+```xml
+
+
+  Replace with descriptive title
+  Optional: what the reader sees and what to compare.
+  
+    
+
+    
+      
+      
+    
+
+    
+      
+      
+    
+  
+
+  
+  
+
+  
+  Your Diagram Title
+  Subtitle or one-line explanation
+
+  
+  
+  Card Title
+  First line of body text
+  Second line of body text
+  
+  Artifact or note
+
+  
+  
+    
+    
+  
+
+
+```
+
+**For system-font SVGs** (decision matrices, dense comparison tables), swap the CSS font stack to:
+
+```css
+.font-title   { font-family: "Segoe UI", system-ui, -apple-system, sans-serif; font-size: 30px; fill: #1a1a1a; font-weight: 700; }
+.font-heading { font-family: "Segoe UI", system-ui, -apple-system, sans-serif; font-size: 24px; fill: #1a1a1a; font-weight: 700; }
+.font-body    { font-family: "Segoe UI", system-ui, -apple-system, sans-serif; font-size: 17px; fill: #1a1a1a; }
+.font-note    { font-family: "Segoe UI", system-ui, -apple-system, sans-serif; font-size: 15px; fill: #555; font-style: italic; }
+```
+
+---
+
+## The Rough Filter (MANDATORY)
+
+Every SVG MUST include these filters in ``. Copy them verbatim from the starter template.
+
+**Primary filter** — for cards, rects, polygons:
+
+```xml
+
+  
+  
+
+```
+
+**Arrow filter** — less jitter so arrowheads stay recognizable:
+
+```xml
+
+  
+  
+
+```
+
+**Apply to**: All rectangles, polygons, lines, and arrows. Do NOT apply to text elements.
+
+**Varying parameters**:
+- `seed`: 2-15. Change only if two overlapping shapes produce identical jitter (rare).
+- `scale`: 2.5 default. Drop to 1.8 for arrows/lines. Bump to 3 for large background rects.
+
+---
+
+## Color Palette
+
+### Core Palette (use these first)
+
+| Token | Fill | Stroke | Usage |
+|-------|------|--------|-------|
+| Indigo | `#eef2ff` | `#4f46e5` · 2.5px | Hypothesis / strategy |
+| Cyan | `#ecfeff` | `#0891b2` · 2.5px | Validation / interviews |
+| Amber | `#fffbeb` | `#d97706` · 2.5px | Design / planning |
+| Ruby red | `#fff5f5` | `#cc342d` · 2.5px | Build / warnings / bad |
+| Green | `#f0fdf4` | `#16a34a` · 2.5px | First customer / good / done |
+
+### Extended Palette (use when core 5 aren't enough)
+
+| Token | Fill | Stroke | When to use |
+|-------|------|--------|-------------|
+| Green (dark) | `#f0f9f0` | `#2e7d32` · 2.5px | Ownership chapters, "correct" answers |
+| Purple | `#fbe9ff` | `#a855f7` · 2.5px | Champions, high-priority tier |
+| Blue | `#e8f4f8` | `#0277bd` · 2.5px | Cloud, infrastructure |
+| Yellow | `#fffbe6` | `#bf8a00` · 2.5px | Validate-without-code quadrant |
+| Gold | `#fff8e0` | `#b8860b` · 2.5px | Warm tier, secrets zone |
+| Purple-light | `#f5e9ff` | `#7c3aed` · 2.5px | Fractional CTO |
+| Gray | `#f0f0f0` | `#666` · 2px, dashed | Cold/dormant tier |
+
+### Background
+
+| Token | Hex | Usage |
+|-------|-----|-------|
+| Paper | `#fafaf7` | Default. Warm off-white. Never sterile `#ffffff`. |
+| Near-white | `#fafafa` | Alternative when `#fafaf7` clashes. |
+
+### Text Colors
+
+| Token | Hex | Usage |
+|-------|-----|-------|
+| Body | `#1a1a1a` | Titles, headings, labels |
+| Secondary | `#444` | Sub-labels, artifact names |
+| Muted | `#555` | Notes, captions |
+| Subtle | `#666` | Italic footnotes |
+| Arrow | `#777` | Arrow labels and shafts |
+
+### Semantic Accents
+
+| Meaning | Color |
+|---------|-------|
+| Bad / wrong / warning | `#cc342d` (ruby red) |
+| Good / correct / done | `#2e7d32` or `#16a34a` (green) |
+| Callout / emphasis | `#a3621e` (brown-gold italic) |
+
+---
+
+## Typography
+
+### Primary: Handwritten (PREFERRED)
+
+Use for conceptual diagrams, bucket frameworks, narrative visuals, and pipeline flows.
+
+```css
+font-family: "Caveat", "Patrick Hand", cursive;
+```
+
+**Size scale** (Caveat runs smaller than system fonts — size up):
+
+| Element | Size | Weight | Color | Line spacing |
+|---------|------|--------|-------|-------------|
+| Page title | 28px | 700 | `#1a1a1a` | — |
+| Subtitle | 16px | 400 italic | `#666` | 24px after title |
+| Card title | 22px | 700 | `#1a1a1a` | — |
+| Section label | 18px | 700 | `#1a1a1a` | 26px after card title |
+| Body / rule text | 16px | 400 | `#1a1a1a` | 22px between lines |
+| Sub-label | 15px | 400 | `#555` | 20px between lines |
+| Artifact / note | 14px | 400 italic | `#444` | 20px between lines |
+| Badge text | 13px | 700 | `#fff` | — |
+| Large number | 38px | 700 | `#cc342d` | — |
+
+### Fallback: System Font
+
+Use only for decision matrices, dense comparison tables, and text-heavy cognitive diagrams where Caveat becomes illegible at small sizes:
+
+```css
+font-family: "Segoe UI", system-ui, -apple-system, sans-serif;
+```
+
+| Element | Size | Weight | Line spacing |
+|---------|------|--------|-------------|
+| Title | 30-34px | 700 | — |
+| Heading | 24-26px | 700 | 32px after title |
+| Body | 17-20px | 400 | 24px between lines |
+| Caption | 16px | 400 italic | 22px between lines |
+| Note | 14-15px | 400 | 20px between lines |
+
+**Decision rule**: If the SVG has more than 15 text elements or text below 14px, use system font. If it's a conceptual diagram, use handwritten. Never mix font families within one SVG.
+
+**`text-anchor` convention**: Page titles and card titles use `text-anchor="middle"` (centered on the card/viewport midpoint). Body text within cards uses `text-anchor="middle"` when cards are narrow (≤200px wide) or left-aligned at `x="card-x + 20"` for wider cards.
+
+---
+
+## Card Conventions
+
+### Shape
+
+```xml
+
+```
+
+- `rx="10"` for standard cards, `rx="12-14"` for larger containers
+- Always include `stroke-linejoin: round` in the CSS class — softens stroke corners to match pen-on-paper feel
+- Always apply `filter="url(#rough)"`
+
+### Casual Rotation
+
+Cards should look placed by hand, not machine-aligned:
+
+```xml
+transform="rotate(-0.3 265 203)"
+```
+
+- **Values**: `-0.4` to `+0.4` degrees. Alternate sign between adjacent cards.
+- **Exception**: Skip rotation for linear pipelines (horizontal card sequences) and comparison matrices where perfect alignment aids readability.
+- The `(cx cy)` is the card center — calculate as `(x + width/2)` and `(y + height/2)`.
+
+### Internal Structure
+
+Every card follows this pattern from top to bottom. Vertical spacing between elements: 22-26px.
+
+1. **Pill badge** (optional) — `rx="6"`, white text on filled background, 13px Caveat 700
+2. **Card title** — 22px Caveat 700, `text-anchor="middle"`, centered on card
+3. **Section label** — 16-18px bold
+4. **Body lines** — 14-16px, 2-4 lines max per card, 22px between lines
+5. **Dashed separator** — `stroke-dasharray="4 3"`, opacity 0.4, match the card stroke color
+6. **Artifact / note** — 14px italic, 20px below separator
+
+### VS Divider Pattern
+
+For side-by-side comparison SVGs (like `good-vs-bad-answers.svg`), use a vertical dashed line with a circle "vs" marker:
+
+```xml
+
+
+vs
+```
+
+---
+
+## Arrows & Connectors
+
+### Hand-drawn arrows
+
+```xml
+
+  
+  
+
+```
+
+- Arrow color: `#777` (muted, never `#000`)
+- Arrow label: 18px Caveat 700, `#777`, placed above the arrow shaft
+- For vertical arrows, adjust polygon points
+
+### Dashed connectors
+
+```xml
+
+```
+
+Use for:
+- Ground lines (e.g., "the ground" in shed-house-skyscraper)
+- VS dividers in comparison diagrams
+- Zone/quadrant boundaries
+
+---
+
+## SVG Viewport
+
+### Standard sizes
+
+| Type | Width | Height |
+|------|-------|--------|
+| Pipeline / flowchart (horizontal) | 1100 | 340 |
+| 4-quadrant matrix | 920 | 620 |
+| 4-zone diagram | 1000 | 620 |
+| Comparison (side-by-side) | 1000 | 640 |
+| Conceptual (single concept) | 960 | 520 |
+| Scoreboard / checklist | 900 | 500 |
+
+### Accessibility
+
+Every SVG MUST have:
+
+```xml
+
+  Descriptive title of what this diagram shows
+  ...
+
+```
+
+For comparison or data-heavy SVGs, add a `` for screen readers:
+
+```xml
+Left side shows a polite hypothetical answer (marked Bad in red). Right side shows a specific past-behavior answer (marked Good in green). Same interviewee, same problem, opposite signal — the question wording decides which answer you get.
+```
+
+---
+
+## Anti-patterns (DO NOT)
+
+| Don't | Why | Do instead |
+|-------|-----|------------|
+| `#ffffff` background | Sterile, looks like a screenshot | `#fafaf7` (warm paper) |
+| No rough filter | Looks machine-generated | Always apply `filter="url(#rough)"` |
+| Mixing Caveat + Segoe UI in one SVG | Jarring inconsistency | Pick one font family per SVG |
+| Pure black text (`#000`) | Too harsh on warm paper | `#1a1a1a` (off-black) |
+| Perfectly aligned cards in conceptual diagrams | Looks like a spreadsheet | Rotate ±0.3° (except pipelines/matrices) |
+| More than 6 cards/sections | Overwhelms the reader | Split into two SVGs |
+| More than 4 lines of text per card | Walls of text kill scannability | Move detail to the chapter body |
+| SVG without `` | Inaccessible | Always include `role="img"` and `aria-labelledby` |
+| `text-anchor="start"` without left-padding | Text touches card edge | Center (`middle`) or pad with `x="card-x + 20"` |
+
+---
+
+## Migration Guide (existing SVGs)
+
+### Priority 1 — font mismatch
+
+These SVGs use Segoe UI but the conceptual content calls for Caveat:
+
+| SVG | Current | Fix |
+|-----|---------|-----|
+| `ownership-zones.svg` | Segoe UI | Swap to Caveat/Patrick Hand |
+| `shed-house-skyscraper.svg` | Segoe UI | Swap to Caveat/Patrick Hand |
+| `decision-matrix.svg` | Segoe UI | **Keep as-is.** Dense matrix with 20+ text elements — system font is correct. |
+| `good-vs-bad-answers.svg` | Patrick Hand | ✅ Already correct |
+| `module-pipeline.svg` | Caveat | ✅ Already correct |
+| `network-buckets.svg` | Caveat | ✅ Already correct |
+
+### Priority 2 — missing rough filter
+
+| SVG | Status |
+|-----|--------|
+| `ownership-zones.svg` | No rough filter — add one |
+| `network-buckets.svg` | No rough filter — add one |
+| `good-vs-bad-answers.svg` | No rough filter — add one |
+| All others | Have rough filter ✅ |
+
+### Priority 3 — missing accessibility
+
+Most course SVGs lack `role="img"`, `aria-labelledby`, and `<title>`. Add during next edit pass. Priority SVGs: `module-pipeline.svg`, `decision-matrix.svg`, `good-vs-bad-answers.svg` (these appear in the most-trafficked chapters).
+
+### Priority 4 — background inconsistency
+
+`good-vs-bad-answers.svg` uses `#fafafa` instead of `#fafaf7`. Swap to match the rest.
+
+---
+
+## Quick Checklist (before shipping an SVG)
+
+- [ ] `#fafaf7` background (never `#ffffff`)
+- [ ] `<filter id="rough">` + `<filter id="rough-arrow">` in `<defs>`
+- [ ] Rough filter applied to all shapes (not text)
+- [ ] `stroke-linejoin: round` on all card stroke classes
+- [ ] Font stack matches content type (handwritten for concepts, system for dense matrices)
+- [ ] Cards rotated ±0.2° to 0.4° (alternating) — **unless** it's a pipeline or matrix
+- [ ] Card fills from the core palette first, extended palette only when needed
+- [ ] Text uses `#1a1a1a` (never `#000`, never `#ffffff` for body)
+- [ ] Arrows use `#777` with `filter="url(#rough-arrow)"` and poly arrowheads
+- [ ] Dashed separators use `stroke-dasharray="4 3"` at opacity 0.4
+- [ ] Text spacing: 22px between body lines, 26px heading→body, 20px separator→note
+- [ ] No more than 6 cards/rects, no more than 4 lines per card
+- [ ] `<title>` with descriptive text + `role="img" aria-labelledby`
+- [ ] Viewport matches one of the standard sizes
+- [ ] One font family per SVG — never mix Caveat and Segoe UI
diff --git a/docs/workflows/course-chapter-pipeline.md b/docs/workflows/course-chapter-pipeline.md
new file mode 100644
index 000000000..8f14f0757
--- /dev/null
+++ b/docs/workflows/course-chapter-pipeline.md
@@ -0,0 +1,394 @@
+# Course Chapter Writing Pipeline
+
+Canonical pre-write + during-write guide for chapters in the **From Idea to First Paying Customer** course (`content/course/tech-for-non-technical-founders-2026/`, formerly "Tech for Non-Technical Founders 2026"). Built from 35+ documented regressions, 3-agent ICP audits, and the voice guide.
+
+**Companion docs (do not duplicate):**
+- `docs/projects/2605-tech-for-non-technical-founders/50-59-execution/mechanical-audit-checklist.md` — post-write audit with Cases 1-35
+- `docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md` — JT voice rules + banned structural patterns
+- `content/course/tech-for-non-technical-founders-2026/_index.md` — module index + landing page
+
+---
+
+## When to use this doc
+
+Apply BEFORE writing any new chapter, BEFORE drafting structural revisions, and BEFORE merging anyone else's chapter edits into a course chapter. Skim section 1-3 every time; deep-read sections 4-12 on first chapter draft.
+
+If you're doing a 1-sentence fix (typo, price update, link swap), this doc is overkill — apply the surgical-edit discipline from CLAUDE.md and ship.
+
+---
+
+## 1. The Course ICP — read FIRST every time
+
+The course ICP is **"Sam"**, not the website ICP "Alex the burned founder". Confusing the two has cost multiple revision passes.
+
+| Attribute | Sam (course ICP) | Alex (website ICP) |
+|---|---|---|
+| Stage | Idea-stage, no team yet | Post-team-fail, mid-rescue |
+| Money | ~$20K personal savings | Has burned $50K-$500K with a shop |
+| Time | Lunch breaks + nights/weekends, still has day job | Full-time on the company |
+| Software experience | Has NEVER hired a developer, signed an SOW, shipped to production | Has hired, has shipped, has been burned |
+| Tech vocab | Reads Stripe + finance docs fluently. Doesn't know what GitHub, AWS, Postgres are | Has been told 100 jargon words by 100 contractors |
+| Goal | Get to first paying customer without burning the savings | Recover or rebuild what the team broke |
+
+**Rule:** every chapter body is for Sam. Rescue/triage chapters (e.g. ownership audit, salvage-vs-rebuild) live in the course but must self-frame as "this also works as a Day-1 preventive" or "this is a side-path for active rescue" so Sam recognizes the chapter applies to him.
+
+**The ICP-reader read-back gate (BLOCKING):** before handback, re-read the edited chapter top-to-bottom AS Sam. Confirm (1) every acronym/tool/term is glossed at FIRST mention, (2) orientation blocks don't front-load thresholds/metrics, (3) the opener doesn't lead with a scenario Sam can't picture himself in.
+
+---
+
+## 2. Pre-write mandatory reads
+
+1. **`docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md`** — voice, banned words, Cases 1-35 banned structural patterns
+2. **`docs/projects/2605-tech-for-non-technical-founders/50-59-execution/mechanical-audit-checklist.md`** — Cases 1-35 + read-back items
+3. **`content/course/tech-for-non-technical-founders-2026/_index.md`** — module index, where your chapter fits in the linear path
+4. **The previous chapter (M.N-1) and next chapter (M.N+1)** — read their declared Input/Output so your chapter's handoff is clean
+5. **`docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.05-content-organization-patterns-2026.md`** Part 2 — cognitive load + F-pattern rules
+
+---
+
+## 3. Chapter structure — the required skeleton
+
+Every chapter follows this skeleton. Sections marked **REQUIRED** are non-negotiable.
+
+```
+---
+Frontmatter (REQUIRED)
+---
+
+> Module X · Step N of M · [course landing link]  (REQUIRED orientation callout)
+>
+> Input: [exact artifact from previous chapter]  (REQUIRED)
+>
+> Output: [exact artifact this chapter produces]  (REQUIRED)
+
+[Opener: 1-2 paragraphs. Either (a) named-founder vignette, (b) stat-anchored hook,
+ (c) definitional opener, (d) principle-statement, or (e) direct second-person.
+ NEVER the same opener template as the chapter before AND after you (rotation gate).]
+
+[Optional hero visual — Mermaid diagram or sketchy SVG. Hand-drawn aesthetic, NOT polished
+ corporate infographic. Must be informational, not decorative.]
+
+[Body sections — each ## H2 has one job. Each section starts with its main point in
+ sentence 1, then evidence, then one actionable takeaway.]
+
+## What to do tomorrow  (REQUIRED in every chapter — Sam's next concrete action)
+
+[3-5 numbered actions Sam can take Monday morning. Each names: time budget, $ cost,
+ the failure signal that means "stop and pivot."]
+
+## Further reading  (OPTIONAL — for Sam who wants to go deeper)
+```
+
+### Frontmatter requirements
+
+| Field | Required | Rule |
+|---|---|---|
+| `title` | yes | "**N.M** · [Chapter Name]" — chapter number in YAML matches landing-page module index |
+| `description` | yes | 140-160 chars, mentions "Chapter N.M of this course" |
+| `date` | yes | Real date, not future (Hugo hides future-dated content) |
+| `draft` | yes | `false` for published; `true` for in-progress (still runs full pipeline) |
+| `author` | yes | "JetThoughts Team" |
+| `slug` | yes | URL-friendly, never change after publish |
+| `cover_image` + `cover_image_alt` | yes | Cover image is source of truth for proof points (don't echo cover counts in body) |
+| `metatags.og_title` + `og_description` | yes | Must match `title` / `description` thematically — drift breaks social cards |
+
+---
+
+## 4. Voice — DO and AVOID
+
+### DO
+
+- **Every sentence needs a human subject doing something.** "The migration broke" → "The contractor's migration broke at 3am because the staging DB had no foreign keys."
+- **Use - not — for all dashes.** Em-dashes are a documented AI tell.
+- **Show, don't tell.** Replace adjectives with concrete scenarios the reader can picture.
+- **Practitioner-level specifics.** Named clients (anonymized OK), exact dollar amounts, exact timelines, exact failure mechanics.
+- **Trade-off honesty.** Every chapter names what the proposed approach FAILS to do or costs.
+- **90/10 rule.** ≥90% education, ≤10% promotion. Sam should learn something useful even if he never contacts JetThoughts.
+
+### AVOID — zero tolerance (reject on sight)
+
+| Pattern | Example | Fix |
+|---|---|---|
+| Rule of three | "It's faster, cheaper, and simpler." | Drop one or vary the structure |
+| Triple rhetorical questions | "What if you could? What if it worked? What if it was free?" | Cut to one specific question |
+| Slogany flips | "It looks free. It isn't." or "X works. Y doesn't." | Plain prose |
+| Slogany reveal-twists | "The hypothesis hadn't been wrong - the questions had been." | Drop the twist, state the mechanic |
+| Negative parallelism | "No tests. Open endpoints. Corrupted data." | One full sentence with a subject |
+| Impersonal fragment stacking | "React + Rails, clean conventions, the demo sailed." | Add a human subject |
+| Sustained staccato | 3+ consecutive short fragments | Vary sentence length |
+| Command-structure repetition | 3+ paragraphs starting with imperatives ("You build... You add... You write...") | Collapse to one noun-phrase |
+| Apologetic caveats | "every project is different", "it depends on the use case" | Cut entirely |
+| Therapist voice | "It's okay to feel overwhelmed." | Cut entirely |
+| Fluffy AI narration | "The alerts fire correctly. Then someone upgrades..." (dramatic present-tense) | Past tense, named incident |
+| Fake authority generalization | "We've seen this on every codebase" | Specific count: "The last three codebases we inherited..." |
+| Cinematic time-cuts | "Nine months later: a product, a $62K dev invoice, zero paying customers" | Drop the cut, state the outcome plainly |
+| Cute aphoristic flourish | "polite noise", "the kind smile that costs you a year" | Cut entirely |
+| Cost-stacked tri-list opener | "$25-$100 in incentives, 40 minutes of calendar, one of the 10 slots" | One sentence with one concrete cost |
+| Fabricated cohort stats | "4 of 5 real interviewees", "30-45% reply rates" | Use real measured numbers OR drop the stat |
+| Year-stamp fabrication | "Last year" without checking if the technology existed then | Verify timeline against real history |
+| Banned heading "## Why this matters in 2026" / "## Why this matters more in 2026" | Case 25 | Use a heading that names the SPECIFIC content of the section |
+| "Founders who..." / "Most founders..." | Case 16 — cap ≤2 per chapter | Reframe with named scenario or direct address |
+| "A founder we worked with..." template opener | Case 17 — cap ≤1 chapter in 3 consecutive | Rotate opener shape across chapters |
+| `## Why this matters` / `Founders who skip` / `Most founders` | Case 25 + 16 — grep regression sweep is BLOCKING before handback | See section 13 |
+
+---
+
+## 5. Practicality — the Monday-morning test
+
+Every chapter must pass these 4 practicality gates:
+
+1. **Time budget declared and honest.** "90-minute sprint" must actually take 90 minutes. "4-week ship plan" must be the build portion only; don't roll in validation weeks.
+2. **$ budget declared.** Even $0 chapters must say "$0" explicitly. Sam needs to know whether to open his wallet.
+3. **Concrete next action.** "Open X, do Y, by Friday." Not "consider", not "explore", not "think about."
+4. **Failure mode named.** Tell Sam what FAILURE looks like: "if 0 of 35 click", "if 9 of 10 say yes politely", "if 2 test users stall on screen 1-2." Sam's intuition is unreliable at idea stage — the chapter must provide the diagnostic signal.
+
+**Cumulative time anchor (BLOCKING for any chapter declaring time):** state where the chapter fits in the 8-12-week / 40-60-hour journey from idea to first paying customer. Don't let Sam infer "8 hours total" from the per-chapter callouts.
+
+---
+
+## 6. Pedagogy — progressive disclosure + scaffolding
+
+1. **Orientation before body.** Input/Output/time/cost callout BEFORE any prose. Sam knows what he's getting into before he commits to reading.
+2. **Progressive disclosure.** Concepts in the order Sam needs them. NEVER reference a tool, term, or framework before glossing it on first mention. "Pick Lovable Pro" only AFTER "Lovable is an AI app builder, free trial, paid plans from $20/mo."
+3. **Scaffolding from previous chapter.** Accept the previous chapter's declared Output as your Input. Don't ask Sam to re-derive anything. If Chapter N.M produces "10 ICP interviewees booked", Chapter N.M+1 starts with "Given your 10 booked interviewees...", not "Now book 10 interviewees..."
+4. **One walked-through example per chapter.** Frameworks + tables + bullets are necessary but NOT sufficient. Include ONE full example end-to-end (named persona, real numbers, named outcome). M1.1's Gmail 2003 example and M3.1's freelance-bookkeeper example are the gold standard.
+
+### Inter-chapter handoff audit (BLOCKING for any structural change)
+
+For each chapter you touch, verify:
+- Does the previous chapter's Output match your declared Input verbatim?
+- Does the next chapter's Input match your declared Output verbatim?
+- Are there any "see Chapter X" deferrals that ask Sam to tab-switch for required content? Inline it instead.
+
+---
+
+## 7. Tool glossary policy (BLOCKING)
+
+Every tool/acronym needs a one-line gloss at **first mention in each chapter** (not just first mention in the course). Sam may land on any chapter via Google search.
+
+Gloss format: `[Tool name] (what it is + free/paid status + key constraint if any)`.
+
+Examples:
+- ✅ "Lovable (an AI app builder that generates a working web app from English prompts - free trial, paid plans from $20/month, no coding required)"
+- ✅ "Supabase (a managed database + login service that stores users and data - free tier covers early-stage usage, paid plans from $25/month)"
+- ✅ "MFA = Multi-Factor Authentication (the 6-digit code your phone shows when you log in - a second proof beyond your password)"
+- ❌ "Lovable (see the gloss in Chapter 4.3)" — deferral fails the search-landing test
+- ❌ "Use RLS to enforce isolation" — RLS unglossed
+- ❌ "the webhook fires" — webhook unglossed for Sam
+
+**Common terms requiring gloss on first mention in each chapter:**
+Lovable · Supabase · Stripe (mostly assumed background, but webhook needs gloss) · Carrd · Notion · Loom · GA4 · Microsoft Clarity · ad-platform pixel · webhook · RLS · MFA · IAM · WHOIS · ICANN · ICP · CR · OAuth · SAML · SOC2 · HIPAA · PCI · ORM · JWT · BOLA · CSV
+
+---
+
+## 8. Visual + cognitive-load rules
+
+Apply for any chapter > 800 words.
+
+### Required
+- **First-3-seconds visual hook** — every long-form chapter needs a visual within the first viewport. Hero diagram, infographic, or strong styled callout. Pure-text hero = 71% dropout per Pew 2026.
+- **One visual break per H2.** Plain prose blocks across 3+ consecutive H2s = density problem.
+- **Labels INSIDE diagrams**, not beside them. If a diagram needs a 200-word "what this shows" paragraph, fix the diagram.
+
+### Forbidden
+- Decorative photography ("happy founders at laptops")
+- Generic abstract gradients
+- Icon arrays without informational content
+- Polished corporate infographics — JT brand uses hand-drawn / Excalidraw / sketchy-Mermaid aesthetic
+
+### Mermaid + SVG width constraint
+Article column is **684px max**. Pre-check width budget BEFORE designing:
+- Mermaid LR with ≥5 nodes will fail
+- SVG with prose-text rows will clip
+- 5-column tables will overflow on mobile
+Use TD orientation (top-down) for tall diagrams or compress nodes.
+
+### Visual verification gate (BLOCKING for any new visual)
+After adding any Mermaid/SVG/image/table/callout:
+1. Take chrome-devtools screenshots at desktop (1280×800) AND mobile (390×844)
+2. Score honestly against 4 criteria:
+   - Is it a great look? (harmony, contrast, alignment)
+   - Is it functional? (readable without zoom, mobile renders)
+   - Would it make Sam want to read more?
+   - Is it helpful overall? (teaches vs decorates)
+3. Any NO on criteria 3 or 4 = ROLLBACK before commit
+
+---
+
+## 9. Cold-eyes review gate (BLOCKING before handback)
+
+For any new chapter OR structural revision, dispatch 3-4 parallel critic agents BEFORE marking the work done.
+
+Personas (specialized agents per `feedback_agent_selection_bias`):
+1. **`voltagent-biz:ux-researcher`** — ICP-Sam reader-fit. Does Sam recognize himself? Is he at the right stage? Are tools glossed? Does he know what to do?
+2. **`voltagent-biz:content-marketer`** — Monday-morning practicality. Time honest? $ named? Concrete action? Failure mode named?
+3. **`tutorial-engineer`** — Pedagogical effectiveness. Orientation OK? Progressive disclosure? Scaffolds from previous? Worked example?
+4. **AI-feel detector** (any critic with the voice-guide pattern list) — Cases 1-35 regression sweep.
+
+**Process the panel in parallel** — single message, 3-4 Agent tool calls.
+
+**Synthesize convergent vs divergent:** issues flagged by ≥2 agents are high-confidence fixes. Single-agent flags are judgment calls.
+
+**Codex cross-check (per CLAUDE.md):** for structural changes touching ≥3 files, dispatch `codex:codex-rescue` as the 4th independent reviewer. Surface what Codex said BEFORE applying.
+
+---
+
+## 10. Post-write checklist
+
+Run these in order. Any failure blocks handback.
+
+### Mechanical (machine-checked)
+- [ ] `bin/validate-course` — 7 validators pass (disclaimer-consistency, no-em-dash, year-stamp-fabrication, chapter-number-consistency, title-yaml-match, internal-link-existence, table-width)
+- [ ] `bin/hugo-build` — no Hugo errors, page renders
+- [ ] No em-dashes (`grep "—" content/course/...`)
+
+### Banned-pattern regression sweep
+- [ ] `grep -rn "## Why this matters\|Founders who\|Most founders\|Founders we worked with\|A founder we worked\|A founder we picked\|A founder we spoke" content/course/tech-for-non-technical-founders-2026/your-chapter-slug/`
+- [ ] Any hit on `## Why this matters` (Case 25) = BLOCKING fix
+- [ ] >2 "Founders who" / "Most founders" hits per chapter (Case 16) = BLOCKING fix
+- [ ] Same opener template as ≥2 adjacent chapters (Case 17) = BLOCKING fix
+
+### ICP read-back
+- [ ] Read the chapter top-to-bottom AS Sam
+- [ ] Every tool/acronym glossed at first mention in THIS chapter
+- [ ] Orientation block doesn't front-load thresholds/metrics
+- [ ] Opener doesn't lead with a scenario Sam can't picture himself in
+- [ ] "What to do tomorrow" section has concrete actions with time + $ + failure signal
+
+### Inter-chapter handoff
+- [ ] Declared Input matches previous chapter's declared Output
+- [ ] Declared Output matches next chapter's declared Input
+- [ ] No "see Chapter X" deferrals for content Sam needs in-chapter
+
+### Visual gate
+- [ ] Hero visual within first viewport
+- [ ] Chrome-devtools verified at desktop + mobile
+- [ ] Scored 4 criteria honestly; no NO on items 3 or 4
+
+### Cold-eyes panel
+- [ ] 3-4 parallel critics dispatched
+- [ ] Convergent issues surfaced to user
+- [ ] Surgical fixes applied (NOT page-bombing rewrites)
+
+---
+
+## 11. Inter-chapter consistency
+
+Course-level rules that span multiple chapters.
+
+### Opener-shape rotation gate (BLOCKING)
+No 3+ consecutive chapters in the same module may share the same opener shape. Templates to rotate:
+- Named-founder vignette ("Maya, a founder we worked with...")
+- Anonymous-founder vignette ("A founder we picked up...")
+- Stat-anchored ("Eleven interviews, nine 'yes...'")
+- Dollar-anchored ("Fourteen months of $23K monthly invoices...")
+- Definitional ("**Vibe Coding** is shipping a real product with AI-generated code...")
+- Principle-statement ("This is interview recruitment, not sales.")
+- Direct second-person ("You have an idea, or a half-built MVP...")
+
+### Cross-post signal portfolio
+Each chapter owns ONE primary diagnostic signal — don't repeat the same lead signal across cluster chapters. M1.2 owns "smoke-test CR%". M2.3 owns "Mom Test scoring rubric". M3.1 owns "one-page brief sections". M4.3 owns "4-week ship plan demos". M4.4 owns "5 ceiling signals scoreboard."
+
+### Anecdote scan
+Before finalizing, grep cluster chapters for repeated named clients, dollar amounts, technical mechanics. The URL-ID/BOLA story repeated across cluster posts in May 2026 was caught by this scan.
+
+---
+
+## 12. Surgical edit discipline (BLOCKING for content edits)
+
+When the user flags ONE attribute (a price, a tool name, a heading, a year-stamp):
+- Change ONLY the sentences containing that attribute
+- Do NOT rewrite, re-balance, or re-theme the surrounding chapter
+- Name the chapter's thesis in one line first and confirm it's unchanged
+- If a fix seems to need touching >1 paragraph or the structure, STOP and ask before expanding scope
+
+When correcting a stance the user called too far one way: land at the documented middle. Do NOT swing to the opposite extreme. (The budget free→paid→balanced pendulum cost 4 round-trips on 2026-05-22.)
+
+Before handback, grep your OWN replacement text for the exact pattern you just removed (year-stamp, banned word, hardcoded tool name) — re-introducing the defect you're fixing is a blocking failure.
+
+---
+
+## 13. Common regressions — the grep sweep
+
+Run this before every handback. Any hit triggers a Tier-1 fix.
+
+```bash
+# Case 25 banned headings (zero tolerance)
+grep -rn "## Why this matters" content/course/tech-for-non-technical-founders-2026/
+
+# Case 16 generalized actor (cap ≤2 per chapter)
+grep -rni "most founders\|founders who" content/course/tech-for-non-technical-founders-2026/your-chapter/
+
+# Case 17 founder-vignette template (rotate across chapters)
+grep -rn "A founder we worked\|A founder we picked\|A founder we spoke\|founder we sat with" content/course/tech-for-non-technical-founders-2026/
+
+# Em-dashes (banned)
+grep -rn "—" content/course/tech-for-non-technical-founders-2026/your-chapter/
+
+# Apologetic caveats (banned)
+grep -rni "every project is different\|depends on the use case\|your mileage may vary" content/course/tech-for-non-technical-founders-2026/your-chapter/
+
+# Cumulative time-banner present on long-build chapters
+grep -n "8-12 weeks\|40-60 hours" content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/index.md
+```
+
+---
+
+## 14. Banned patterns reference (Cases 1-35)
+
+Full catalog in `docs/projects/2605-tech-for-non-technical-founders/50-59-execution/mechanical-audit-checklist.md`. Critical subset:
+
+| Case | Pattern | Cap |
+|---|---|---|
+| 16 | "Founders who..." / "Most founders..." generalization | ≤2 per chapter |
+| 17 | "A founder we worked with..." anonymous-vignette opener | ≤1 in any 3 consecutive chapters |
+| 25 | "## Why this matters in 2026" / "## Why this matters more in 2026" heading | 0 (banned outright) |
+| 32 | Command-structure repetition (3+ "You verb" sentences in a row) | 0 |
+| 33 | Cinematic time-cut ("Nine months later:") | 0 |
+| 34 | Cute aphoristic flourish ("polite noise") | 0 |
+| 35 | Anonymous-named-founder opener template repeated 3+ consecutive | 0 |
+
+---
+
+## 15. What NOT to do (anti-patterns documented from incidents)
+
+- **Don't page-bomb on a 1-attribute fix.** The user flagged "make this price clearer" once → I rewrote 3 paragraphs. Lost 2 hours. Cap edits to sentences containing the flagged attribute.
+- **Don't trust the implementer subagent's self-review for voice quality.** They wrote the content; they can't cold-eyes review it. Always dispatch independent critics.
+- **Don't skip the regression grep because "slop score is low."** Slop detector misses shape-tells. Voice regressed M1-M3 on 2026-05-28 despite slop score = 22/100 across all 9 chapters.
+- **Don't add `## Why this matters` headings.** Removed 3 times across 9 chapters; regressed once. Use a heading that names the SPECIFIC content of the section ("Your real question: do you need to build at all", "Who this 5-signal check is for", etc.).
+- **Don't change publish dates on a fix/republish pass.** Old date is part of the historical record.
+- **Don't bundle tactical fixes with structural moves in one commit/edit batch.** Separate approval gates required.
+- **Don't apply structural changes without explicit user approval.** Apply only after surfacing convergent findings + 1 recommendation.
+- **Don't write Sam's chapter in Alex's voice.** Course ICP is Sam (idea-stage). Rescue framing is wrong-audience.
+
+---
+
+## 16. What TO do (validated patterns from successful chapters)
+
+M1.1 (Form Your Founding Hypothesis) and M3.1 (One-Page Product Brief) are the gold-standard templates. Reference them when writing new chapters:
+
+- M1.1: orienting callout → narrative hook → framework → 4 worked examples (Gmail 2003, chiropractic billing, allergy-parent, procurement matrix) → 4-lens scoring → trade-off acknowledgement → next-chapter handoff
+- M3.1: orienting callout → audience table → 5 sections → freelance-bookkeeper carried through ALL 5 sections as one worked example → outcome-shaped feature spec
+
+Use these as the structural template. Don't invent new structures for chapters that fit one of these two patterns.
+
+---
+
+## Quick reference
+
+| Action | Command / file |
+|---|---|
+| Run mechanical validators | `eval "$(rbenv init -)" && bin/validate-course` |
+| Build site | `bin/hugo-build` |
+| Banned-pattern sweep | `grep -rn "## Why this matters\|Founders who\|Most founders\|A founder we" content/course/tech-for-non-technical-founders-2026/` |
+| Cold-eyes panel | 3 parallel Agent calls — ux-researcher + content-marketer + tutorial-engineer |
+| Voice guide | `docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md` |
+| Banned patterns catalog | `docs/projects/2605-tech-for-non-technical-founders/50-59-execution/mechanical-audit-checklist.md` |
+| Course ICP profile | This doc, section 1 |
+| Project plan | `docs/projects/2605-tech-for-non-technical-founders/` |
+
+---
+
+## Change log
+
+- **2026-05-29** — Initial version built from 3-agent M1-M4 audit, 35 mechanical audit cases, and 30+ documented memory feedback items.
diff --git a/docs/workflows/linkedin-post-pipeline.md b/docs/workflows/linkedin-post-pipeline.md
index 90498b517..ce62a53cc 100644
--- a/docs/workflows/linkedin-post-pipeline.md
+++ b/docs/workflows/linkedin-post-pipeline.md
@@ -360,6 +360,7 @@ When asked to write a LinkedIn post for Paul:
 - [ ] If score >2/10: run sentence-by-sentence pass (Editing methodology §1)
 - [ ] Run story-flow fluency test (read aloud, listen for connectors at seams)
 - [ ] If campaign post or first in sequence: spawn multi-critic review (Editing methodology §3)
+- [ ] If the user flags the same draft as "AI", "sales-y", "fluffy", or "not human" a SECOND time, spawn multi-critic review (Editing methodology §3) BEFORE iterating again. Solo revision past the second user pushback consistently misses pattern-level tells (cinematic beat-marking, omniscient framing, copywriter shape) that single-pass review keeps missing — observed on the 2026-05-11 Monday Jira-not-progress post, which needed 5 solo passes after the AI rubric scored 0/10.
 - [ ] Run frontmatter-to-body consistency check (Editing methodology §4)
 - [ ] No marketing CTA, no JT mention, no website link
 - [ ] No "learned the hard way" framing, no credential stamps
diff --git a/layouts/course/list.html b/layouts/course/list.html
new file mode 100644
index 000000000..b479c00de
--- /dev/null
+++ b/layouts/course/list.html
@@ -0,0 +1,50 @@
+{{ define "header" }}
+  {{- $CSS := slice
+    (resources.Get "css/critical/base.css")
+    (resources.Get "css/3059-layout.css")
+    (resources.Get "css/bf72bba397177a0376baed325bffdc75-layout-bundle.css")
+    (resources.Get "css/dynamic-icons.css" | resources.ExecuteAsTemplate "css/dynamic586.css" .)
+    (resources.Get "css/586.css")
+    (resources.Get "css/vendors/base-4.min.css")
+    (resources.Get "css/style.css")
+    (resources.Get "css/skin-65eda28877e04.css")
+    (resources.Get "css/single-post.css")
+    (resources.Get "css/footer.css")
+  -}}
+  {{ partial "assets/css-processor.html" (dict "resources" $CSS "bundleName" "course-list" "context" .) }}
+{{ end }}
+
+{{ define "main" }}
+  <div id="fl-main-content" class="blog" role="main">
+    <div class="fl-row-content fl-row-fixed-width">
+      <article
+        class="single-content"
+        style="max-width: 720px; margin:0 auto; padding-left:18px;padding-right:18px">
+        <header>
+          <h1 class="fl-heading">{{ .Title }}</h1>
+          {{ with .Params.description }}
+            <p class="post-meta-byline" style="margin-top:0.5rem">{{ . }}</p>
+          {{ end }}
+
+          {{/* Cover image */}}
+          {{ with .Resources.GetMatch "cover.*" }}
+            <figure class="post-cover-figure" style="margin: 1.25rem 0; max-width: 43rem;">
+              <img
+                class="post-cover"
+                src="{{ .RelPermalink }}"
+                alt="{{ $.Params.cover_image_alt | default $.Title }}"
+                width="{{ .Width }}"
+                height="{{ .Height }}"
+                loading="eager"
+                fetchpriority="high" />
+            </figure>
+          {{ end }}
+        </header>
+
+        <div class="post-content" itemprop="text">
+          {{ .Content }}
+        </div>
+      </article>
+    </div>
+  </div>
+{{ end }}
diff --git a/lib/course_validators.rb b/lib/course_validators.rb
new file mode 100644
index 000000000..a8a5e002d
--- /dev/null
+++ b/lib/course_validators.rb
@@ -0,0 +1,351 @@
+# frozen_string_literal: true
+
+# Source-of-truth validators for the Tech for Non-Technical Founders 2026 course.
+# Each validator reads course chapters from disk and reports violations.
+#
+# Hook locations: bin/hugo-build (pre-flight), Rakefile tasks, CI pipeline.
+# Usage: CourseValidators.run_all => [Result, ...]
+#
+# Reference: TASK-TRACKER.md P1 - "Build 4 source-of-truth validators (Kaizen Muda outcome)"
+
+require "yaml"
+require "set"
+
+class CourseValidators
+  COURSE_DIR = "content/course"
+  YAML_PATH = "data/course_sequence.yaml"
+  ALL_BLOG_DIR = "content/blog"
+
+  Result = Struct.new(:name, :passed, :violations, keyword_init: true) do
+    def to_s
+      status = passed ? "PASS" : "FAIL"
+      "#{status}  #{name}#{violations.any? ? "\n  #{violations.join("\n  ")}" : ""}"
+    end
+  end
+
+  def self.run_all
+    new.run_all
+  end
+
+  def run_all
+    [
+      check_chapter_number_consistency,
+      check_title_yaml_match,
+      check_internal_links,
+      check_table_width,
+      check_disclaimer_consistency,
+      check_em_dash_in_content,
+      check_year_stamp_fabrication
+    ]
+  end
+
+  private
+
+  # ── Validator 1: Chapter-number consistency ──────────────────────────────
+  # Every "Chapter N.X" reference in body/frontmatter/SVG must resolve to an
+  # entry in data/course_sequence.yaml.
+
+  def check_chapter_number_consistency
+    violations = []
+    valid_chapters = build_valid_chapter_set
+
+    course_chapters.each do |path|
+      slug = File.basename(File.dirname(path))
+      body = File.read(path)
+
+      # Find all "Chapter N.X" patterns in the body (not inside URLs or code blocks)
+      body.scan(/Chapter\s+(\d+\.\d+)/) do |match|
+        ref = match.first
+        unless valid_chapters.include?(ref)
+          violations << "#{slug}: references 'Chapter #{ref}' which is not in course_sequence.yaml"
+        end
+      end
+
+      # Also check "Module N" callout references (e.g., "> **Module 1 · Step 2 of 3**")
+      body.scan(/> \*\*Module\s+(\d+)\s/) do |match|
+        module_num = match.first
+        # Module N should correspond to Chapter N.X
+        # Extract the chapter number from the title frontmatter
+        fm = parse_frontmatter(path)
+        next unless fm["title"]
+        title_match = fm["title"].match(/(\d+)\.(\d+)/)
+        next unless title_match
+        expected_module = title_match[1]
+        if module_num != expected_module
+          violations << "#{slug}: callout says 'Module #{module_num}' but title '#{fm["title"]}' starts with #{expected_module}"
+        end
+      end
+    end
+
+    # Check SVG files for stale chapter references (recursive for nested course structure)
+    Dir["#{COURSE_DIR}/**/*.svg"].each do |svg_path|
+      slug = File.basename(File.dirname(svg_path))
+      content = File.read(svg_path)
+
+      content.scan(/Chapter\s+(\d+\.\d+)/) do |match|
+        ref = match.first
+        next if ref == "Chapter 0.0" # Skip any default/placeholder
+        unless valid_chapters.include?(ref)
+          violations << "#{slug}/#{File.basename(svg_path)}: SVG references 'Chapter #{ref}' which is not in course_sequence.yaml"
+        end
+      end
+    end
+
+    Result.new(name: "chapter-number-consistency", passed: violations.empty?, violations: violations)
+  end
+
+  # ── Validator 2: Title-YAML byte-for-byte match ──────────────────────────
+  # Frontmatter title / og_title must START WITH the YAML title for that slug.
+  # The callout prefix must match the chapter number.
+
+  def check_title_yaml_match
+    violations = []
+    yaml_map = build_yaml_title_map
+
+    course_chapters.each do |path|
+      slug = File.basename(File.dirname(path))
+      fm = parse_frontmatter(path)
+      yaml_entry = yaml_map[slug]
+
+      # Supplementary chapters (course_chapter: true but not in the linear sequence)
+      # are not in the YAML. Skip them for the title-match check - they have their
+      # own title scheme outside the X.Y · Foo convention.
+      next unless yaml_entry
+
+      yaml_title = yaml_entry["title"]
+      fm_title = fm["title"]
+      fm_og_title = fm.dig("metatags", "og_title") || fm["og_title"]
+
+      # Check frontmatter title starts with YAML title
+      if fm_title && !fm_title.start_with?(yaml_title)
+        violations << "#{slug}: frontmatter title '#{fm_title}' does not start with YAML title '#{yaml_title}'"
+      end
+
+      # Check og_title starts with YAML title
+      if fm_og_title && !fm_og_title.start_with?(yaml_title)
+        violations << "#{slug}: og_title '#{fm_og_title}' does not start with YAML title '#{yaml_title}'"
+      end
+
+      # Check callout chapter number matches YAML module
+      body = File.read(path)
+      callout_match = body.match(/> \*\*Module\s+(\d+) · Step (\d+) of (\d+)\*\*/)
+      if callout_match
+        step_num = callout_match[2]
+        total_steps = callout_match[3]
+
+        # YAML module field is like "Chapter 1.1"
+        yaml_module = yaml_entry["module"]
+        chapter_match = yaml_module.match(/(\d+)\.(\d+)/)
+        next unless chapter_match
+
+        yaml_chapter_num = chapter_match[2]
+        if step_num != yaml_chapter_num
+          violations << "#{slug}: callout says 'Step #{step_num}' but YAML module '#{yaml_module}' has chapter #{yaml_chapter_num}"
+        end
+      end
+    end
+
+    Result.new(name: "title-yaml-match", passed: violations.empty?, violations: violations)
+  end
+
+  # ── Validator 3: Internal-link existence ─────────────────────────────────
+  # Every /blog/slug/ link in course chapters must resolve to an existing
+  # content/blog/slug/index.md.
+
+  def check_internal_links
+    violations = []
+    course_slugs = build_course_slug_set
+
+    course_chapters.each do |path|
+      slug = File.basename(File.dirname(path))
+      body = File.read(path)
+
+      # Find INTERNAL /blog/X/ markdown links - i.e., `[text](/blog/X/)` form.
+      # External URLs like `[text](https://example.com/blog/X/)` start with `https`
+      # so won't match `\(/blog/`. This is the only form we should validate.
+      body.scan(%r{\]\(/blog/([^/"')\]\s]+)/\)}) do |match|
+        target_slug = match.first
+        target_slug = match.first
+        # If target is a course slug, it should now live under /course/<namespace>/
+        next if course_slugs.include?(target_slug)
+        target_path = "#{ALL_BLOG_DIR}/#{target_slug}"
+
+        unless Dir.exist?(target_path)
+          violations << "#{slug}: links to /blog/#{target_slug}/ but directory content/blog/#{target_slug}/ does not exist"
+        end
+      end
+
+      # Find INTERNAL /course/<namespace>/<slug>/ markdown links
+      body.scan(%r{\]\(/course/([^/"')\]\s]+)/([^/"')\]\s]+)/\)}) do |match|
+        namespace, target_slug = match
+        target_path = "#{COURSE_DIR}/#{namespace}/#{target_slug}"
+
+        unless Dir.exist?(target_path)
+          violations << "#{slug}: links to /course/#{namespace}/#{target_slug}/ but directory #{target_path}/ does not exist"
+        end
+      end
+    end
+
+    Result.new(name: "internal-link-existence", passed: violations.empty?, violations: violations)
+  end
+
+  # Helper: set of all course chapter slugs (so we can skip /blog/<course-slug>/
+  # links that are intentionally backed by Hugo aliases now)
+  def build_course_slug_set
+    @course_slug_set ||= begin
+      set = Set.new
+      course_chapters.each do |path|
+        set.add(File.basename(File.dirname(path)))
+      end
+      set
+    end
+  end
+
+  # ── Validator 4: Mobile-table width ──────────────────────────────────────
+  # Tables with >=5 columns in course_chapter: true posts fail the build.
+  # Detected by counting pipe-separated cells in the separator row (|---|).
+
+  def check_table_width
+    violations = []
+
+    course_chapters.each do |path|
+      slug = File.basename(File.dirname(path))
+      body = File.read(path)
+
+      # Find markdown tables by looking for separator rows
+      body.scan(/^\|[- :|]+\|$/) do |separator|
+        # Count columns by splitting on |
+        columns = separator.strip.split("|").reject(&:empty?)
+        col_count = columns.length
+
+        if col_count >= 5
+          # Find context: the previous line should be the header row
+          lines = body.lines
+          sep_index = lines.index { |l| l.strip == separator.strip }
+          context = if sep_index && sep_index > 0
+            lines[sep_index - 1].strip
+          else
+            "(unknown context)"
+          end
+
+          violations << "#{slug}: table with #{col_count} columns (>=5) found in context: \"#{context[0..60]}\""
+        end
+      end
+    end
+
+    Result.new(name: "table-width", passed: violations.empty?, violations: violations)
+  end
+
+  # ── Validator 5: Disclaimer consistency (all-or-none) ────────────────────
+  # A per-chapter boilerplate disclaimer must appear in EVERY course chapter or
+  # NONE. Present in only some = inconsistent artifact (the user flagged a
+  # disclaimer living in 2 of 18 chapters on 2026-05-22).
+
+  DISCLAIMER_MARKER = "anonymized names"
+
+  def check_disclaimer_consistency
+    chapters = course_chapters
+    with = chapters.select { |p| File.read(p).include?(DISCLAIMER_MARKER) }
+    violations = []
+    if with.any? && with.length < chapters.length
+      slugs = with.map { |p| File.basename(File.dirname(p)) }
+      violations << "disclaimer ('#{DISCLAIMER_MARKER}') present in #{with.length}/#{chapters.length} chapters (must be all or none): #{slugs.join(", ")}"
+    end
+    Result.new(name: "disclaimer-consistency", passed: violations.empty?, violations: violations)
+  end
+
+  # ── Validator 6: No em-dashes in content ─────────────────────────────────
+  # Project rule: use "-" not "—" in all content. Code fences excluded so
+  # legitimate code samples don't false-positive.
+
+  def check_em_dash_in_content
+    violations = []
+    course_chapters.each do |path|
+      slug = File.basename(File.dirname(path))
+      count = strip_code_fences(File.read(path)).count("—")
+      violations << "#{slug}: #{count} em-dash(es) (—) in content - use '-' instead" if count.positive?
+    end
+    Result.new(name: "no-em-dash", passed: violations.empty?, violations: violations)
+  end
+
+  # ── Validator 7: Year-stamp client-cohort fabrication ────────────────────
+  # Flags fabricated client-cohort timelines ("founders we joined in 2026",
+  # "A 2026 example"). Real dated references (a book's pub date, a CVE year)
+  # are NOT matched - only the "clients we X in YEAR" cohort shapes.
+
+  COHORT_YEAR_PATTERNS = [
+    /\b(?:founders?|clients?|teams?|rescues?)\s+we\s+(?:joined|ran|rescued|worked with)\s+(?:in\s+)?(?:early |mid |late |January |February |March |April |May |June |July |August |September |October |November |December )?20\d{2}/i,
+    /\bA\s+20\d{2}\s+example\b/i,
+    /\bwe\s+(?:joined|rescued|ran)\b[^.\n]*\bin\s+(?:early |mid |late |January |February |March |April |May |June |July |August |September |October |November |December )?20\d{2}/i
+  ].freeze
+
+  def check_year_stamp_fabrication
+    violations = []
+    course_chapters.each do |path|
+      slug = File.basename(File.dirname(path))
+      body = File.read(path)
+      COHORT_YEAR_PATTERNS.each do |re|
+        body.scan(re) { |_| violations << "#{slug}: fabricated client-cohort year-stamp (matched /#{re.source}/)" }
+      end
+    end
+    Result.new(name: "year-stamp-fabrication", passed: violations.empty?, violations: violations)
+  end
+
+  # ── Helpers ──────────────────────────────────────────────────────────────
+
+  def strip_code_fences(text)
+    text.gsub(/```.*?```/m, "")
+  end
+
+  def course_chapters
+    # Recursive glob to handle nested course namespaces
+    # (e.g., content/course/tech-for-non-technical-founders-2026/<chapter-slug>/index.md)
+    @course_chapters ||= Dir["#{COURSE_DIR}/**/index.md"].select do |f|
+      fm = parse_frontmatter(f)
+      fm["course_chapter"] == true
+    end.sort
+  end
+
+  def parse_frontmatter(path)
+    content = File.read(path)
+    if content =~ /\A---\s*\n(.*?)\n---\s*\n(.*)/m
+      YAML.safe_load($1, permitted_classes: [Date, Time]) || {}
+    else
+      {}
+    end
+  rescue Psych::SyntaxError => e
+    warn "Warning: YAML parse error in #{path}: #{e.message}"
+    {}
+  end
+
+  def sequence_data
+    @sequence_data ||= begin
+      data = YAML.load_file(YAML_PATH)
+      data["sequence"] || []
+    rescue Errno::ENOENT
+      warn "Warning: #{YAML_PATH} not found. Run from project root."
+      []
+    end
+  end
+
+  def build_valid_chapter_set
+    @valid_chapter_set ||= begin
+      set = Set.new
+      sequence_data.each do |entry|
+        match = entry["module"].match(/(\d+\.\d+)/)
+        set.add(match[1]) if match
+      end
+      set
+    end
+  end
+
+  def build_yaml_title_map
+    @yaml_title_map ||= begin
+      map = {}
+      sequence_data.each do |entry|
+        map[entry["slug"]] = entry
+      end
+      map
+    end
+  end
+end
diff --git a/linkedin-posts/icp-validation/backlog-vibe-coding-disposable.md b/linkedin-posts/icp-validation/backlog-vibe-coding-disposable.md
index 05229d0b6..d3eafe181 100644
--- a/linkedin-posts/icp-validation/backlog-vibe-coding-disposable.md
+++ b/linkedin-posts/icp-validation/backlog-vibe-coding-disposable.md
@@ -40,3 +40,5 @@ AI doesn't refactor when you ask for a fix. It generates fresh code. After a few
 I vibe-code on weekends too. Once the hypothesis lands, I throw the code out. Not because I'm pure about it. Because the alternative is paying for the same fix every couple of weeks for the rest of the product's life.
 
 If you've been through one of these rebuilds, what did you keep, what did you throw away?
+
+#ai #founders #vibecoding
diff --git a/linkedin-posts/icp-validation/week1-mon-jira-not-progress.md b/linkedin-posts/icp-validation/week1-mon-jira-not-progress.md
index 92594b04a..68ee485c4 100644
--- a/linkedin-posts/icp-validation/week1-mon-jira-not-progress.md
+++ b/linkedin-posts/icp-validation/week1-mon-jira-not-progress.md
@@ -6,26 +6,45 @@ voice: personal-first-person
 pillar: progress-visibility
 hypothesis: H1, H3
 icp_test: Do founders recognize this version of the problem and reply with their own?
-cta: Open question - "anyone else been here?"
+cta: Open question - "anyone else been in this version of it?"
 utm_campaign: icp_validation_progress_visibility
 utm_content: friday_demo_rule
 status: draft
 notes: |
-  Story-shaped, not advice-shaped. No tagline opener, no advice frame
-  ("What works is..."), no objection-handling bullet list, no
-  empowerment close. The tactical move is embedded inside the story
-  ("She's going to try something this Friday"), not lifted out as
-  prescribed advice.
+  Story-shaped, not advice-shaped. Tactical move embedded inside what
+  the founder is going to try Friday.
+  Five passes 2026-05-11. Pass 1-3: progressively removed AI tells,
+  grounded the opener, tightened length. Pass 4 added connectors at
+  the seams ("So I asked her", "We hopped on a screenshare", "Before
+  we hung up").
+  Pass 5 (per user feedback - "Long pause" and "five minutes in she
+  was navigating around features she didn't recognize" both read as
+  sales/marketing): removed cinematic beat-marking. "Long pause" was
+  a stage direction - replaced with "She had to think about it" which
+  describes the action instead of marking the beat. "Five minutes in
+  she was navigating around features she didn't recognize" had three
+  tells (omniscient time-stamp, passive narrator framing, stylized
+  reveal phrase) - replaced with "She didn't recognize half of what
+  she was clicking through" which is the same fact stated as a plain
+  observation. "She went quiet again" (literary callback) replaced
+  with "she couldn't point to any" (direct failure).
+  Skill search outcome: rejected kostja94/marketing-skills@linkedin
+  -posts (only generic LinkedIn-post skill with meaningful adoption,
+  992 installs) - its emphasis on engagement signals, character-count
+  thresholds, and SEO optimization conflicts directly with the
+  pipeline's voice rules. Pipeline §"Pre-writing reads" line 18:
+  "If this file conflicts with a generic writing, SEO, or humanizer
+  skill, this file wins for LinkedIn drafts."
 ---
 
-A founder pinged me last week. She couldn't say what was off. Just that something was.
+A founder pinged me last Tuesday wanting to know what her team had actually shipped that sprint. 14 tickets closed, standup that morning clean - and she still couldn't name one thing they'd built that she'd go and use.
 
-She walked me through her sprint board. Her dev shop had closed 14 tickets and she felt good about the pace.
+So I asked her when she'd last opened the product herself. She had to think about it, then said she couldn't remember - her dev shop had been on retainer since January and she hadn't clicked through anything they'd shipped.
 
-Asked her when she'd last actually used something the team shipped. She couldn't remember. And they'd been billing her for months.
+So she pulled it up while we were on the call. She didn't recognize half of what she was clicking through, and when I asked her to find one of those 14 closed tickets on screen, she couldn't point to any.
 
-The devs are closing tickets every week. The thing is, she can't open the product and show me what any of those tickets actually did. The board doesn't tell her if they built what she wanted, or just enough to close tickets.
+Before we hung up she said she'd try one thing this Friday. Instead of asking her dev shop how the sprint went, she'd ask for a URL where the week's work was actually visible, and use it herself for ten minutes.
 
-We talked about what she'd ask for this Friday. One URL on staging where anything had changed from the week before. Then she'd use it for a bit. Anything that didn't match what she asked for, she'd send back. The team only knew what she told them, and she hadn't been telling them much.
+Anyone else been in this version of it?
 
-Anyone else been here?
+#founders #startups #productmanagement
diff --git a/linkedin-posts/icp-validation/week1-tue-staging-question.md b/linkedin-posts/icp-validation/week1-tue-staging-question.md
index 8c71c663f..e8e6f7991 100644
--- a/linkedin-posts/icp-validation/week1-tue-staging-question.md
+++ b/linkedin-posts/icp-validation/week1-tue-staging-question.md
@@ -6,22 +6,49 @@ voice: personal-first-person
 pillar: progress-visibility
 hypothesis: H2, H3
 icp_test: Do founders share their own "question that saved a sprint" stories?
-cta: Open question - "anyone else stuck asking questions that don't pay back?"
+cta: Open question - "Has any standup question ever changed what you did the day after?"
 utm_campaign: icp_validation_progress_visibility
 utm_content: staging_question_script
-status: draft
+status: scheduled
+scheduled_for: 2026-05-12
 notes: |
-  Story-shape per docs/workflows/linkedin-post-pipeline.md. Hook archetype:
-  history-led ("Three sprints in a row...") to break dialogue-led overlap
-  with Monday post. Tactical content (staging question) embedded inside
-  what happened on one concrete founder call - not lifted out as advice.
-  No credential framing, no signposting, no three-line objection-handling
-  list. Quoted recurring exchange compressed into one sentence to avoid
-  parallel-sentence-stem flag.
+  Scheduled 2026-05-11 for posting 2026-05-12 (Tuesday). All
+  frontmatter-to-body consistency checks (pipeline §4) passed.
+  Story-shape per docs/workflows/linkedin-post-pipeline.md.
+  Revised 2026-05-11 (final pass) to de-duplicate against Monday's
+  Jira-not-progress post after user flagged the campaign as repetitive.
+  Four overlaps with Monday were removed:
+  1. OPENER ARCHETYPE: was dialogue-led "A founder I work with had
+     been asking..." (same shape as Monday's "A founder pinged me").
+     Now stat-led: "For the last dozen-ish standups I've sat in on..."
+     Paul as protagonist of an aggregated observation, not the founder
+     as protagonist of a specific call.
+  2. PROOF SIGNAL: was "smallest thing they could put in front of her
+     by Friday - even one screen with new data" - same deliverable-
+     visibility signal family as Monday's clickable URL. Now user-
+     impact verification ("name three real users on her support queue
+     who'd notice anything that shipped last sprint"), per the signal
+     portfolio in feedback_cross_post_signal_repetition.md.
+  3. SUBSTITUTION FRAMING: dropped "Instead of yes-or-no, she'd ask..."
+     since Monday uses the exact same "Instead of X, she'd ask for Y"
+     rhetorical move. Tuesday now uses "this week's standup gets a
+     different question" + the question itself.
+  4. CTA STEM: was "Anyone else stuck running..." (same "Anyone
+     else..." stem as Monday's "Anyone else been in this version of
+     it?"). Now post-specific: "Has any standup question ever changed
+     what you did the day after?"
+  Earlier 2026-05-11 revisions had already removed: performative
+  constructed-dialogue Q&A in the opener, "the cycle would start over"
+  slogany cyclical reveal, "Either she gets X, or she finds out Y"
+  binary-pivot construction, "Beats three more sprints of..." subject-
+  less slogany kicker, and the poetic "questions that don't pay back"
+  CTA metaphor.
 ---
 
-Three sprints in a row, same conversation: "is it on track?" yes, "when will it be ready?" next week. Next week would show up and the cycle would start over. The founder I was helping had run out of follow-ups, so we hopped on a quick call. When I asked her what either question had ever told her, she didn't have an answer.
+For the last dozen-ish standups I've sat in on with non-technical founders, the answer to "is it on track?" was yes almost every time, and almost none of those answers changed what got decided afterward. A founder I work with had been running that exact loop with her dev shop for three sprints before she pinged me. The thing I asked her: what would she have done differently if any of those three answers had come back "no"?
 
-So we agreed she'd try a different one this week. Instead of yes-or-no, she'd ask the team for the smallest thing they could actually put in front of her by Friday - even one screen with new data on it. Either she gets something to look at, or she finds out the team can't produce anything specific. Beats three more sprints of "is it on track?"
+So this week's standup gets a different question. She'll ask the team to name three real users on her support queue who'd notice anything that shipped last sprint - actual names, not personas or internal test accounts. If three names come back, the work has landed somewhere a customer can feel. If she gets vague personas, that's the answer two weeks before her old question would have produced it.
 
-Anyone else stuck asking questions that don't pay back?
+Has any standup question ever changed what you did the day after?
+
+#founders #startups #leadership
diff --git a/linkedin-posts/icp-validation/week1-wed-trust-signals-poll.md b/linkedin-posts/icp-validation/week1-wed-trust-signals-poll.md
index 54ccd104f..9b3119516 100644
--- a/linkedin-posts/icp-validation/week1-wed-trust-signals-poll.md
+++ b/linkedin-posts/icp-validation/week1-wed-trust-signals-poll.md
@@ -25,7 +25,7 @@ notes: |
 
 For founders working with an external dev team or agency: which signal do you actually rely on to know they're shipping?
 
-Vote below, and if you've got 30 seconds - tell me what yours sends and whether it's been useful.
+Vote below, and if you've got 30 seconds - tell me what your team currently sends and whether it actually helps.
 
 ## Poll question
 
@@ -41,3 +41,7 @@ What makes you trust your dev team is actually shipping?
 ## Poll duration
 
 1 week (closes Wednesday next week - results in hand before Friday review)
+
+## Hashtags (append to post body, after the peer-comment prompt)
+
+#founders #startups #buildinpublic
diff --git a/package-lock.json b/package-lock.json
new file mode 100644
index 000000000..25ade0422
--- /dev/null
+++ b/package-lock.json
@@ -0,0 +1,5687 @@
+{
+  "name": "jt_site",
+  "version": "1.0.0",
+  "lockfileVersion": 3,
+  "requires": true,
+  "packages": {
+    "": {
+      "name": "jt_site",
+      "version": "1.0.0",
+      "dependencies": {
+        "caniuse-lite": "^1.0.30001793"
+      },
+      "devDependencies": {
+        "@fullhuman/postcss-purgecss": "^8.0.0",
+        "autoprefixer": "^10.5.0",
+        "cssnano": "^8.0.1",
+        "lighthouse": "^13.3.0",
+        "markdownlint-cli": "^0.48.0",
+        "postcss": "^8.5.15",
+        "postcss-cli": "^11.0.1",
+        "postcss-delete-duplicate-css": "^1.0.0",
+        "postcss-extend-rule": "^4.0.0",
+        "postcss-import": "^16.1.1",
+        "postcss-mixins": "^12.1.2",
+        "postcss-nested": "^7.0.2",
+        "surge": "^0.27.4"
+      },
+      "engines": {
+        "bun": ">=1.3"
+      }
+    },
+    "node_modules/@colordx/core": {
+      "version": "5.4.3",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/@colors/colors": {
+      "version": "1.5.0",
+      "resolved": "https://registry.npmjs.org/@colors/colors/-/colors-1.5.0.tgz",
+      "integrity": "sha512-ooWCrlZP11i8GImSjTHYHLkvFDP48nS4+204nGb1RiX/WXYHmJA2III9/e2DWVabCESdW7hBAEzHRqUn9OUVvQ==",
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "engines": {
+        "node": ">=0.1.90"
+      }
+    },
+    "node_modules/@csstools/selector-specificity": {
+      "version": "2.2.0",
+      "dev": true,
+      "license": "CC0-1.0",
+      "engines": {
+        "node": "^14 || ^16 || >=18"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/csstools"
+      },
+      "peerDependencies": {
+        "postcss-selector-parser": "^6.0.10"
+      }
+    },
+    "node_modules/@formatjs/ecma402-abstract": {
+      "version": "2.3.6",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@formatjs/fast-memoize": "2.2.7",
+        "@formatjs/intl-localematcher": "0.6.2",
+        "decimal.js": "^10.4.3",
+        "tslib": "^2.8.0"
+      }
+    },
+    "node_modules/@formatjs/fast-memoize": {
+      "version": "2.2.7",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "tslib": "^2.8.0"
+      }
+    },
+    "node_modules/@formatjs/icu-messageformat-parser": {
+      "version": "2.11.4",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@formatjs/ecma402-abstract": "2.3.6",
+        "@formatjs/icu-skeleton-parser": "1.8.16",
+        "tslib": "^2.8.0"
+      }
+    },
+    "node_modules/@formatjs/icu-skeleton-parser": {
+      "version": "1.8.16",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@formatjs/ecma402-abstract": "2.3.6",
+        "tslib": "^2.8.0"
+      }
+    },
+    "node_modules/@formatjs/intl-localematcher": {
+      "version": "0.6.2",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "tslib": "^2.8.0"
+      }
+    },
+    "node_modules/@fullhuman/postcss-purgecss": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "purgecss": "^8.0.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.0.0"
+      }
+    },
+    "node_modules/@isaacs/fs-minipass": {
+      "version": "4.0.1",
+      "dev": true,
+      "license": "ISC",
+      "dependencies": {
+        "minipass": "^7.0.4"
+      },
+      "engines": {
+        "node": ">=18.0.0"
+      }
+    },
+    "node_modules/@nodelib/fs.scandir": {
+      "version": "2.1.5",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@nodelib/fs.stat": "2.0.5",
+        "run-parallel": "^1.1.9"
+      },
+      "engines": {
+        "node": ">= 8"
+      }
+    },
+    "node_modules/@nodelib/fs.stat": {
+      "version": "2.0.5",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 8"
+      }
+    },
+    "node_modules/@nodelib/fs.walk": {
+      "version": "1.2.8",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@nodelib/fs.scandir": "2.1.5",
+        "fastq": "^1.6.0"
+      },
+      "engines": {
+        "node": ">= 8"
+      }
+    },
+    "node_modules/@opentelemetry/api": {
+      "version": "1.9.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "engines": {
+        "node": ">=8.0.0"
+      }
+    },
+    "node_modules/@opentelemetry/api-logs": {
+      "version": "0.57.2",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      },
+      "engines": {
+        "node": ">=14"
+      }
+    },
+    "node_modules/@opentelemetry/context-async-hooks": {
+      "version": "1.30.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": ">=1.0.0 <1.10.0"
+      }
+    },
+    "node_modules/@opentelemetry/core": {
+      "version": "1.30.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/semantic-conventions": "1.28.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": ">=1.0.0 <1.10.0"
+      }
+    },
+    "node_modules/@opentelemetry/core/node_modules/@opentelemetry/semantic-conventions": {
+      "version": "1.28.0",
+      "dev": true,
+      "license": "Apache-2.0",
+      "engines": {
+        "node": ">=14"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation": {
+      "version": "0.57.2",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/api-logs": "0.57.2",
+        "@types/shimmer": "^1.2.0",
+        "import-in-the-middle": "^1.8.1",
+        "require-in-the-middle": "^7.1.1",
+        "semver": "^7.5.2",
+        "shimmer": "^1.2.1"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-amqplib": {
+      "version": "0.46.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/core": "^1.8.0",
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/semantic-conventions": "^1.27.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-connect": {
+      "version": "0.43.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/core": "^1.8.0",
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/semantic-conventions": "^1.27.0",
+        "@types/connect": "3.4.38"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-dataloader": {
+      "version": "0.16.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/instrumentation": "^0.57.1"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-express": {
+      "version": "0.47.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/core": "^1.8.0",
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/semantic-conventions": "^1.27.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-fs": {
+      "version": "0.19.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/core": "^1.8.0",
+        "@opentelemetry/instrumentation": "^0.57.1"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-generic-pool": {
+      "version": "0.43.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/instrumentation": "^0.57.1"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-graphql": {
+      "version": "0.47.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/instrumentation": "^0.57.1"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-hapi": {
+      "version": "0.45.2",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/core": "^1.8.0",
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/semantic-conventions": "^1.27.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-http": {
+      "version": "0.57.2",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/core": "1.30.1",
+        "@opentelemetry/instrumentation": "0.57.2",
+        "@opentelemetry/semantic-conventions": "1.28.0",
+        "forwarded-parse": "2.1.2",
+        "semver": "^7.5.2"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-http/node_modules/@opentelemetry/semantic-conventions": {
+      "version": "1.28.0",
+      "dev": true,
+      "license": "Apache-2.0",
+      "engines": {
+        "node": ">=14"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-ioredis": {
+      "version": "0.47.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/redis-common": "^0.36.2",
+        "@opentelemetry/semantic-conventions": "^1.27.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-kafkajs": {
+      "version": "0.7.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/semantic-conventions": "^1.27.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-knex": {
+      "version": "0.44.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/semantic-conventions": "^1.27.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-koa": {
+      "version": "0.47.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/core": "^1.8.0",
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/semantic-conventions": "^1.27.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-lru-memoizer": {
+      "version": "0.44.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/instrumentation": "^0.57.1"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-mongodb": {
+      "version": "0.52.0",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/semantic-conventions": "^1.27.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-mongoose": {
+      "version": "0.46.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/core": "^1.8.0",
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/semantic-conventions": "^1.27.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-mysql": {
+      "version": "0.45.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/semantic-conventions": "^1.27.0",
+        "@types/mysql": "2.15.26"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-mysql2": {
+      "version": "0.45.2",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/semantic-conventions": "^1.27.0",
+        "@opentelemetry/sql-common": "^0.40.1"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-pg": {
+      "version": "0.51.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/core": "^1.26.0",
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/semantic-conventions": "^1.27.0",
+        "@opentelemetry/sql-common": "^0.40.1",
+        "@types/pg": "8.6.1",
+        "@types/pg-pool": "2.0.6"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-redis-4": {
+      "version": "0.46.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/redis-common": "^0.36.2",
+        "@opentelemetry/semantic-conventions": "^1.27.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-tedious": {
+      "version": "0.18.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/instrumentation": "^0.57.1",
+        "@opentelemetry/semantic-conventions": "^1.27.0",
+        "@types/tedious": "^4.0.14"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.3.0"
+      }
+    },
+    "node_modules/@opentelemetry/instrumentation-undici": {
+      "version": "0.10.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/core": "^1.8.0",
+        "@opentelemetry/instrumentation": "^0.57.1"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.7.0"
+      }
+    },
+    "node_modules/@opentelemetry/redis-common": {
+      "version": "0.36.2",
+      "dev": true,
+      "license": "Apache-2.0",
+      "engines": {
+        "node": ">=14"
+      }
+    },
+    "node_modules/@opentelemetry/resources": {
+      "version": "1.30.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/core": "1.30.1",
+        "@opentelemetry/semantic-conventions": "1.28.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": ">=1.0.0 <1.10.0"
+      }
+    },
+    "node_modules/@opentelemetry/resources/node_modules/@opentelemetry/semantic-conventions": {
+      "version": "1.28.0",
+      "dev": true,
+      "license": "Apache-2.0",
+      "engines": {
+        "node": ">=14"
+      }
+    },
+    "node_modules/@opentelemetry/sdk-trace-base": {
+      "version": "1.30.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/core": "1.30.1",
+        "@opentelemetry/resources": "1.30.1",
+        "@opentelemetry/semantic-conventions": "1.28.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": ">=1.0.0 <1.10.0"
+      }
+    },
+    "node_modules/@opentelemetry/sdk-trace-base/node_modules/@opentelemetry/semantic-conventions": {
+      "version": "1.28.0",
+      "dev": true,
+      "license": "Apache-2.0",
+      "engines": {
+        "node": ">=14"
+      }
+    },
+    "node_modules/@opentelemetry/semantic-conventions": {
+      "version": "1.40.0",
+      "dev": true,
+      "license": "Apache-2.0",
+      "engines": {
+        "node": ">=14"
+      }
+    },
+    "node_modules/@opentelemetry/sql-common": {
+      "version": "0.40.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/core": "^1.1.0"
+      },
+      "engines": {
+        "node": ">=14"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.1.0"
+      }
+    },
+    "node_modules/@paulirish/trace_engine": {
+      "version": "0.0.64",
+      "dev": true,
+      "license": "BSD-3-Clause",
+      "dependencies": {
+        "legacy-javascript": "latest",
+        "third-party-web": "latest"
+      }
+    },
+    "node_modules/@prisma/instrumentation": {
+      "version": "6.11.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@opentelemetry/instrumentation": "^0.52.0 || ^0.53.0 || ^0.54.0 || ^0.55.0 || ^0.56.0 || ^0.57.0"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.8"
+      }
+    },
+    "node_modules/@puppeteer/browsers": {
+      "version": "2.13.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "debug": "^4.4.3",
+        "extract-zip": "^2.0.1",
+        "progress": "^2.0.3",
+        "proxy-agent": "^6.5.0",
+        "semver": "^7.7.4",
+        "tar-fs": "^3.1.1",
+        "yargs": "^17.7.2"
+      },
+      "bin": {
+        "browsers": "lib/cjs/main-cli.js"
+      },
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@puppeteer/browsers/node_modules/debug": {
+      "version": "4.4.3",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "ms": "^2.1.3"
+      },
+      "engines": {
+        "node": ">=6.0"
+      },
+      "peerDependenciesMeta": {
+        "supports-color": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/@puppeteer/browsers/node_modules/semver": {
+      "version": "7.7.4",
+      "dev": true,
+      "license": "ISC",
+      "bin": {
+        "semver": "bin/semver.js"
+      },
+      "engines": {
+        "node": ">=10"
+      }
+    },
+    "node_modules/@sentry/core": {
+      "version": "9.47.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@sentry/node": {
+      "version": "9.47.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@opentelemetry/api": "^1.9.0",
+        "@opentelemetry/context-async-hooks": "^1.30.1",
+        "@opentelemetry/core": "^1.30.1",
+        "@opentelemetry/instrumentation": "^0.57.2",
+        "@opentelemetry/instrumentation-amqplib": "^0.46.1",
+        "@opentelemetry/instrumentation-connect": "0.43.1",
+        "@opentelemetry/instrumentation-dataloader": "0.16.1",
+        "@opentelemetry/instrumentation-express": "0.47.1",
+        "@opentelemetry/instrumentation-fs": "0.19.1",
+        "@opentelemetry/instrumentation-generic-pool": "0.43.1",
+        "@opentelemetry/instrumentation-graphql": "0.47.1",
+        "@opentelemetry/instrumentation-hapi": "0.45.2",
+        "@opentelemetry/instrumentation-http": "0.57.2",
+        "@opentelemetry/instrumentation-ioredis": "0.47.1",
+        "@opentelemetry/instrumentation-kafkajs": "0.7.1",
+        "@opentelemetry/instrumentation-knex": "0.44.1",
+        "@opentelemetry/instrumentation-koa": "0.47.1",
+        "@opentelemetry/instrumentation-lru-memoizer": "0.44.1",
+        "@opentelemetry/instrumentation-mongodb": "0.52.0",
+        "@opentelemetry/instrumentation-mongoose": "0.46.1",
+        "@opentelemetry/instrumentation-mysql": "0.45.1",
+        "@opentelemetry/instrumentation-mysql2": "0.45.2",
+        "@opentelemetry/instrumentation-pg": "0.51.1",
+        "@opentelemetry/instrumentation-redis-4": "0.46.1",
+        "@opentelemetry/instrumentation-tedious": "0.18.1",
+        "@opentelemetry/instrumentation-undici": "0.10.1",
+        "@opentelemetry/resources": "^1.30.1",
+        "@opentelemetry/sdk-trace-base": "^1.30.1",
+        "@opentelemetry/semantic-conventions": "^1.34.0",
+        "@prisma/instrumentation": "6.11.1",
+        "@sentry/core": "9.47.1",
+        "@sentry/node-core": "9.47.1",
+        "@sentry/opentelemetry": "9.47.1",
+        "import-in-the-middle": "^1.14.2",
+        "minimatch": "^9.0.0"
+      },
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@sentry/node-core": {
+      "version": "9.47.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@sentry/core": "9.47.1",
+        "@sentry/opentelemetry": "9.47.1",
+        "import-in-the-middle": "^1.14.2"
+      },
+      "engines": {
+        "node": ">=18"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.9.0",
+        "@opentelemetry/context-async-hooks": "^1.30.1 || ^2.0.0",
+        "@opentelemetry/core": "^1.30.1 || ^2.0.0",
+        "@opentelemetry/instrumentation": ">=0.57.1 <1",
+        "@opentelemetry/resources": "^1.30.1 || ^2.0.0",
+        "@opentelemetry/sdk-trace-base": "^1.30.1 || ^2.0.0",
+        "@opentelemetry/semantic-conventions": "^1.34.0"
+      }
+    },
+    "node_modules/@sentry/node/node_modules/minimatch": {
+      "version": "9.0.9",
+      "dev": true,
+      "license": "ISC",
+      "dependencies": {
+        "brace-expansion": "^2.0.2"
+      },
+      "engines": {
+        "node": ">=16 || 14 >=14.17"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/isaacs"
+      }
+    },
+    "node_modules/@sentry/node/node_modules/minimatch/node_modules/brace-expansion": {
+      "version": "2.1.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "balanced-match": "^1.0.0"
+      }
+    },
+    "node_modules/@sentry/node/node_modules/minimatch/node_modules/brace-expansion/node_modules/balanced-match": {
+      "version": "1.0.2",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/@sentry/opentelemetry": {
+      "version": "9.47.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@sentry/core": "9.47.1"
+      },
+      "engines": {
+        "node": ">=18"
+      },
+      "peerDependencies": {
+        "@opentelemetry/api": "^1.9.0",
+        "@opentelemetry/context-async-hooks": "^1.30.1 || ^2.0.0",
+        "@opentelemetry/core": "^1.30.1 || ^2.0.0",
+        "@opentelemetry/sdk-trace-base": "^1.30.1 || ^2.0.0",
+        "@opentelemetry/semantic-conventions": "^1.34.0"
+      }
+    },
+    "node_modules/@tootallnate/quickjs-emscripten": {
+      "version": "0.23.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/@types/connect": {
+      "version": "3.4.38",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/node": "*"
+      }
+    },
+    "node_modules/@types/debug": {
+      "version": "4.1.13",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/ms": "*"
+      }
+    },
+    "node_modules/@types/katex": {
+      "version": "0.16.8",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/@types/ms": {
+      "version": "2.1.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/@types/mysql": {
+      "version": "2.15.26",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/node": "*"
+      }
+    },
+    "node_modules/@types/node": {
+      "version": "25.6.2",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "undici-types": "~7.19.0"
+      }
+    },
+    "node_modules/@types/pg": {
+      "version": "8.6.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/node": "*",
+        "pg-protocol": "*",
+        "pg-types": "^2.2.0"
+      }
+    },
+    "node_modules/@types/pg-pool": {
+      "version": "2.0.6",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/pg": "*"
+      }
+    },
+    "node_modules/@types/shimmer": {
+      "version": "1.2.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/@types/tedious": {
+      "version": "4.0.14",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/node": "*"
+      }
+    },
+    "node_modules/@types/unist": {
+      "version": "2.0.11",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/@types/yauzl": {
+      "version": "2.10.3",
+      "resolved": "https://registry.npmjs.org/@types/yauzl/-/yauzl-2.10.3.tgz",
+      "integrity": "sha512-oJoftv0LSuaDZE3Le4DbKX+KS9G36NzOeSap90UIK0yMA/NhKJhqlSGtNDORNRaIbQfzjXDrQa0ytJ6mNRGz/Q==",
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "dependencies": {
+        "@types/node": "*"
+      }
+    },
+    "node_modules/acorn": {
+      "version": "8.16.0",
+      "dev": true,
+      "license": "MIT",
+      "bin": {
+        "acorn": "bin/acorn"
+      },
+      "engines": {
+        "node": ">=0.4.0"
+      }
+    },
+    "node_modules/acorn-import-attributes": {
+      "version": "1.9.5",
+      "dev": true,
+      "license": "MIT",
+      "peerDependencies": {
+        "acorn": "^8"
+      }
+    },
+    "node_modules/agent-base": {
+      "version": "7.1.4",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 14"
+      }
+    },
+    "node_modules/ansi-colors": {
+      "version": "4.1.3",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=6"
+      }
+    },
+    "node_modules/ansi-regex": {
+      "version": "5.0.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/ansi-styles": {
+      "version": "4.3.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "color-convert": "^2.0.1"
+      },
+      "engines": {
+        "node": ">=8"
+      },
+      "funding": {
+        "url": "https://github.com/chalk/ansi-styles?sponsor=1"
+      }
+    },
+    "node_modules/anymatch": {
+      "version": "3.1.3",
+      "dev": true,
+      "license": "ISC",
+      "dependencies": {
+        "normalize-path": "^3.0.0",
+        "picomatch": "^2.0.4"
+      },
+      "engines": {
+        "node": ">= 8"
+      }
+    },
+    "node_modules/anymatch/node_modules/picomatch": {
+      "version": "2.3.2",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=8.6"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/jonschlinkert"
+      }
+    },
+    "node_modules/argparse": {
+      "version": "2.0.1",
+      "dev": true,
+      "license": "Python-2.0"
+    },
+    "node_modules/ast-types": {
+      "version": "0.13.4",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "tslib": "^2.0.1"
+      },
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/asynckit": {
+      "version": "0.4.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/atomically": {
+      "version": "2.1.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "stubborn-fs": "^2.0.0",
+        "when-exit": "^2.1.4"
+      }
+    },
+    "node_modules/autoprefixer": {
+      "version": "10.5.0",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/postcss/"
+        },
+        {
+          "type": "tidelift",
+          "url": "https://tidelift.com/funding/github/npm/autoprefixer"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "browserslist": "^4.28.2",
+        "caniuse-lite": "^1.0.30001787",
+        "fraction.js": "^5.3.4",
+        "picocolors": "^1.1.1",
+        "postcss-value-parser": "^4.2.0"
+      },
+      "bin": {
+        "autoprefixer": "bin/autoprefixer"
+      },
+      "engines": {
+        "node": "^10 || ^12 || >=14"
+      },
+      "peerDependencies": {
+        "postcss": "^8.1.0"
+      }
+    },
+    "node_modules/autoprefixer/node_modules/caniuse-lite": {
+      "version": "1.0.30001792",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/browserslist"
+        },
+        {
+          "type": "tidelift",
+          "url": "https://tidelift.com/funding/github/npm/caniuse-lite"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "CC-BY-4.0"
+    },
+    "node_modules/axe-core": {
+      "version": "4.11.4",
+      "dev": true,
+      "license": "MPL-2.0",
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/axios": {
+      "version": "1.13.5",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "follow-redirects": "^1.15.11",
+        "form-data": "^4.0.5",
+        "proxy-from-env": "^1.1.0"
+      }
+    },
+    "node_modules/b4a": {
+      "version": "1.8.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "peerDependencies": {
+        "react-native-b4a": "*"
+      },
+      "peerDependenciesMeta": {
+        "react-native-b4a": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/babar": {
+      "version": "0.2.3",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "colors": "~1.4.0"
+      }
+    },
+    "node_modules/balanced-match": {
+      "version": "4.0.4",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": "18 || 20 || >=22"
+      }
+    },
+    "node_modules/bare-events": {
+      "version": "2.8.2",
+      "dev": true,
+      "license": "Apache-2.0",
+      "peerDependencies": {
+        "bare-abort-controller": "*"
+      },
+      "peerDependenciesMeta": {
+        "bare-abort-controller": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/bare-fs": {
+      "version": "4.7.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "bare-events": "^2.5.4",
+        "bare-path": "^3.0.0",
+        "bare-stream": "^2.6.4",
+        "bare-url": "^2.2.2",
+        "fast-fifo": "^1.3.2"
+      },
+      "engines": {
+        "bare": ">=1.16.0"
+      },
+      "peerDependencies": {
+        "bare-buffer": "*"
+      },
+      "peerDependenciesMeta": {
+        "bare-buffer": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/bare-os": {
+      "version": "3.9.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "engines": {
+        "bare": ">=1.14.0"
+      }
+    },
+    "node_modules/bare-path": {
+      "version": "3.0.0",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "bare-os": "^3.0.1"
+      }
+    },
+    "node_modules/bare-stream": {
+      "version": "2.13.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "streamx": "^2.25.0",
+        "teex": "^1.0.1"
+      },
+      "peerDependencies": {
+        "bare-abort-controller": "*",
+        "bare-buffer": "*",
+        "bare-events": "*"
+      },
+      "peerDependenciesMeta": {
+        "bare-abort-controller": {
+          "optional": true
+        },
+        "bare-buffer": {
+          "optional": true
+        },
+        "bare-events": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/bare-url": {
+      "version": "2.4.3",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "bare-path": "^3.0.0"
+      }
+    },
+    "node_modules/baseline-browser-mapping": {
+      "version": "2.10.29",
+      "dev": true,
+      "license": "Apache-2.0",
+      "bin": {
+        "baseline-browser-mapping": "dist/cli.cjs"
+      },
+      "engines": {
+        "node": ">=6.0.0"
+      }
+    },
+    "node_modules/basic-ftp": {
+      "version": "5.3.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=10.0.0"
+      }
+    },
+    "node_modules/binary-extensions": {
+      "version": "2.3.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=8"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/boolbase": {
+      "version": "1.0.0",
+      "dev": true,
+      "license": "ISC"
+    },
+    "node_modules/brace-expansion": {
+      "version": "5.0.6",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "balanced-match": "^4.0.2"
+      },
+      "engines": {
+        "node": "18 || 20 || >=22"
+      }
+    },
+    "node_modules/braces": {
+      "version": "3.0.3",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "fill-range": "^7.1.1"
+      },
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/browserslist": {
+      "version": "4.28.2",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/browserslist"
+        },
+        {
+          "type": "tidelift",
+          "url": "https://tidelift.com/funding/github/npm/browserslist"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "baseline-browser-mapping": "^2.10.12",
+        "caniuse-lite": "^1.0.30001782",
+        "electron-to-chromium": "^1.5.328",
+        "node-releases": "^2.0.36",
+        "update-browserslist-db": "^1.2.3"
+      },
+      "bin": {
+        "browserslist": "cli.js"
+      },
+      "engines": {
+        "node": "^6 || ^7 || ^8 || ^9 || ^10 || ^11 || ^12 || >=13.7"
+      }
+    },
+    "node_modules/browserslist/node_modules/caniuse-lite": {
+      "version": "1.0.30001792",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/browserslist"
+        },
+        {
+          "type": "tidelift",
+          "url": "https://tidelift.com/funding/github/npm/caniuse-lite"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "CC-BY-4.0"
+    },
+    "node_modules/buffer-crc32": {
+      "version": "0.2.13",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": "*"
+      }
+    },
+    "node_modules/call-bind-apply-helpers": {
+      "version": "1.0.2",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "es-errors": "^1.3.0",
+        "function-bind": "^1.1.2"
+      },
+      "engines": {
+        "node": ">= 0.4"
+      }
+    },
+    "node_modules/camelcase-css": {
+      "version": "2.0.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 6"
+      }
+    },
+    "node_modules/caniuse-api": {
+      "version": "3.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "browserslist": "^4.0.0",
+        "caniuse-lite": "^1.0.0",
+        "lodash.memoize": "^4.1.2",
+        "lodash.uniq": "^4.5.0"
+      }
+    },
+    "node_modules/caniuse-api/node_modules/caniuse-lite": {
+      "version": "1.0.30001792",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/browserslist"
+        },
+        {
+          "type": "tidelift",
+          "url": "https://tidelift.com/funding/github/npm/caniuse-lite"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "CC-BY-4.0"
+    },
+    "node_modules/caniuse-lite": {
+      "version": "1.0.30001793",
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/browserslist"
+        },
+        {
+          "type": "tidelift",
+          "url": "https://tidelift.com/funding/github/npm/caniuse-lite"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "CC-BY-4.0"
+    },
+    "node_modules/character-entities": {
+      "version": "2.0.2",
+      "dev": true,
+      "license": "MIT",
+      "funding": {
+        "type": "github",
+        "url": "https://github.com/sponsors/wooorm"
+      }
+    },
+    "node_modules/character-entities-legacy": {
+      "version": "3.0.0",
+      "dev": true,
+      "license": "MIT",
+      "funding": {
+        "type": "github",
+        "url": "https://github.com/sponsors/wooorm"
+      }
+    },
+    "node_modules/character-reference-invalid": {
+      "version": "2.0.1",
+      "dev": true,
+      "license": "MIT",
+      "funding": {
+        "type": "github",
+        "url": "https://github.com/sponsors/wooorm"
+      }
+    },
+    "node_modules/chokidar": {
+      "version": "3.6.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "anymatch": "~3.1.2",
+        "braces": "~3.0.2",
+        "glob-parent": "~5.1.2",
+        "is-binary-path": "~2.1.0",
+        "is-glob": "~4.0.1",
+        "normalize-path": "~3.0.0",
+        "readdirp": "~3.6.0"
+      },
+      "engines": {
+        "node": ">= 8.10.0"
+      },
+      "funding": {
+        "url": "https://paulmillr.com/funding/"
+      },
+      "optionalDependencies": {
+        "fsevents": "~2.3.2"
+      }
+    },
+    "node_modules/chownr": {
+      "version": "3.0.0",
+      "dev": true,
+      "license": "BlueOak-1.0.0",
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/chrome-launcher": {
+      "version": "1.2.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@types/node": "*",
+        "escape-string-regexp": "^4.0.0",
+        "is-wsl": "^2.2.0",
+        "lighthouse-logger": "^2.0.1"
+      },
+      "bin": {
+        "print-chrome-path": "bin/print-chrome-path.cjs"
+      },
+      "engines": {
+        "node": ">=12.13.0"
+      }
+    },
+    "node_modules/chromium-bidi": {
+      "version": "14.0.0",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "mitt": "^3.0.1",
+        "zod": "^3.24.1"
+      },
+      "peerDependencies": {
+        "devtools-protocol": "*"
+      }
+    },
+    "node_modules/cjs-module-lexer": {
+      "version": "1.4.3",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/cli-table3": {
+      "version": "0.6.5",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "string-width": "^4.2.0"
+      },
+      "engines": {
+        "node": "10.* || >= 12.*"
+      },
+      "optionalDependencies": {
+        "@colors/colors": "1.5.0"
+      }
+    },
+    "node_modules/cliui": {
+      "version": "8.0.1",
+      "dev": true,
+      "license": "ISC",
+      "dependencies": {
+        "string-width": "^4.2.0",
+        "strip-ansi": "^6.0.1",
+        "wrap-ansi": "^7.0.0"
+      },
+      "engines": {
+        "node": ">=12"
+      }
+    },
+    "node_modules/cliui/node_modules/string-width": {
+      "version": "4.2.3",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "emoji-regex": "^8.0.0",
+        "is-fullwidth-code-point": "^3.0.0",
+        "strip-ansi": "^6.0.1"
+      },
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/cliui/node_modules/string-width/node_modules/emoji-regex": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/cliui/node_modules/strip-ansi": {
+      "version": "6.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "ansi-regex": "^5.0.1"
+      },
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/cliui/node_modules/strip-ansi/node_modules/ansi-regex": {
+      "version": "5.0.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/color-convert": {
+      "version": "2.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "color-name": "~1.1.4"
+      },
+      "engines": {
+        "node": ">=7.0.0"
+      }
+    },
+    "node_modules/color-name": {
+      "version": "1.1.4",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/colors": {
+      "version": "1.4.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=0.1.90"
+      }
+    },
+    "node_modules/combined-stream": {
+      "version": "1.0.8",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "delayed-stream": "~1.0.0"
+      },
+      "engines": {
+        "node": ">= 0.8"
+      }
+    },
+    "node_modules/commander": {
+      "version": "14.0.3",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=20"
+      }
+    },
+    "node_modules/configstore": {
+      "version": "7.1.0",
+      "dev": true,
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "atomically": "^2.0.3",
+        "dot-prop": "^9.0.0",
+        "graceful-fs": "^4.2.11",
+        "xdg-basedir": "^5.1.0"
+      },
+      "engines": {
+        "node": ">=18"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/csp_evaluator": {
+      "version": "1.1.5",
+      "dev": true,
+      "license": "Apache-2.0"
+    },
+    "node_modules/cssesc": {
+      "version": "3.0.0",
+      "dev": true,
+      "license": "MIT",
+      "bin": {
+        "cssesc": "bin/cssesc"
+      },
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/cssnano": {
+      "version": "8.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "cssnano-preset-default": "^8.0.1",
+        "lilconfig": "^3.1.3"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/cssnano"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/cssnano-preset-default": {
+      "version": "8.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "browserslist": "^4.28.2",
+        "cssnano-utils": "^6.0.0",
+        "postcss-calc": "^10.1.1",
+        "postcss-colormin": "^8.0.0",
+        "postcss-convert-values": "^8.0.0",
+        "postcss-discard-comments": "^8.0.0",
+        "postcss-discard-duplicates": "^8.0.0",
+        "postcss-discard-empty": "^8.0.0",
+        "postcss-discard-overridden": "^8.0.0",
+        "postcss-merge-longhand": "^8.0.0",
+        "postcss-merge-rules": "^8.0.0",
+        "postcss-minify-font-values": "^8.0.0",
+        "postcss-minify-gradients": "^8.0.0",
+        "postcss-minify-params": "^8.0.0",
+        "postcss-minify-selectors": "^8.0.1",
+        "postcss-normalize-charset": "^8.0.0",
+        "postcss-normalize-display-values": "^8.0.0",
+        "postcss-normalize-positions": "^8.0.0",
+        "postcss-normalize-repeat-style": "^8.0.0",
+        "postcss-normalize-string": "^8.0.0",
+        "postcss-normalize-timing-functions": "^8.0.0",
+        "postcss-normalize-unicode": "^8.0.0",
+        "postcss-normalize-url": "^8.0.0",
+        "postcss-normalize-whitespace": "^8.0.0",
+        "postcss-ordered-values": "^8.0.0",
+        "postcss-reduce-initial": "^8.0.0",
+        "postcss-reduce-transforms": "^8.0.0",
+        "postcss-svgo": "^8.0.0",
+        "postcss-unique-selectors": "^8.0.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/cssnano-utils": {
+      "version": "6.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/csso": {
+      "version": "5.0.5",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "css-tree": "~2.2.0"
+      },
+      "engines": {
+        "node": "^10 || ^12.20.0 || ^14.13.0 || >=15.0.0",
+        "npm": ">=7.0.0"
+      }
+    },
+    "node_modules/csso/node_modules/css-tree": {
+      "version": "2.2.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "mdn-data": "2.0.28",
+        "source-map-js": "^1.0.1"
+      },
+      "engines": {
+        "node": "^10 || ^12.20.0 || ^14.13.0 || >=15.0.0",
+        "npm": ">=7.0.0"
+      }
+    },
+    "node_modules/csso/node_modules/css-tree/node_modules/mdn-data": {
+      "version": "2.0.28",
+      "dev": true,
+      "license": "CC0-1.0"
+    },
+    "node_modules/csso/node_modules/css-tree/node_modules/source-map-js": {
+      "version": "1.2.0",
+      "dev": true,
+      "license": "BSD-3-Clause",
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/data-uri-to-buffer": {
+      "version": "6.0.2",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 14"
+      }
+    },
+    "node_modules/debug": {
+      "version": "4.4.3",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "ms": "^2.1.3"
+      },
+      "engines": {
+        "node": ">=6.0"
+      },
+      "peerDependenciesMeta": {
+        "supports-color": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/decimal.js": {
+      "version": "10.6.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/decode-named-character-reference": {
+      "version": "1.3.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "character-entities": "^2.0.0"
+      },
+      "funding": {
+        "type": "github",
+        "url": "https://github.com/sponsors/wooorm"
+      }
+    },
+    "node_modules/deep-extend": {
+      "version": "0.6.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=4.0.0"
+      }
+    },
+    "node_modules/define-lazy-prop": {
+      "version": "2.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/degenerator": {
+      "version": "5.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "ast-types": "^0.13.4",
+        "escodegen": "^2.1.0",
+        "esprima": "^4.0.1"
+      },
+      "engines": {
+        "node": ">= 14"
+      }
+    },
+    "node_modules/delayed-stream": {
+      "version": "1.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=0.4.0"
+      }
+    },
+    "node_modules/dependency-graph": {
+      "version": "1.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/dequal": {
+      "version": "2.0.3",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=6"
+      }
+    },
+    "node_modules/devlop": {
+      "version": "1.1.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "dequal": "^2.0.0"
+      },
+      "funding": {
+        "type": "github",
+        "url": "https://github.com/sponsors/wooorm"
+      }
+    },
+    "node_modules/devtools-protocol": {
+      "version": "0.0.1625959",
+      "dev": true,
+      "license": "BSD-3-Clause"
+    },
+    "node_modules/dom-serializer": {
+      "version": "2.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "domelementtype": "^2.3.0",
+        "domhandler": "^5.0.2",
+        "entities": "^4.2.0"
+      },
+      "funding": {
+        "url": "https://github.com/cheeriojs/dom-serializer?sponsor=1"
+      }
+    },
+    "node_modules/domelementtype": {
+      "version": "2.3.0",
+      "dev": true,
+      "funding": [
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/fb55"
+        }
+      ],
+      "license": "BSD-2-Clause"
+    },
+    "node_modules/domhandler": {
+      "version": "5.0.3",
+      "dev": true,
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "domelementtype": "^2.3.0"
+      },
+      "engines": {
+        "node": ">= 4"
+      },
+      "funding": {
+        "url": "https://github.com/fb55/domhandler?sponsor=1"
+      }
+    },
+    "node_modules/domutils": {
+      "version": "3.2.2",
+      "dev": true,
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "dom-serializer": "^2.0.0",
+        "domelementtype": "^2.3.0",
+        "domhandler": "^5.0.3"
+      },
+      "funding": {
+        "url": "https://github.com/fb55/domutils?sponsor=1"
+      }
+    },
+    "node_modules/dot-prop": {
+      "version": "9.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "type-fest": "^4.18.2"
+      },
+      "engines": {
+        "node": ">=18"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/dunder-proto": {
+      "version": "1.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "call-bind-apply-helpers": "^1.0.1",
+        "es-errors": "^1.3.0",
+        "gopd": "^1.2.0"
+      },
+      "engines": {
+        "node": ">= 0.4"
+      }
+    },
+    "node_modules/electron-to-chromium": {
+      "version": "1.5.353",
+      "dev": true,
+      "license": "ISC"
+    },
+    "node_modules/emoji-regex": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/end-of-stream": {
+      "version": "1.4.5",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "once": "^1.4.0"
+      }
+    },
+    "node_modules/enquirer": {
+      "version": "2.4.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "ansi-colors": "^4.1.1",
+        "strip-ansi": "^6.0.1"
+      },
+      "engines": {
+        "node": ">=8.6"
+      }
+    },
+    "node_modules/entities": {
+      "version": "4.5.0",
+      "dev": true,
+      "license": "BSD-2-Clause",
+      "engines": {
+        "node": ">=0.12"
+      },
+      "funding": {
+        "url": "https://github.com/fb55/entities?sponsor=1"
+      }
+    },
+    "node_modules/es-define-property": {
+      "version": "1.0.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 0.4"
+      }
+    },
+    "node_modules/es-errors": {
+      "version": "1.3.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 0.4"
+      }
+    },
+    "node_modules/es-object-atoms": {
+      "version": "1.1.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "es-errors": "^1.3.0"
+      },
+      "engines": {
+        "node": ">= 0.4"
+      }
+    },
+    "node_modules/es-set-tostringtag": {
+      "version": "2.1.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "es-errors": "^1.3.0",
+        "get-intrinsic": "^1.2.6",
+        "has-tostringtag": "^1.0.2",
+        "hasown": "^2.0.2"
+      },
+      "engines": {
+        "node": ">= 0.4"
+      }
+    },
+    "node_modules/escalade": {
+      "version": "3.2.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=6"
+      }
+    },
+    "node_modules/escape-string-regexp": {
+      "version": "4.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=10"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/escodegen": {
+      "version": "2.1.0",
+      "dev": true,
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "esprima": "^4.0.1",
+        "estraverse": "^5.2.0",
+        "esutils": "^2.0.2"
+      },
+      "bin": {
+        "escodegen": "bin/escodegen.js",
+        "esgenerate": "bin/esgenerate.js"
+      },
+      "engines": {
+        "node": ">=6.0"
+      },
+      "optionalDependencies": {
+        "source-map": "~0.6.1"
+      }
+    },
+    "node_modules/esprima": {
+      "version": "4.0.1",
+      "dev": true,
+      "license": "BSD-2-Clause",
+      "bin": {
+        "esparse": "bin/esparse.js",
+        "esvalidate": "bin/esvalidate.js"
+      },
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/estraverse": {
+      "version": "5.3.0",
+      "dev": true,
+      "license": "BSD-2-Clause",
+      "engines": {
+        "node": ">=4.0"
+      }
+    },
+    "node_modules/esutils": {
+      "version": "2.0.3",
+      "dev": true,
+      "license": "BSD-2-Clause",
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/events-universal": {
+      "version": "1.0.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "bare-events": "^2.7.0"
+      }
+    },
+    "node_modules/extract-zip": {
+      "version": "2.0.1",
+      "dev": true,
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "debug": "^4.1.1",
+        "get-stream": "^5.1.0",
+        "yauzl": "^2.10.0"
+      },
+      "bin": {
+        "extract-zip": "cli.js"
+      },
+      "engines": {
+        "node": ">= 10.17.0"
+      },
+      "optionalDependencies": {
+        "@types/yauzl": "^2.9.1"
+      }
+    },
+    "node_modules/fast-fifo": {
+      "version": "1.3.2",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/fast-glob": {
+      "version": "3.3.3",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@nodelib/fs.stat": "^2.0.2",
+        "@nodelib/fs.walk": "^1.2.3",
+        "glob-parent": "^5.1.2",
+        "merge2": "^1.3.0",
+        "micromatch": "^4.0.8"
+      },
+      "engines": {
+        "node": ">=8.6.0"
+      }
+    },
+    "node_modules/fastq": {
+      "version": "1.20.1",
+      "dev": true,
+      "license": "ISC",
+      "dependencies": {
+        "reusify": "^1.0.4"
+      }
+    },
+    "node_modules/fd-slicer": {
+      "version": "1.1.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "pend": "~1.2.0"
+      }
+    },
+    "node_modules/fdir": {
+      "version": "6.5.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=12.0.0"
+      },
+      "peerDependencies": {
+        "picomatch": "^3 || ^4"
+      },
+      "peerDependenciesMeta": {
+        "picomatch": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/fill-range": {
+      "version": "7.1.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "to-regex-range": "^5.0.1"
+      },
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/follow-redirects": {
+      "version": "1.16.0",
+      "dev": true,
+      "funding": [
+        {
+          "type": "individual",
+          "url": "https://github.com/sponsors/RubenVerborgh"
+        }
+      ],
+      "license": "MIT",
+      "engines": {
+        "node": ">=4.0"
+      },
+      "peerDependenciesMeta": {
+        "debug": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/form-data": {
+      "version": "4.0.5",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "asynckit": "^0.4.0",
+        "combined-stream": "^1.0.8",
+        "es-set-tostringtag": "^2.1.0",
+        "hasown": "^2.0.2",
+        "mime-types": "^2.1.12"
+      },
+      "engines": {
+        "node": ">= 6"
+      }
+    },
+    "node_modules/forwarded-parse": {
+      "version": "2.1.2",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/fraction.js": {
+      "version": "5.3.4",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": "*"
+      },
+      "funding": {
+        "type": "github",
+        "url": "https://github.com/sponsors/rawify"
+      }
+    },
+    "node_modules/fs-extra": {
+      "version": "11.3.5",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "graceful-fs": "^4.2.0",
+        "jsonfile": "^6.0.1",
+        "universalify": "^2.0.0"
+      },
+      "engines": {
+        "node": ">=14.14"
+      }
+    },
+    "node_modules/fsevents": {
+      "version": "2.3.3",
+      "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.3.tgz",
+      "integrity": "sha512-5xoDfX+fL7faATnagmWPpbFtwh/R77WmMMqqHGS65C3vvB0YHrgF+B1YmZ3441tMj5n63k0212XNoJwzlhffQw==",
+      "dev": true,
+      "hasInstallScript": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "darwin"
+      ],
+      "engines": {
+        "node": "^8.16.0 || ^10.6.0 || >=11.0.0"
+      }
+    },
+    "node_modules/function-bind": {
+      "version": "1.1.2",
+      "dev": true,
+      "license": "MIT",
+      "funding": {
+        "url": "https://github.com/sponsors/ljharb"
+      }
+    },
+    "node_modules/get-caller-file": {
+      "version": "2.0.5",
+      "dev": true,
+      "license": "ISC",
+      "engines": {
+        "node": "6.* || 8.* || >= 10.*"
+      }
+    },
+    "node_modules/get-east-asian-width": {
+      "version": "1.6.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=18"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/get-intrinsic": {
+      "version": "1.3.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "call-bind-apply-helpers": "^1.0.2",
+        "es-define-property": "^1.0.1",
+        "es-errors": "^1.3.0",
+        "es-object-atoms": "^1.1.1",
+        "function-bind": "^1.1.2",
+        "get-proto": "^1.0.1",
+        "gopd": "^1.2.0",
+        "has-symbols": "^1.1.0",
+        "hasown": "^2.0.2",
+        "math-intrinsics": "^1.1.0"
+      },
+      "engines": {
+        "node": ">= 0.4"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/ljharb"
+      }
+    },
+    "node_modules/get-proto": {
+      "version": "1.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "dunder-proto": "^1.0.1",
+        "es-object-atoms": "^1.0.0"
+      },
+      "engines": {
+        "node": ">= 0.4"
+      }
+    },
+    "node_modules/get-stream": {
+      "version": "5.2.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "pump": "^3.0.0"
+      },
+      "engines": {
+        "node": ">=8"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/get-uri": {
+      "version": "6.0.5",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "basic-ftp": "^5.0.2",
+        "data-uri-to-buffer": "^6.0.2",
+        "debug": "^4.3.4"
+      },
+      "engines": {
+        "node": ">= 14"
+      }
+    },
+    "node_modules/glob-parent": {
+      "version": "5.1.2",
+      "dev": true,
+      "license": "ISC",
+      "dependencies": {
+        "is-glob": "^4.0.1"
+      },
+      "engines": {
+        "node": ">= 6"
+      }
+    },
+    "node_modules/gopd": {
+      "version": "1.2.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 0.4"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/ljharb"
+      }
+    },
+    "node_modules/graceful-fs": {
+      "version": "4.2.11",
+      "dev": true,
+      "license": "ISC"
+    },
+    "node_modules/has-symbols": {
+      "version": "1.1.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 0.4"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/ljharb"
+      }
+    },
+    "node_modules/has-tostringtag": {
+      "version": "1.0.2",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "has-symbols": "^1.0.3"
+      },
+      "engines": {
+        "node": ">= 0.4"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/ljharb"
+      }
+    },
+    "node_modules/hasown": {
+      "version": "2.0.3",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "function-bind": "^1.1.2"
+      },
+      "engines": {
+        "node": ">= 0.4"
+      }
+    },
+    "node_modules/http-link-header": {
+      "version": "1.1.3",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=6.0.0"
+      }
+    },
+    "node_modules/http-proxy-agent": {
+      "version": "7.0.2",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "agent-base": "^7.1.0",
+        "debug": "^4.3.4"
+      },
+      "engines": {
+        "node": ">= 14"
+      }
+    },
+    "node_modules/https-proxy-agent": {
+      "version": "7.0.6",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "agent-base": "^7.1.2",
+        "debug": "4"
+      },
+      "engines": {
+        "node": ">= 14"
+      }
+    },
+    "node_modules/human-readable-numbers": {
+      "version": "0.9.5",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/ignore": {
+      "version": "7.0.5",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 4"
+      }
+    },
+    "node_modules/image-ssim": {
+      "version": "0.2.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/import-in-the-middle": {
+      "version": "1.15.0",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "acorn": "^8.14.0",
+        "acorn-import-attributes": "^1.9.5",
+        "cjs-module-lexer": "^1.2.2",
+        "module-details-from-path": "^1.0.3"
+      }
+    },
+    "node_modules/ini": {
+      "version": "4.1.3",
+      "dev": true,
+      "license": "ISC",
+      "engines": {
+        "node": "^14.17.0 || ^16.13.0 || >=18.0.0"
+      }
+    },
+    "node_modules/intl-messageformat": {
+      "version": "10.7.18",
+      "dev": true,
+      "license": "BSD-3-Clause",
+      "dependencies": {
+        "@formatjs/ecma402-abstract": "2.3.6",
+        "@formatjs/fast-memoize": "2.2.7",
+        "@formatjs/icu-messageformat-parser": "2.11.4",
+        "tslib": "^2.8.0"
+      }
+    },
+    "node_modules/ip-address": {
+      "version": "10.2.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 12"
+      }
+    },
+    "node_modules/is-alphabetical": {
+      "version": "2.0.1",
+      "dev": true,
+      "license": "MIT",
+      "funding": {
+        "type": "github",
+        "url": "https://github.com/sponsors/wooorm"
+      }
+    },
+    "node_modules/is-alphanumerical": {
+      "version": "2.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "is-alphabetical": "^2.0.0",
+        "is-decimal": "^2.0.0"
+      },
+      "funding": {
+        "type": "github",
+        "url": "https://github.com/sponsors/wooorm"
+      }
+    },
+    "node_modules/is-binary-path": {
+      "version": "2.1.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "binary-extensions": "^2.0.0"
+      },
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/is-core-module": {
+      "version": "2.16.2",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "hasown": "^2.0.3"
+      },
+      "engines": {
+        "node": ">= 0.4"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/ljharb"
+      }
+    },
+    "node_modules/is-decimal": {
+      "version": "2.0.1",
+      "dev": true,
+      "license": "MIT",
+      "funding": {
+        "type": "github",
+        "url": "https://github.com/sponsors/wooorm"
+      }
+    },
+    "node_modules/is-docker": {
+      "version": "2.2.1",
+      "dev": true,
+      "license": "MIT",
+      "bin": {
+        "is-docker": "cli.js"
+      },
+      "engines": {
+        "node": ">=8"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/is-domain": {
+      "version": "0.0.1",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/is-extglob": {
+      "version": "2.1.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/is-fullwidth-code-point": {
+      "version": "3.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/is-glob": {
+      "version": "4.0.3",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "is-extglob": "^2.1.1"
+      },
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/is-hexadecimal": {
+      "version": "2.0.1",
+      "dev": true,
+      "license": "MIT",
+      "funding": {
+        "type": "github",
+        "url": "https://github.com/sponsors/wooorm"
+      }
+    },
+    "node_modules/is-number": {
+      "version": "7.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=0.12.0"
+      }
+    },
+    "node_modules/is-wsl": {
+      "version": "2.2.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "is-docker": "^2.0.0"
+      },
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/jpeg-js": {
+      "version": "0.4.4",
+      "dev": true,
+      "license": "BSD-3-Clause"
+    },
+    "node_modules/js-library-detector": {
+      "version": "6.7.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=12"
+      }
+    },
+    "node_modules/js-yaml": {
+      "version": "4.1.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "argparse": "^2.0.1"
+      },
+      "bin": {
+        "js-yaml": "bin/js-yaml.js"
+      }
+    },
+    "node_modules/jsonc-parser": {
+      "version": "3.3.1",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/jsonfile": {
+      "version": "6.2.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "universalify": "^2.0.0"
+      },
+      "optionalDependencies": {
+        "graceful-fs": "^4.1.6"
+      }
+    },
+    "node_modules/jsonpointer": {
+      "version": "5.0.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/katex": {
+      "version": "0.16.45",
+      "dev": true,
+      "funding": [
+        "https://opencollective.com/katex",
+        "https://github.com/sponsors/katex"
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "commander": "^8.3.0"
+      },
+      "bin": {
+        "katex": "cli.js"
+      }
+    },
+    "node_modules/katex/node_modules/commander": {
+      "version": "8.3.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 12"
+      }
+    },
+    "node_modules/kleur": {
+      "version": "3.0.3",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=6"
+      }
+    },
+    "node_modules/legacy-javascript": {
+      "version": "0.0.1",
+      "resolved": "https://registry.npmjs.org/legacy-javascript/-/legacy-javascript-0.0.1.tgz",
+      "integrity": "sha512-lPyntS4/aS7jpuvOlitZDFifBCb4W8L/3QU0PLbUTUj+zYah8rfVjYic88yG7ZKTxhS5h9iz7duT8oUXKszLhg==",
+      "dev": true,
+      "license": "Apache-2.0"
+    },
+    "node_modules/lighthouse": {
+      "version": "13.3.0",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@paulirish/trace_engine": "0.0.64",
+        "@sentry/node": "^9.28.1",
+        "axe-core": "^4.11.4",
+        "chrome-launcher": "^1.2.1",
+        "configstore": "^7.0.0",
+        "csp_evaluator": "1.1.5",
+        "devtools-protocol": "0.0.1625959",
+        "enquirer": "^2.3.6",
+        "http-link-header": "^1.1.1",
+        "intl-messageformat": "^10.5.3",
+        "jpeg-js": "^0.4.4",
+        "js-library-detector": "^6.7.0",
+        "lighthouse-logger": "^2.0.2",
+        "lighthouse-stack-packs": "1.12.3",
+        "lodash-es": "^4.17.21",
+        "lookup-closest-locale": "6.2.0",
+        "open": "^8.4.0",
+        "puppeteer-core": "^24.43.0",
+        "robots-parser": "^3.0.1",
+        "speedline-core": "^1.4.3",
+        "third-party-web": "^0.29.0",
+        "tldts-icann": "^7.0.30",
+        "web-features": "^3.26.0",
+        "ws": "^7.0.0",
+        "yargs": "^17.3.1",
+        "yargs-parser": "^21.0.0"
+      },
+      "bin": {
+        "chrome-debug": "core/scripts/manual-chrome-launcher.js",
+        "lighthouse": "cli/index.js",
+        "smokehouse": "cli/test/smokehouse/frontends/smokehouse-bin.js"
+      },
+      "engines": {
+        "node": ">=22.19"
+      }
+    },
+    "node_modules/lighthouse-logger": {
+      "version": "2.0.2",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "debug": "^4.4.1",
+        "marky": "^1.2.2"
+      }
+    },
+    "node_modules/lighthouse-stack-packs": {
+      "version": "1.12.3",
+      "dev": true,
+      "license": "Apache-2.0"
+    },
+    "node_modules/lilconfig": {
+      "version": "3.1.3",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=14"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/antonk52"
+      }
+    },
+    "node_modules/linkify-it": {
+      "version": "5.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "uc.micro": "^2.0.0"
+      }
+    },
+    "node_modules/lodash-es": {
+      "version": "4.18.1",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/lodash.memoize": {
+      "version": "4.1.2",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/lodash.uniq": {
+      "version": "4.5.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/lookup-closest-locale": {
+      "version": "6.2.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/lru-cache": {
+      "version": "7.18.3",
+      "dev": true,
+      "license": "ISC",
+      "engines": {
+        "node": ">=12"
+      }
+    },
+    "node_modules/markdown-it": {
+      "version": "14.1.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "argparse": "^2.0.1",
+        "entities": "^4.4.0",
+        "linkify-it": "^5.0.0",
+        "mdurl": "^2.0.0",
+        "punycode.js": "^2.3.1",
+        "uc.micro": "^2.1.0"
+      },
+      "bin": {
+        "markdown-it": "bin/markdown-it.mjs"
+      }
+    },
+    "node_modules/markdownlint": {
+      "version": "0.40.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "micromark": "4.0.2",
+        "micromark-core-commonmark": "2.0.3",
+        "micromark-extension-directive": "4.0.0",
+        "micromark-extension-gfm-autolink-literal": "2.1.0",
+        "micromark-extension-gfm-footnote": "2.1.0",
+        "micromark-extension-gfm-table": "2.1.1",
+        "micromark-extension-math": "3.1.0",
+        "micromark-util-types": "2.0.2",
+        "string-width": "8.1.0"
+      },
+      "engines": {
+        "node": ">=20"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/DavidAnson"
+      }
+    },
+    "node_modules/markdownlint-cli": {
+      "version": "0.48.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "commander": "~14.0.3",
+        "deep-extend": "~0.6.0",
+        "ignore": "~7.0.5",
+        "js-yaml": "~4.1.1",
+        "jsonc-parser": "~3.3.1",
+        "jsonpointer": "~5.0.1",
+        "markdown-it": "~14.1.1",
+        "markdownlint": "~0.40.0",
+        "minimatch": "~10.2.4",
+        "run-con": "~1.3.2",
+        "smol-toml": "~1.6.0",
+        "tinyglobby": "~0.2.15"
+      },
+      "bin": {
+        "markdownlint": "markdownlint.js"
+      },
+      "engines": {
+        "node": ">=20"
+      }
+    },
+    "node_modules/markdownlint/node_modules/string-width": {
+      "version": "8.1.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "get-east-asian-width": "^1.3.0",
+        "strip-ansi": "^7.1.0"
+      },
+      "engines": {
+        "node": ">=20"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/markdownlint/node_modules/string-width/node_modules/strip-ansi": {
+      "version": "7.2.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "ansi-regex": "^6.2.2"
+      },
+      "engines": {
+        "node": ">=12"
+      },
+      "funding": {
+        "url": "https://github.com/chalk/strip-ansi?sponsor=1"
+      }
+    },
+    "node_modules/markdownlint/node_modules/string-width/node_modules/strip-ansi/node_modules/ansi-regex": {
+      "version": "6.2.2",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=12"
+      },
+      "funding": {
+        "url": "https://github.com/chalk/ansi-regex?sponsor=1"
+      }
+    },
+    "node_modules/marky": {
+      "version": "1.3.0",
+      "dev": true,
+      "license": "Apache-2.0"
+    },
+    "node_modules/math-intrinsics": {
+      "version": "1.1.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 0.4"
+      }
+    },
+    "node_modules/mdurl": {
+      "version": "2.0.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/merge2": {
+      "version": "1.4.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 8"
+      }
+    },
+    "node_modules/micromark": {
+      "version": "4.0.2",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "@types/debug": "^4.0.0",
+        "debug": "^4.0.0",
+        "decode-named-character-reference": "^1.0.0",
+        "devlop": "^1.0.0",
+        "micromark-core-commonmark": "^2.0.0",
+        "micromark-factory-space": "^2.0.0",
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-chunked": "^2.0.0",
+        "micromark-util-combine-extensions": "^2.0.0",
+        "micromark-util-decode-numeric-character-reference": "^2.0.0",
+        "micromark-util-encode": "^2.0.0",
+        "micromark-util-normalize-identifier": "^2.0.0",
+        "micromark-util-resolve-all": "^2.0.0",
+        "micromark-util-sanitize-uri": "^2.0.0",
+        "micromark-util-subtokenize": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-core-commonmark": {
+      "version": "2.0.3",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "decode-named-character-reference": "^1.0.0",
+        "devlop": "^1.0.0",
+        "micromark-factory-destination": "^2.0.0",
+        "micromark-factory-label": "^2.0.0",
+        "micromark-factory-space": "^2.0.0",
+        "micromark-factory-title": "^2.0.0",
+        "micromark-factory-whitespace": "^2.0.0",
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-chunked": "^2.0.0",
+        "micromark-util-classify-character": "^2.0.0",
+        "micromark-util-html-tag-name": "^2.0.0",
+        "micromark-util-normalize-identifier": "^2.0.0",
+        "micromark-util-resolve-all": "^2.0.0",
+        "micromark-util-subtokenize": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-extension-directive": {
+      "version": "4.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "devlop": "^1.0.0",
+        "micromark-factory-space": "^2.0.0",
+        "micromark-factory-whitespace": "^2.0.0",
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0",
+        "parse-entities": "^4.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/unified"
+      }
+    },
+    "node_modules/micromark-extension-gfm-autolink-literal": {
+      "version": "2.1.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-sanitize-uri": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/unified"
+      }
+    },
+    "node_modules/micromark-extension-gfm-footnote": {
+      "version": "2.1.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "devlop": "^1.0.0",
+        "micromark-core-commonmark": "^2.0.0",
+        "micromark-factory-space": "^2.0.0",
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-normalize-identifier": "^2.0.0",
+        "micromark-util-sanitize-uri": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/unified"
+      }
+    },
+    "node_modules/micromark-extension-gfm-table": {
+      "version": "2.1.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "devlop": "^1.0.0",
+        "micromark-factory-space": "^2.0.0",
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/unified"
+      }
+    },
+    "node_modules/micromark-extension-math": {
+      "version": "3.1.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/katex": "^0.16.0",
+        "devlop": "^1.0.0",
+        "katex": "^0.16.0",
+        "micromark-factory-space": "^2.0.0",
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/unified"
+      }
+    },
+    "node_modules/micromark-factory-destination": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-factory-label": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "devlop": "^1.0.0",
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-factory-space": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-factory-title": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "micromark-factory-space": "^2.0.0",
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-factory-whitespace": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "micromark-factory-space": "^2.0.0",
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-util-character": {
+      "version": "2.1.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-util-chunked": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "micromark-util-symbol": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-util-classify-character": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-util-combine-extensions": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "micromark-util-chunked": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-util-decode-numeric-character-reference": {
+      "version": "2.0.2",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "micromark-util-symbol": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-util-encode": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT"
+    },
+    "node_modules/micromark-util-html-tag-name": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT"
+    },
+    "node_modules/micromark-util-normalize-identifier": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "micromark-util-symbol": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-util-resolve-all": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "micromark-util-types": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-util-sanitize-uri": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "micromark-util-character": "^2.0.0",
+        "micromark-util-encode": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-util-subtokenize": {
+      "version": "2.1.0",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "devlop": "^1.0.0",
+        "micromark-util-chunked": "^2.0.0",
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
+      }
+    },
+    "node_modules/micromark-util-symbol": {
+      "version": "2.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT"
+    },
+    "node_modules/micromark-util-types": {
+      "version": "2.0.2",
+      "dev": true,
+      "funding": [
+        {
+          "type": "GitHub Sponsors",
+          "url": "https://github.com/sponsors/unifiedjs"
+        },
+        {
+          "type": "OpenCollective",
+          "url": "https://opencollective.com/unified"
+        }
+      ],
+      "license": "MIT"
+    },
+    "node_modules/micromatch": {
+      "version": "4.0.8",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "braces": "^3.0.3",
+        "picomatch": "^2.3.1"
+      },
+      "engines": {
+        "node": ">=8.6"
+      }
+    },
+    "node_modules/micromatch/node_modules/picomatch": {
+      "version": "2.3.2",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=8.6"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/jonschlinkert"
+      }
+    },
+    "node_modules/mime-db": {
+      "version": "1.52.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 0.6"
+      }
+    },
+    "node_modules/mime-types": {
+      "version": "2.1.35",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "mime-db": "1.52.0"
+      },
+      "engines": {
+        "node": ">= 0.6"
+      }
+    },
+    "node_modules/minimatch": {
+      "version": "10.2.5",
+      "dev": true,
+      "license": "BlueOak-1.0.0",
+      "dependencies": {
+        "brace-expansion": "^5.0.5"
+      },
+      "engines": {
+        "node": "18 || 20 || >=22"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/isaacs"
+      }
+    },
+    "node_modules/minimist": {
+      "version": "1.2.8",
+      "dev": true,
+      "license": "MIT",
+      "funding": {
+        "url": "https://github.com/sponsors/ljharb"
+      }
+    },
+    "node_modules/minipass": {
+      "version": "7.1.3",
+      "dev": true,
+      "license": "BlueOak-1.0.0",
+      "engines": {
+        "node": ">=16 || 14 >=14.17"
+      }
+    },
+    "node_modules/minizlib": {
+      "version": "3.1.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "minipass": "^7.1.2"
+      },
+      "engines": {
+        "node": ">= 18"
+      }
+    },
+    "node_modules/mitt": {
+      "version": "3.0.1",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/module-details-from-path": {
+      "version": "1.0.4",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/moniker": {
+      "version": "0.1.2",
+      "dev": true
+    },
+    "node_modules/ms": {
+      "version": "2.1.3",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/mute-stream": {
+      "version": "0.0.8",
+      "dev": true,
+      "license": "ISC"
+    },
+    "node_modules/nanoid": {
+      "version": "3.3.12",
+      "dev": true,
+      "funding": [
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "bin": {
+        "nanoid": "bin/nanoid.cjs"
+      },
+      "engines": {
+        "node": "^10 || ^12 || ^13.7 || ^14 || >=15.0.1"
+      }
+    },
+    "node_modules/netmask": {
+      "version": "2.1.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 0.4.0"
+      }
+    },
+    "node_modules/netrc": {
+      "version": "0.1.4",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/node-releases": {
+      "version": "2.0.38",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/normalize-path": {
+      "version": "3.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/nth-check": {
+      "version": "2.1.1",
+      "dev": true,
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "boolbase": "^1.0.0"
+      },
+      "funding": {
+        "url": "https://github.com/fb55/nth-check?sponsor=1"
+      }
+    },
+    "node_modules/once": {
+      "version": "1.4.0",
+      "dev": true,
+      "license": "ISC",
+      "dependencies": {
+        "wrappy": "1"
+      }
+    },
+    "node_modules/open": {
+      "version": "8.4.2",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "define-lazy-prop": "^2.0.0",
+        "is-docker": "^2.1.1",
+        "is-wsl": "^2.2.0"
+      },
+      "engines": {
+        "node": ">=12"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/pac-proxy-agent": {
+      "version": "7.2.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@tootallnate/quickjs-emscripten": "^0.23.0",
+        "agent-base": "^7.1.2",
+        "debug": "^4.3.4",
+        "get-uri": "^6.0.1",
+        "http-proxy-agent": "^7.0.0",
+        "https-proxy-agent": "^7.0.6",
+        "pac-resolver": "^7.0.1",
+        "socks-proxy-agent": "^8.0.5"
+      },
+      "engines": {
+        "node": ">= 14"
+      }
+    },
+    "node_modules/pac-resolver": {
+      "version": "7.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "degenerator": "^5.0.0",
+        "netmask": "^2.0.2"
+      },
+      "engines": {
+        "node": ">= 14"
+      }
+    },
+    "node_modules/parse-entities": {
+      "version": "4.0.2",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/unist": "^2.0.0",
+        "character-entities-legacy": "^3.0.0",
+        "character-reference-invalid": "^2.0.0",
+        "decode-named-character-reference": "^1.0.0",
+        "is-alphanumerical": "^2.0.0",
+        "is-decimal": "^2.0.0",
+        "is-hexadecimal": "^2.0.0"
+      },
+      "funding": {
+        "type": "github",
+        "url": "https://github.com/sponsors/wooorm"
+      }
+    },
+    "node_modules/path-parse": {
+      "version": "1.0.7",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/pend": {
+      "version": "1.2.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/pg-int8": {
+      "version": "1.0.1",
+      "dev": true,
+      "license": "ISC",
+      "engines": {
+        "node": ">=4.0.0"
+      }
+    },
+    "node_modules/pg-protocol": {
+      "version": "1.13.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/pg-types": {
+      "version": "2.2.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "pg-int8": "1.0.1",
+        "postgres-array": "~2.0.0",
+        "postgres-bytea": "~1.0.0",
+        "postgres-date": "~1.0.4",
+        "postgres-interval": "^1.1.0"
+      },
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/picocolors": {
+      "version": "1.1.1",
+      "dev": true,
+      "license": "ISC"
+    },
+    "node_modules/picomatch": {
+      "version": "4.0.4",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=12"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/jonschlinkert"
+      }
+    },
+    "node_modules/pify": {
+      "version": "2.3.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/postcss": {
+      "version": "8.5.15",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/postcss/"
+        },
+        {
+          "type": "tidelift",
+          "url": "https://tidelift.com/funding/github/npm/postcss"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "nanoid": "^3.3.12",
+        "picocolors": "^1.1.1",
+        "source-map-js": "^1.2.1"
+      },
+      "engines": {
+        "node": "^10 || ^12 || >=14"
+      }
+    },
+    "node_modules/postcss-calc": {
+      "version": "10.1.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-selector-parser": "^7.0.0",
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^18.12 || ^20.9 || >=22.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.4.38"
+      }
+    },
+    "node_modules/postcss-calc/node_modules/postcss-selector-parser": {
+      "version": "7.1.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "cssesc": "^3.0.0",
+        "util-deprecate": "^1.0.2"
+      },
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/postcss-cli": {
+      "version": "11.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "chokidar": "^3.3.0",
+        "dependency-graph": "^1.0.0",
+        "fs-extra": "^11.0.0",
+        "picocolors": "^1.0.0",
+        "postcss-load-config": "^5.0.0",
+        "postcss-reporter": "^7.0.0",
+        "pretty-hrtime": "^1.0.3",
+        "read-cache": "^1.0.0",
+        "slash": "^5.0.0",
+        "tinyglobby": "^0.2.12",
+        "yargs": "^17.0.0"
+      },
+      "bin": {
+        "postcss": "index.js"
+      },
+      "engines": {
+        "node": ">=18"
+      },
+      "peerDependencies": {
+        "postcss": "^8.0.0"
+      }
+    },
+    "node_modules/postcss-cli/node_modules/tinyglobby": {
+      "version": "0.2.12",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "fdir": "^6.4.3",
+        "picomatch": "^4.0.2"
+      },
+      "engines": {
+        "node": ">=12.0.0"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/SuperchupuDev"
+      }
+    },
+    "node_modules/postcss-cli/node_modules/tinyglobby/node_modules/fdir": {
+      "version": "6.4.3",
+      "dev": true,
+      "license": "MIT",
+      "peerDependencies": {
+        "picomatch": "^3 || ^4"
+      },
+      "peerDependenciesMeta": {
+        "picomatch": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/postcss-cli/node_modules/tinyglobby/node_modules/picomatch": {
+      "version": "4.0.2",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=12"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/jonschlinkert"
+      }
+    },
+    "node_modules/postcss-colormin": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@colordx/core": "^5.4.3",
+        "browserslist": "^4.28.2",
+        "caniuse-api": "^3.0.0",
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-convert-values": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "browserslist": "^4.28.2",
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-delete-duplicate-css": {
+      "version": "1.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=10.0.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.2.8"
+      }
+    },
+    "node_modules/postcss-discard-comments": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-selector-parser": "^7.1.1"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-discard-comments/node_modules/postcss-selector-parser": {
+      "version": "7.1.1",
+      "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-7.1.1.tgz",
+      "integrity": "sha512-orRsuYpJVw8LdAwqqLykBj9ecS5/cRHlI5+nvTo8LcCKmzDmqVORXtOIYEEQuL9D4BxtA1lm5isAqzQZCoQ6Eg==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "cssesc": "^3.0.0",
+        "util-deprecate": "^1.0.2"
+      },
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/postcss-discard-duplicates": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-discard-empty": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-discard-overridden": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-extend-rule": {
+      "version": "4.0.0",
+      "dev": true,
+      "license": "CC0-1.0",
+      "dependencies": {
+        "postcss-nesting": "^10.1.2"
+      },
+      "engines": {
+        "node": "^12 || ^14 || >=16"
+      },
+      "peerDependencies": {
+        "postcss": "^8.4.6"
+      }
+    },
+    "node_modules/postcss-import": {
+      "version": "16.1.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-value-parser": "^4.0.0",
+        "read-cache": "^1.0.0",
+        "resolve": "^1.1.7"
+      },
+      "engines": {
+        "node": ">=18.0.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.0.0"
+      }
+    },
+    "node_modules/postcss-js": {
+      "version": "4.1.0",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/postcss/"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "camelcase-css": "^2.0.1"
+      },
+      "engines": {
+        "node": "^12 || ^14 || >= 16"
+      },
+      "peerDependencies": {
+        "postcss": "^8.4.21"
+      }
+    },
+    "node_modules/postcss-load-config": {
+      "version": "5.1.0",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/postcss/"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "lilconfig": "^3.1.1",
+        "yaml": "^2.4.2"
+      },
+      "engines": {
+        "node": ">= 18"
+      },
+      "peerDependencies": {
+        "jiti": ">=1.21.0",
+        "postcss": ">=8.0.9",
+        "tsx": "^4.8.1"
+      },
+      "peerDependenciesMeta": {
+        "jiti": {
+          "optional": true
+        },
+        "postcss": {
+          "optional": true
+        },
+        "tsx": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/postcss-load-config/node_modules/lilconfig": {
+      "version": "3.1.2",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=14"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/antonk52"
+      }
+    },
+    "node_modules/postcss-merge-longhand": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-value-parser": "^4.2.0",
+        "stylehacks": "^8.0.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-merge-rules": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "browserslist": "^4.28.2",
+        "caniuse-api": "^3.0.0",
+        "cssnano-utils": "^6.0.0",
+        "postcss-selector-parser": "^7.1.1"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-merge-rules/node_modules/postcss-selector-parser": {
+      "version": "7.1.1",
+      "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-7.1.1.tgz",
+      "integrity": "sha512-orRsuYpJVw8LdAwqqLykBj9ecS5/cRHlI5+nvTo8LcCKmzDmqVORXtOIYEEQuL9D4BxtA1lm5isAqzQZCoQ6Eg==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "cssesc": "^3.0.0",
+        "util-deprecate": "^1.0.2"
+      },
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/postcss-minify-font-values": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-minify-gradients": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@colordx/core": "^5.4.3",
+        "cssnano-utils": "^6.0.0",
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-minify-params": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "browserslist": "^4.28.2",
+        "cssnano-utils": "^6.0.0",
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-minify-selectors": {
+      "version": "8.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "browserslist": "^4.28.1",
+        "caniuse-api": "^3.0.0",
+        "cssesc": "^3.0.0",
+        "postcss-selector-parser": "^7.1.1"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-minify-selectors/node_modules/postcss-selector-parser": {
+      "version": "7.1.1",
+      "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-7.1.1.tgz",
+      "integrity": "sha512-orRsuYpJVw8LdAwqqLykBj9ecS5/cRHlI5+nvTo8LcCKmzDmqVORXtOIYEEQuL9D4BxtA1lm5isAqzQZCoQ6Eg==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "cssesc": "^3.0.0",
+        "util-deprecate": "^1.0.2"
+      },
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/postcss-mixins": {
+      "version": "12.1.2",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/postcss/"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "postcss-js": "^4.0.1",
+        "postcss-simple-vars": "^7.0.1",
+        "sugarss": "^5.0.0",
+        "tinyglobby": "^0.2.14"
+      },
+      "engines": {
+        "node": "^20.0 || ^22.0 || >=24.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.2.14"
+      }
+    },
+    "node_modules/postcss-nested": {
+      "version": "7.0.2",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/postcss/"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "postcss-selector-parser": "^7.0.0"
+      },
+      "engines": {
+        "node": ">=18.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.2.14"
+      }
+    },
+    "node_modules/postcss-nested/node_modules/postcss-selector-parser": {
+      "version": "7.1.1",
+      "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-7.1.1.tgz",
+      "integrity": "sha512-orRsuYpJVw8LdAwqqLykBj9ecS5/cRHlI5+nvTo8LcCKmzDmqVORXtOIYEEQuL9D4BxtA1lm5isAqzQZCoQ6Eg==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "cssesc": "^3.0.0",
+        "util-deprecate": "^1.0.2"
+      },
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/postcss-nesting": {
+      "version": "10.2.0",
+      "dev": true,
+      "license": "CC0-1.0",
+      "dependencies": {
+        "@csstools/selector-specificity": "^2.0.0",
+        "postcss-selector-parser": "^6.0.10"
+      },
+      "engines": {
+        "node": "^12 || ^14 || >=16"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/csstools"
+      },
+      "peerDependencies": {
+        "postcss": "^8.2"
+      }
+    },
+    "node_modules/postcss-normalize-charset": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-normalize-display-values": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-normalize-positions": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-normalize-repeat-style": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-normalize-string": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-normalize-timing-functions": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-normalize-unicode": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "browserslist": "^4.28.2",
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-normalize-url": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-normalize-whitespace": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-ordered-values": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "cssnano-utils": "^6.0.0",
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-reduce-initial": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "browserslist": "^4.28.2",
+        "caniuse-api": "^3.0.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-reduce-transforms": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-value-parser": "^4.2.0"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-reporter": {
+      "version": "7.1.0",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/postcss/"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "picocolors": "^1.0.0",
+        "thenby": "^1.3.4"
+      },
+      "engines": {
+        "node": ">=10"
+      },
+      "peerDependencies": {
+        "postcss": "^8.1.0"
+      }
+    },
+    "node_modules/postcss-reporter/node_modules/picocolors": {
+      "version": "1.1.0",
+      "dev": true,
+      "license": "ISC"
+    },
+    "node_modules/postcss-selector-parser": {
+      "version": "6.1.2",
+      "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-6.1.2.tgz",
+      "integrity": "sha512-Q8qQfPiZ+THO/3ZrOrO0cJJKfpYCagtMUkXbnEfmgUjwXg6z/WBeOyS9APBBPCTSiDV+s4SwQGu8yFsiMRIudg==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "cssesc": "^3.0.0",
+        "util-deprecate": "^1.0.2"
+      },
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/postcss-simple-vars": {
+      "version": "7.0.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=14.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/postcss/"
+      },
+      "peerDependencies": {
+        "postcss": "^8.2.1"
+      }
+    },
+    "node_modules/postcss-svgo": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-value-parser": "^4.2.0",
+        "svgo": "^4.0.1"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-unique-selectors": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "postcss-selector-parser": "^7.1.1"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/postcss-unique-selectors/node_modules/postcss-selector-parser": {
+      "version": "7.1.1",
+      "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-7.1.1.tgz",
+      "integrity": "sha512-orRsuYpJVw8LdAwqqLykBj9ecS5/cRHlI5+nvTo8LcCKmzDmqVORXtOIYEEQuL9D4BxtA1lm5isAqzQZCoQ6Eg==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "cssesc": "^3.0.0",
+        "util-deprecate": "^1.0.2"
+      },
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/postcss-value-parser": {
+      "version": "4.2.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/postgres-array": {
+      "version": "2.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/postgres-bytea": {
+      "version": "1.0.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/postgres-date": {
+      "version": "1.0.7",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/postgres-interval": {
+      "version": "1.2.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "xtend": "^4.0.0"
+      },
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/pretty-hrtime": {
+      "version": "1.0.3",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 0.8"
+      }
+    },
+    "node_modules/progress": {
+      "version": "2.0.3",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=0.4.0"
+      }
+    },
+    "node_modules/prompts": {
+      "version": "2.4.2",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "kleur": "^3.0.3",
+        "sisteransi": "^1.0.5"
+      },
+      "engines": {
+        "node": ">= 6"
+      }
+    },
+    "node_modules/proxy-agent": {
+      "version": "6.5.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "agent-base": "^7.1.2",
+        "debug": "^4.3.4",
+        "http-proxy-agent": "^7.0.1",
+        "https-proxy-agent": "^7.0.6",
+        "lru-cache": "^7.14.1",
+        "pac-proxy-agent": "^7.1.0",
+        "proxy-from-env": "^1.1.0",
+        "socks-proxy-agent": "^8.0.5"
+      },
+      "engines": {
+        "node": ">= 14"
+      }
+    },
+    "node_modules/proxy-from-env": {
+      "version": "1.1.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/pump": {
+      "version": "3.0.4",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "end-of-stream": "^1.1.0",
+        "once": "^1.3.1"
+      }
+    },
+    "node_modules/punycode.js": {
+      "version": "2.3.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=6"
+      }
+    },
+    "node_modules/puppeteer-core": {
+      "version": "24.43.0",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "@puppeteer/browsers": "2.13.1",
+        "chromium-bidi": "14.0.0",
+        "debug": "^4.4.3",
+        "devtools-protocol": "0.0.1608973",
+        "typed-query-selector": "^2.12.2",
+        "webdriver-bidi-protocol": "0.4.1",
+        "ws": "^8.20.0"
+      },
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/puppeteer-core/node_modules/debug": {
+      "version": "4.4.3",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "ms": "^2.1.3"
+      },
+      "engines": {
+        "node": ">=6.0"
+      },
+      "peerDependenciesMeta": {
+        "supports-color": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/puppeteer-core/node_modules/devtools-protocol": {
+      "version": "0.0.1608973",
+      "dev": true,
+      "license": "BSD-3-Clause"
+    },
+    "node_modules/puppeteer-core/node_modules/ws": {
+      "version": "8.20.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=10.0.0"
+      },
+      "peerDependencies": {
+        "bufferutil": "^4.0.1",
+        "utf-8-validate": ">=5.0.2"
+      },
+      "peerDependenciesMeta": {
+        "bufferutil": {
+          "optional": true
+        },
+        "utf-8-validate": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/purgecss": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "commander": "^12.1.0",
+        "fast-glob": "^3.3.2",
+        "postcss": "^8.4.47",
+        "postcss-selector-parser": "^7.0.0"
+      },
+      "bin": {
+        "purgecss": "bin/purgecss.js"
+      }
+    },
+    "node_modules/purgecss/node_modules/commander": {
+      "version": "12.1.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/purgecss/node_modules/postcss": {
+      "version": "8.5.14",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/postcss/"
+        },
+        {
+          "type": "tidelift",
+          "url": "https://tidelift.com/funding/github/npm/postcss"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "nanoid": "^3.3.11",
+        "picocolors": "^1.1.1",
+        "source-map-js": "^1.2.1"
+      },
+      "engines": {
+        "node": "^10 || ^12 || >=14"
+      }
+    },
+    "node_modules/purgecss/node_modules/postcss-selector-parser": {
+      "version": "7.1.1",
+      "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-7.1.1.tgz",
+      "integrity": "sha512-orRsuYpJVw8LdAwqqLykBj9ecS5/cRHlI5+nvTo8LcCKmzDmqVORXtOIYEEQuL9D4BxtA1lm5isAqzQZCoQ6Eg==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "cssesc": "^3.0.0",
+        "util-deprecate": "^1.0.2"
+      },
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/queue-microtask": {
+      "version": "1.2.3",
+      "dev": true,
+      "funding": [
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/feross"
+        },
+        {
+          "type": "patreon",
+          "url": "https://www.patreon.com/feross"
+        },
+        {
+          "type": "consulting",
+          "url": "https://feross.org/support"
+        }
+      ],
+      "license": "MIT"
+    },
+    "node_modules/read": {
+      "version": "1.0.5",
+      "dev": true,
+      "license": "BSD",
+      "dependencies": {
+        "mute-stream": "~0.0.4"
+      },
+      "engines": {
+        "node": ">=0.8"
+      }
+    },
+    "node_modules/read-cache": {
+      "version": "1.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "pify": "^2.3.0"
+      }
+    },
+    "node_modules/readdirp": {
+      "version": "3.6.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "picomatch": "^2.2.1"
+      },
+      "engines": {
+        "node": ">=8.10.0"
+      }
+    },
+    "node_modules/readdirp/node_modules/picomatch": {
+      "version": "2.3.2",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=8.6"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/jonschlinkert"
+      }
+    },
+    "node_modules/require-directory": {
+      "version": "2.1.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/require-in-the-middle": {
+      "version": "7.5.2",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "debug": "^4.3.5",
+        "module-details-from-path": "^1.0.3",
+        "resolve": "^1.22.8"
+      },
+      "engines": {
+        "node": ">=8.6.0"
+      }
+    },
+    "node_modules/resolve": {
+      "version": "1.22.12",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "es-errors": "^1.3.0",
+        "is-core-module": "^2.16.1",
+        "path-parse": "^1.0.7",
+        "supports-preserve-symlinks-flag": "^1.0.0"
+      },
+      "bin": {
+        "resolve": "bin/resolve"
+      },
+      "engines": {
+        "node": ">= 0.4"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/ljharb"
+      }
+    },
+    "node_modules/reusify": {
+      "version": "1.1.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "iojs": ">=1.0.0",
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/robots-parser": {
+      "version": "3.0.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=10.0.0"
+      }
+    },
+    "node_modules/run-con": {
+      "version": "1.3.2",
+      "dev": true,
+      "license": "(BSD-2-Clause OR MIT OR Apache-2.0)",
+      "dependencies": {
+        "deep-extend": "^0.6.0",
+        "ini": "~4.1.0",
+        "minimist": "^1.2.8",
+        "strip-json-comments": "~3.1.1"
+      },
+      "bin": {
+        "run-con": "cli.js"
+      }
+    },
+    "node_modules/run-parallel": {
+      "version": "1.2.0",
+      "dev": true,
+      "funding": [
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/feross"
+        },
+        {
+          "type": "patreon",
+          "url": "https://www.patreon.com/feross"
+        },
+        {
+          "type": "consulting",
+          "url": "https://feross.org/support"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "queue-microtask": "^1.2.2"
+      }
+    },
+    "node_modules/sax": {
+      "version": "1.6.0",
+      "dev": true,
+      "license": "BlueOak-1.0.0",
+      "engines": {
+        "node": ">=11.0.0"
+      }
+    },
+    "node_modules/semver": {
+      "version": "7.8.0",
+      "dev": true,
+      "license": "ISC",
+      "bin": {
+        "semver": "bin/semver.js"
+      },
+      "engines": {
+        "node": ">=10"
+      }
+    },
+    "node_modules/shimmer": {
+      "version": "1.2.1",
+      "dev": true,
+      "license": "BSD-2-Clause"
+    },
+    "node_modules/sisteransi": {
+      "version": "1.0.5",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/slash": {
+      "version": "5.1.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=14.16"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/smart-buffer": {
+      "version": "4.2.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 6.0.0",
+        "npm": ">= 3.0.0"
+      }
+    },
+    "node_modules/smol-toml": {
+      "version": "1.6.1",
+      "dev": true,
+      "license": "BSD-3-Clause",
+      "engines": {
+        "node": ">= 18"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/cyyynthia"
+      }
+    },
+    "node_modules/socks": {
+      "version": "2.8.9",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "ip-address": "^10.1.1",
+        "smart-buffer": "^4.2.0"
+      },
+      "engines": {
+        "node": ">= 10.0.0",
+        "npm": ">= 3.0.0"
+      }
+    },
+    "node_modules/socks-proxy-agent": {
+      "version": "8.0.5",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "agent-base": "^7.1.2",
+        "debug": "^4.3.4",
+        "socks": "^2.8.3"
+      },
+      "engines": {
+        "node": ">= 14"
+      }
+    },
+    "node_modules/source-map": {
+      "version": "0.6.1",
+      "resolved": "https://registry.npmjs.org/source-map/-/source-map-0.6.1.tgz",
+      "integrity": "sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g==",
+      "dev": true,
+      "license": "BSD-3-Clause",
+      "optional": true,
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/source-map-js": {
+      "version": "1.2.1",
+      "dev": true,
+      "license": "BSD-3-Clause",
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/speedline-core": {
+      "version": "1.4.3",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/node": "*",
+        "image-ssim": "^0.2.0",
+        "jpeg-js": "^0.4.1"
+      },
+      "engines": {
+        "node": ">=8.0"
+      }
+    },
+    "node_modules/split": {
+      "version": "1.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "through": "2"
+      },
+      "engines": {
+        "node": "*"
+      }
+    },
+    "node_modules/streamx": {
+      "version": "2.25.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "events-universal": "^1.0.0",
+        "fast-fifo": "^1.3.2",
+        "text-decoder": "^1.1.0"
+      }
+    },
+    "node_modules/string-width": {
+      "version": "4.2.3",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "emoji-regex": "^8.0.0",
+        "is-fullwidth-code-point": "^3.0.0",
+        "strip-ansi": "^6.0.1"
+      },
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/strip-ansi": {
+      "version": "6.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "ansi-regex": "^5.0.1"
+      },
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/strip-json-comments": {
+      "version": "3.1.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=8"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/stubborn-fs": {
+      "version": "2.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "stubborn-utils": "^1.0.1"
+      }
+    },
+    "node_modules/stubborn-utils": {
+      "version": "1.0.2",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/stylehacks": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "browserslist": "^4.28.2",
+        "postcss-selector-parser": "^7.1.1"
+      },
+      "engines": {
+        "node": "^22.11.0 || ^24.11.0 || >=26.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.5.14"
+      }
+    },
+    "node_modules/stylehacks/node_modules/postcss-selector-parser": {
+      "version": "7.1.1",
+      "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-7.1.1.tgz",
+      "integrity": "sha512-orRsuYpJVw8LdAwqqLykBj9ecS5/cRHlI5+nvTo8LcCKmzDmqVORXtOIYEEQuL9D4BxtA1lm5isAqzQZCoQ6Eg==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "cssesc": "^3.0.0",
+        "util-deprecate": "^1.0.2"
+      },
+      "engines": {
+        "node": ">=4"
+      }
+    },
+    "node_modules/sugarss": {
+      "version": "5.0.1",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/postcss/"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "engines": {
+        "node": ">=18.0"
+      },
+      "peerDependencies": {
+        "postcss": "^8.3.3"
+      }
+    },
+    "node_modules/supports-preserve-symlinks-flag": {
+      "version": "1.0.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 0.4"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/ljharb"
+      }
+    },
+    "node_modules/surge": {
+      "version": "0.27.4",
+      "dev": true,
+      "license": "ISC",
+      "dependencies": {
+        "axios": "1.13.5",
+        "babar": "0.2.3",
+        "cli-table3": "0.6.5",
+        "colors": "1.4.0",
+        "human-readable-numbers": "0.9.5",
+        "ignore": "7.0.5",
+        "is-domain": "0.0.1",
+        "minimist": "1.2.8",
+        "moniker": "0.1.2",
+        "netrc": "0.1.4",
+        "progress": "2.0.3",
+        "prompts": "2.4.2",
+        "read": "1.0.5",
+        "surge-ignore": "0.3.0",
+        "surge-sdk": "0.10.1",
+        "surge-stream": "0.10.1",
+        "url-parse-as-address": "1.0.0",
+        "xbytes": "1.9.1"
+      },
+      "bin": {
+        "surge": "bin/surge"
+      }
+    },
+    "node_modules/surge-ignore": {
+      "version": "0.3.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/surge-sdk": {
+      "version": "0.10.1",
+      "dev": true,
+      "license": "ISC",
+      "dependencies": {
+        "axios": "1.13.5"
+      }
+    },
+    "node_modules/surge-stream": {
+      "version": "0.10.1",
+      "dev": true,
+      "license": "ISC",
+      "dependencies": {
+        "axios": "1.13.5",
+        "ignore": "7.0.5",
+        "split": "1.0.1",
+        "surge-ignore": "0.3.0",
+        "tar": "7.5.9"
+      }
+    },
+    "node_modules/svgo": {
+      "version": "4.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "commander": "^11.1.0",
+        "css-select": "^5.1.0",
+        "css-tree": "^3.0.1",
+        "css-what": "^6.1.0",
+        "csso": "^5.0.5",
+        "picocolors": "^1.1.1",
+        "sax": "^1.5.0"
+      },
+      "bin": {
+        "svgo": "bin/svgo.js"
+      },
+      "engines": {
+        "node": ">=16"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/svgo"
+      }
+    },
+    "node_modules/svgo/node_modules/commander": {
+      "version": "11.1.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=16"
+      }
+    },
+    "node_modules/svgo/node_modules/css-select": {
+      "version": "5.2.2",
+      "dev": true,
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "boolbase": "^1.0.0",
+        "css-what": "^6.1.0",
+        "domhandler": "^5.0.2",
+        "domutils": "^3.0.1",
+        "nth-check": "^2.0.1"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/fb55"
+      }
+    },
+    "node_modules/svgo/node_modules/css-tree": {
+      "version": "3.1.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "mdn-data": "2.12.2",
+        "source-map-js": "^1.0.1"
+      },
+      "engines": {
+        "node": "^10 || ^12.20.0 || ^14.13.0 || >=15.0.0"
+      }
+    },
+    "node_modules/svgo/node_modules/css-tree/node_modules/mdn-data": {
+      "version": "2.12.2",
+      "dev": true,
+      "license": "CC0-1.0"
+    },
+    "node_modules/svgo/node_modules/css-what": {
+      "version": "6.2.2",
+      "dev": true,
+      "license": "BSD-2-Clause",
+      "engines": {
+        "node": ">= 6"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/fb55"
+      }
+    },
+    "node_modules/tar": {
+      "version": "7.5.9",
+      "dev": true,
+      "license": "BlueOak-1.0.0",
+      "dependencies": {
+        "@isaacs/fs-minipass": "^4.0.0",
+        "chownr": "^3.0.0",
+        "minipass": "^7.1.2",
+        "minizlib": "^3.1.0",
+        "yallist": "^5.0.0"
+      },
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/tar-fs": {
+      "version": "3.1.2",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "pump": "^3.0.0",
+        "tar-stream": "^3.1.5"
+      },
+      "optionalDependencies": {
+        "bare-fs": "^4.0.1",
+        "bare-path": "^3.0.0"
+      }
+    },
+    "node_modules/tar-stream": {
+      "version": "3.2.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "b4a": "^1.6.4",
+        "bare-fs": "^4.5.5",
+        "fast-fifo": "^1.2.0",
+        "streamx": "^2.15.0"
+      }
+    },
+    "node_modules/teex": {
+      "version": "1.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "streamx": "^2.12.5"
+      }
+    },
+    "node_modules/text-decoder": {
+      "version": "1.2.7",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "b4a": "^1.6.4"
+      }
+    },
+    "node_modules/thenby": {
+      "version": "1.4.1",
+      "dev": true,
+      "license": "Apache-2.0"
+    },
+    "node_modules/third-party-web": {
+      "version": "0.29.2",
+      "resolved": "https://registry.npmjs.org/third-party-web/-/third-party-web-0.29.2.tgz",
+      "integrity": "sha512-fegtha91tq2DHphyoiBXVHjVi2YG9zFaRnboT9C28tO1en9Y3wJsfspuy40F+u5wl3hHVbw7cnd1b67kEGHb8g==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/through": {
+      "version": "2.3.8",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/tinyglobby": {
+      "version": "0.2.16",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "fdir": "^6.5.0",
+        "picomatch": "^4.0.4"
+      },
+      "engines": {
+        "node": ">=12.0.0"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/SuperchupuDev"
+      }
+    },
+    "node_modules/tldts-core": {
+      "version": "7.0.30",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/tldts-icann": {
+      "version": "7.0.30",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "tldts-core": "^7.0.30"
+      }
+    },
+    "node_modules/to-regex-range": {
+      "version": "5.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "is-number": "^7.0.0"
+      },
+      "engines": {
+        "node": ">=8.0"
+      }
+    },
+    "node_modules/tslib": {
+      "version": "2.8.1",
+      "dev": true,
+      "license": "0BSD"
+    },
+    "node_modules/type-fest": {
+      "version": "4.41.0",
+      "dev": true,
+      "license": "(MIT OR CC0-1.0)",
+      "engines": {
+        "node": ">=16"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/typed-query-selector": {
+      "version": "2.12.2",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/uc.micro": {
+      "version": "2.1.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/undici-types": {
+      "version": "7.19.2",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/universalify": {
+      "version": "2.0.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 10.0.0"
+      }
+    },
+    "node_modules/update-browserslist-db": {
+      "version": "1.2.3",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/browserslist"
+        },
+        {
+          "type": "tidelift",
+          "url": "https://tidelift.com/funding/github/npm/browserslist"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "escalade": "^3.2.0",
+        "picocolors": "^1.1.1"
+      },
+      "bin": {
+        "update-browserslist-db": "cli.js"
+      },
+      "peerDependencies": {
+        "browserslist": ">= 4.21.0"
+      }
+    },
+    "node_modules/url-parse-as-address": {
+      "version": "1.0.0",
+      "dev": true,
+      "license": "ISC"
+    },
+    "node_modules/util-deprecate": {
+      "version": "1.0.2",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/web-features": {
+      "version": "3.27.0",
+      "dev": true,
+      "license": "Apache-2.0"
+    },
+    "node_modules/webdriver-bidi-protocol": {
+      "version": "0.4.1",
+      "dev": true,
+      "license": "Apache-2.0"
+    },
+    "node_modules/when-exit": {
+      "version": "2.1.5",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/wrap-ansi": {
+      "version": "7.0.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "ansi-styles": "^4.0.0",
+        "string-width": "^4.1.0",
+        "strip-ansi": "^6.0.0"
+      },
+      "engines": {
+        "node": ">=10"
+      },
+      "funding": {
+        "url": "https://github.com/chalk/wrap-ansi?sponsor=1"
+      }
+    },
+    "node_modules/wrap-ansi/node_modules/string-width": {
+      "version": "4.2.3",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "emoji-regex": "^8.0.0",
+        "is-fullwidth-code-point": "^3.0.0",
+        "strip-ansi": "^6.0.1"
+      },
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/wrap-ansi/node_modules/string-width/node_modules/emoji-regex": {
+      "version": "8.0.0",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/wrap-ansi/node_modules/strip-ansi": {
+      "version": "6.0.1",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "ansi-regex": "^5.0.1"
+      },
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/wrap-ansi/node_modules/strip-ansi/node_modules/ansi-regex": {
+      "version": "5.0.1",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/wrappy": {
+      "version": "1.0.2",
+      "dev": true,
+      "license": "ISC"
+    },
+    "node_modules/ws": {
+      "version": "7.5.10",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=8.3.0"
+      },
+      "peerDependencies": {
+        "bufferutil": "^4.0.1",
+        "utf-8-validate": "^5.0.2"
+      },
+      "peerDependenciesMeta": {
+        "bufferutil": {
+          "optional": true
+        },
+        "utf-8-validate": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/xbytes": {
+      "version": "1.9.1",
+      "dev": true,
+      "license": "Apache-2.0",
+      "engines": {
+        "node": ">=1"
+      }
+    },
+    "node_modules/xdg-basedir": {
+      "version": "5.1.0",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=12"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/xtend": {
+      "version": "4.0.2",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=0.4"
+      }
+    },
+    "node_modules/y18n": {
+      "version": "5.0.8",
+      "dev": true,
+      "license": "ISC",
+      "engines": {
+        "node": ">=10"
+      }
+    },
+    "node_modules/yallist": {
+      "version": "5.0.0",
+      "dev": true,
+      "license": "BlueOak-1.0.0",
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/yaml": {
+      "version": "2.8.4",
+      "dev": true,
+      "license": "ISC",
+      "bin": {
+        "yaml": "bin.mjs"
+      },
+      "engines": {
+        "node": ">= 14.6"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/eemeli"
+      }
+    },
+    "node_modules/yargs": {
+      "version": "17.7.2",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "cliui": "^8.0.1",
+        "escalade": "^3.1.1",
+        "get-caller-file": "^2.0.5",
+        "require-directory": "^2.1.1",
+        "string-width": "^4.2.3",
+        "y18n": "^5.0.5",
+        "yargs-parser": "^21.1.1"
+      },
+      "engines": {
+        "node": ">=12"
+      }
+    },
+    "node_modules/yargs-parser": {
+      "version": "21.1.1",
+      "dev": true,
+      "license": "ISC",
+      "engines": {
+        "node": ">=12"
+      }
+    },
+    "node_modules/yauzl": {
+      "version": "2.10.0",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "buffer-crc32": "~0.2.3",
+        "fd-slicer": "~1.1.0"
+      }
+    },
+    "node_modules/zod": {
+      "version": "3.25.76",
+      "dev": true,
+      "license": "MIT",
+      "funding": {
+        "url": "https://github.com/sponsors/colinhacks"
+      }
+    }
+  }
+}
diff --git a/package.json b/package.json
index e7962c47e..d46b9500a 100644
--- a/package.json
+++ b/package.json
@@ -23,17 +23,17 @@
     "cssnano": "^8.0.1",
     "lighthouse": "^13.3.0",
     "markdownlint-cli": "^0.48.0",
-    "postcss": "^8.5.14",
+    "postcss": "^8.5.15",
     "postcss-cli": "^11.0.1",
     "postcss-delete-duplicate-css": "^1.0.0",
     "postcss-extend-rule": "^4.0.0",
     "postcss-import": "^16.1.1",
     "postcss-mixins": "^12.1.2",
     "postcss-nested": "^7.0.2",
-    "surge": "^0.27.3"
+    "surge": "^0.27.4"
   },
   "dependencies": {
-    "caniuse-lite": "^1.0.30001792"
+    "caniuse-lite": "^1.0.30001793"
   },
   "engines": {
     "bun": ">=1.3"
diff --git a/postcss.config.js b/postcss.config.js
index b2c9163de..95433892d 100644
--- a/postcss.config.js
+++ b/postcss.config.js
@@ -73,6 +73,12 @@ module.exports = {
       skipDuplicates: true
     }),
 
+    // NOTE: POSTCSS_ENABLE_MIXINS and POSTCSS_ENABLE_EXTEND are inherited naturally
+    // from the parent shell through standard OS process inheritance. Hugo does NOT
+    // filter child-process env vars — only HUGO_ENVIRONMENT fails to auto-export.
+    // These two toggles work without any explicit export in bin/dev, bin/hugo-build,
+    // or CI. They're only needed if you want to DISABLE a plugin (export either as 'false').
+
     // Mixins first so they can be expanded before nesting/extend
     process.env.POSTCSS_ENABLE_MIXINS === 'false' ? null : postcssMixins({
       mixinsDir: 'themes/beaver/assets/css/mixins'
diff --git a/test/fixtures/screenshots/linux/desktop/nav/services.png b/test/fixtures/screenshots/linux/desktop/nav/services.png
index 47c0f621c..3b77f2f57 100644
Binary files a/test/fixtures/screenshots/linux/desktop/nav/services.png and b/test/fixtures/screenshots/linux/desktop/nav/services.png differ
diff --git a/test/fixtures/screenshots/linux/desktop/nav/use_cases.png b/test/fixtures/screenshots/linux/desktop/nav/use_cases.png
index e5e951806..d69da8762 100644
Binary files a/test/fixtures/screenshots/linux/desktop/nav/use_cases.png and b/test/fixtures/screenshots/linux/desktop/nav/use_cases.png differ
diff --git a/test/fixtures/screenshots/linux/mobile/blog/index/_pagination.png b/test/fixtures/screenshots/linux/mobile/blog/index/_pagination.png
index a7c0bc27e..10a476ae5 100644
Binary files a/test/fixtures/screenshots/linux/mobile/blog/index/_pagination.png and b/test/fixtures/screenshots/linux/mobile/blog/index/_pagination.png differ
diff --git a/test/fixtures/screenshots/linux/mobile/nav/hamburger_menu.png b/test/fixtures/screenshots/linux/mobile/nav/hamburger_menu.png
index 0cb1a060d..c576f5b50 100644
Binary files a/test/fixtures/screenshots/linux/mobile/nav/hamburger_menu.png and b/test/fixtures/screenshots/linux/mobile/nav/hamburger_menu.png differ
diff --git a/test/fixtures/screenshots/linux/mobile/nav/hamburger_menu/services.png b/test/fixtures/screenshots/linux/mobile/nav/hamburger_menu/services.png
index a11741fb2..ab5d88c1b 100644
Binary files a/test/fixtures/screenshots/linux/mobile/nav/hamburger_menu/services.png and b/test/fixtures/screenshots/linux/mobile/nav/hamburger_menu/services.png differ
diff --git a/test/fixtures/screenshots/macos/desktop/nav/services.png b/test/fixtures/screenshots/macos/desktop/nav/services.png
index 23d1206fa..12f7301e1 100644
Binary files a/test/fixtures/screenshots/macos/desktop/nav/services.png and b/test/fixtures/screenshots/macos/desktop/nav/services.png differ
diff --git a/test/fixtures/screenshots/macos/desktop/nav/use_cases.png b/test/fixtures/screenshots/macos/desktop/nav/use_cases.png
index 19f65d6d6..4be54d20e 100644
Binary files a/test/fixtures/screenshots/macos/desktop/nav/use_cases.png and b/test/fixtures/screenshots/macos/desktop/nav/use_cases.png differ
diff --git a/test/fixtures/screenshots/macos/mobile/blog/index/_pagination.png b/test/fixtures/screenshots/macos/mobile/blog/index/_pagination.png
index 47a4e910e..19f133bd5 100644
Binary files a/test/fixtures/screenshots/macos/mobile/blog/index/_pagination.png and b/test/fixtures/screenshots/macos/mobile/blog/index/_pagination.png differ
diff --git a/test/fixtures/screenshots/macos/mobile/nav/hamburger_menu.png b/test/fixtures/screenshots/macos/mobile/nav/hamburger_menu.png
index 3170c8183..8ec55bf2e 100644
Binary files a/test/fixtures/screenshots/macos/mobile/nav/hamburger_menu.png and b/test/fixtures/screenshots/macos/mobile/nav/hamburger_menu.png differ
diff --git a/test/fixtures/screenshots/macos/mobile/nav/hamburger_menu/services.png b/test/fixtures/screenshots/macos/mobile/nav/hamburger_menu/services.png
index b050bdfed..35fc704b3 100644
Binary files a/test/fixtures/screenshots/macos/mobile/nav/hamburger_menu/services.png and b/test/fixtures/screenshots/macos/mobile/nav/hamburger_menu/services.png differ
diff --git a/test/integration/hugo_pipeline_test.rb b/test/integration/hugo_pipeline_test.rb
new file mode 100644
index 000000000..d99cf671f
--- /dev/null
+++ b/test/integration/hugo_pipeline_test.rb
@@ -0,0 +1,173 @@
+# frozen_string_literal: true
+
+require_relative "../test_helper"
+require "fileutils"
+
+# Integration tests for the Hugo asset pipeline production branching.
+#
+# These tests build the full site in both development and production
+# environments, then verify that Hugo template partials
+# (css-processor.html, css-inline.html, js-processor.html) produce
+# the correct outputs:
+#
+#   Dev:  fingerprint only, no integrity, no .min. in filenames
+#   Prod: fingerprint + minify, integrity attributes, .min. in CSS
+#         filenames, crossorigin=anonymous on script tags
+#
+# Builds run once per test class via class-level memoization (~7s each).
+# All tests skip if either build fails.
+
+HUGO_PROJECT_ROOT = File.expand_path("../..", __dir__)
+HUGO_DEV_DIR = "/tmp/hugo-test-dev"
+HUGO_PROD_DIR = "/tmp/hugo-test-prod"
+
+class HugoPipelineIntegrationTest < Minitest::Test
+  # -- One-time builds (class-level memoization) ---------------------------
+
+  def self.dev_ready?
+    @dev_ready ||= begin
+      FileUtils.rm_rf(HUGO_DEV_DIR)
+      system({ "HUGO_ENVIRONMENT" => "development", "BASE_URL" => "http://localhost:1313" },
+             "hugo build --noBuildLock --environment development --destination #{HUGO_DEV_DIR}",
+             chdir: HUGO_PROJECT_ROOT,
+             %i[out err] => "/dev/null")
+    end
+  end
+
+  def self.prod_ready?
+    @prod_ready ||= begin
+      FileUtils.rm_rf(HUGO_PROD_DIR)
+      system({ "HUGO_ENVIRONMENT" => "production", "BASE_URL" => "https://jetthoughts.com" },
+             "hugo build --noBuildLock --environment production --destination #{HUGO_PROD_DIR}",
+             chdir: HUGO_PROJECT_ROOT,
+             %i[out err] => "/dev/null")
+    end
+  end
+
+  def setup
+    skip "Dev Hugo build failed or unavailable" unless self.class.dev_ready?
+    skip "Prod Hugo build failed or unavailable" unless self.class.prod_ready?
+    skip "Dev output missing" unless Dir.exist?(HUGO_DEV_DIR)
+    skip "Prod output missing" unless Dir.exist?(HUGO_PROD_DIR)
+  end
+
+  # -- HTML output helpers -------------------------------------------------
+
+  def dev_html
+    @dev_html ||= File.read("#{HUGO_DEV_DIR}/index.html")
+  end
+
+  def prod_html
+    @prod_html ||= File.read("#{HUGO_PROD_DIR}/index.html")
+  end
+
+  def dev_css_files(pattern = "homepage.*.css")
+    Dir["#{HUGO_DEV_DIR}/css/#{pattern}"]
+  end
+
+  def prod_css_files(pattern = "homepage.*.css")
+    Dir["#{HUGO_PROD_DIR}/css/#{pattern}"]
+  end
+
+  # -- Tests: CSS integrity attributes ------------------------------------
+  # css-processor.html adds integrity= to <link> tags ONLY in production
+
+  def test_css_has_no_integrity_in_development
+    refute dev_html.include?("integrity"),
+      "Dev build should not have integrity attributes on any tags"
+  end
+
+  def test_css_has_integrity_in_production
+    assert prod_html.include?('integrity="sha256-'),
+      "Prod build should have sha256 integrity attributes on link/script tags"
+  end
+
+  def test_css_has_multiple_integrity_attributes_in_production
+    count = prod_html.scan(%r{integrity="sha256-}).length
+    assert_operator count, :>=, 2,
+      "Prod build should have at least 2 integrity attributes (preload + stylesheet)"
+  end
+
+  # -- Tests: CSS minification (via .min. in filename) --------------------
+  # css-processor.html runs | minify | fingerprint "sha256" in production,
+  # which produces homepage.min.<hash>.css vs homepage.<hash>.css in dev
+
+  def test_css_filenames_have_min_suffix_in_production
+    prod_css_files.each do |f|
+      basename = File.basename(f)
+      assert basename.include?(".min."),
+        "Prod CSS '#{basename}' should have .min. in filename (was minified)"
+    end
+  end
+
+  def test_css_filenames_have_no_min_in_development
+    dev_css_files.each do |f|
+      basename = File.basename(f)
+      refute basename.include?(".min."),
+        "Dev CSS '#{basename}' should NOT have .min. in filename (not minified)"
+    end
+  end
+
+  # -- Tests: CSS file size (minification evidence) -----------------------
+  # Production CSS should be noticeably smaller than dev CSS
+
+  def test_css_content_is_minified_in_production
+    dev_file = dev_css_files.first
+    prod_file = prod_css_files.first
+
+    skip "No dev CSS file found" unless dev_file
+    skip "No prod CSS file found" unless prod_file
+
+    dev_size = File.size(dev_file)
+    prod_size = File.size(prod_file)
+
+    assert_operator prod_size, :<, dev_size,
+      "Prod CSS (#{prod_size}B) should be smaller than dev CSS (#{dev_size}B) (was minified)"
+  end
+
+  # -- Tests: JS integrity + crossorigin ----------------------------------
+  # js-processor.html adds integrity + crossorigin=anonymous ONLY in production
+
+  def test_js_has_integrity_and_crossorigin_in_production
+    assert prod_html.include?('integrity="sha256-'),
+      "Prod should have integrity attributes on script tags"
+    assert prod_html.include?("crossorigin=anonymous"),
+      "Prod should have crossorigin=anonymous on script tags"
+  end
+
+  def test_js_no_integrity_or_crossorigin_in_development
+    refute dev_html.include?("integrity"),
+      "Dev tags should not have integrity attributes"
+    refute dev_html.include?("crossorigin"),
+      "Dev tags should not have crossorigin attributes"
+  end
+
+  # -- Tests: CSS loaded via <link> with integrity in prod ----------------
+  # css-processor.html wraps integrity in the <link> tag
+
+  def test_stylesheet_links_have_integrity_in_production
+    integrity_links = prod_html.scan(%r{<link[^>]*rel=stylesheet[^>]*integrity=[^>]*>})
+
+    assert_operator integrity_links.length, :>=, 1,
+      "Prod should have at least 1 link rel=stylesheet tag with integrity"
+  end
+
+  def test_preload_links_have_integrity_in_production
+    preload_links = prod_html.scan(%r{<link[^>]*rel=preload[^>]*as=style[^>]*integrity=[^>]*>})
+
+    assert_operator preload_links.length, :>=, 1,
+      "Prod should have at least 1 link rel=preload as=style with integrity"
+  end
+
+  # -- Tests: CSS not minified in dev ------------------------------------
+  # Also verify the opposite: dev CSS files should NOT have .min.
+
+  def test_multiple_css_bundles_exist_in_both_envs
+    dev_count = dev_css_files.length
+    prod_count = prod_css_files.length
+
+    assert_operator dev_count, :>=, 1, "Dev should have at least 1 CSS bundle"
+    assert_equal dev_count, prod_count,
+      "Dev and prod should have the same number of CSS bundles"
+  end
+end
diff --git a/test/system/desktop_site_test.rb b/test/system/desktop_site_test.rb
index 7238dcbcf..e994f0bd4 100644
--- a/test/system/desktop_site_test.rb
+++ b/test/system/desktop_site_test.rb
@@ -305,6 +305,48 @@ def test_about_page_sections
     verify_section_for("about_page", "footer", css: "footer")
   end
 
+  def test_course_nav_link_exists_on_homepage
+    # User can find the course from the homepage via the nav bar "Course" link.
+    # The link points to the namespaced course URL.
+    visit "/"
+    within_top_bar do
+      link = find("a", text: "Course", visible: true, wait: 5)
+      href = link[:href]
+      assert_match %r{/course/tech-for-non-technical-founders-2026/?\z}, href,
+        "Expected Course nav link to point to /course/tech-for-non-technical-founders-2026/, got: #{href}"
+    end
+  end
+
+  def test_course_landing_page_renders
+    # The course landing page renders with title + key sections.
+    visit "/course/tech-for-non-technical-founders-2026/"
+
+    within ".fl-heading" do
+      assert_text "From Idea to First Paying Customer"
+    end
+    assert_text "Why this course exists"
+    assert_text "Module index"
+  end
+
+  def test_visit_course_chapter_from_landing
+    # From the course landing, user can click into the first chapter (Founding Hypothesis).
+    visit "/course/tech-for-non-technical-founders-2026/"
+
+    within ".post-content" do
+      find("a", text: /Form Your Founding Hypothesis/, match: :first, visible: true).click
+    end
+
+    assert_current_path "/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/", wait: 10
+    assert_text "Form Your Founding Hypothesis"
+  end
+
+  def test_old_blog_url_redirects_to_course
+    # Old /blog/<slug>/ URLs alias-redirect to the new /course/<namespace>/<slug>/ URL via Hugo meta-refresh.
+    # Capybara follows the meta-refresh automatically.
+    visit "/blog/form-your-founding-hypothesis-90-minute-sprint/"
+    assert_current_path "/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/", wait: 5
+  end
+
   private
 
   def verify_section_for(page_name, section_id, css: nil, **options)
diff --git a/test/system/mobile_site_test.rb b/test/system/mobile_site_test.rb
index 18d716308..743fd3d38 100644
--- a/test/system/mobile_site_test.rb
+++ b/test/system/mobile_site_test.rb
@@ -30,7 +30,7 @@ def test_blog_index_pagination
 
     scroll_to find("#pagination")
 
-    assert_stable_screenshot "blog/index/_pagination", skip_area: [".blog-post"]
+    assert_stable_screenshot "blog/index/_pagination", skip_area: [".blog-post"], tolerance: 0.03
   end
 
   def test_visit_blog_post
diff --git a/test/unit/course_validators_test.rb b/test/unit/course_validators_test.rb
new file mode 100644
index 000000000..4363f0ecd
--- /dev/null
+++ b/test/unit/course_validators_test.rb
@@ -0,0 +1,491 @@
+# frozen_string_literal: true
+
+require_relative "../test_helper"
+require_relative "../../lib/course_validators"
+
+class CourseValidatorsTest < Minitest::Test
+  def setup
+    @tmpdir = Dir.mktmpdir("course_validators_test")
+    @orig_course_dir = CourseValidators::COURSE_DIR
+    @orig_yaml_path = CourseValidators::YAML_PATH
+
+    # Override constants for testing
+    silence_warnings do
+      CourseValidators.const_set(:COURSE_DIR, "#{@tmpdir}/content/blog")
+      CourseValidators.const_set(:ALL_BLOG_DIR, "#{@tmpdir}/content/blog")
+      CourseValidators.const_set(:YAML_PATH, "#{@tmpdir}/data/course_sequence.yaml")
+    end
+
+    FileUtils.mkdir_p("#{@tmpdir}/data")
+    FileUtils.mkdir_p("#{@tmpdir}/content/blog")
+  end
+
+  def teardown
+    FileUtils.rm_rf(@tmpdir)
+    silence_warnings do
+      CourseValidators.const_set(:COURSE_DIR, @orig_course_dir)
+      CourseValidators.const_set(:ALL_BLOG_DIR, @orig_course_dir)
+      CourseValidators.const_set(:YAML_PATH, @orig_yaml_path)
+    end
+  end
+
+  # ── Helper: write a course chapter ───────────────────────────────────────
+
+  def write_course_chapter(slug:, title:, og_title: nil, body: "", course_chapter: true, extra_frontmatter: {})
+    dir = "#{@tmpdir}/content/blog/#{slug}"
+    FileUtils.mkdir_p(dir)
+
+    fm = {
+      "title" => title,
+      "course_chapter" => course_chapter,
+      "slug" => slug
+    }.merge(extra_frontmatter)
+
+    if og_title
+      fm["metatags"] ||= {}
+      fm["metatags"]["og_title"] = og_title
+    end
+
+    yaml_fm = YAML.dump(fm)
+    content = "---\n#{yaml_fm}---\n#{body}"
+    File.write("#{dir}/index.md", content)
+  end
+
+  def write_yaml(entries)
+    data = { "sequence" => entries }
+    FileUtils.mkdir_p("#{@tmpdir}/data")
+    File.write("#{@tmpdir}/data/course_sequence.yaml", YAML.dump(data))
+  end
+
+  def write_blog_post(slug:)
+    dir = "#{@tmpdir}/content/blog/#{slug}"
+    FileUtils.mkdir_p(dir)
+    File.write("#{dir}/index.md", "---\ntitle: \"#{slug}\"\ndate: 2026-01-01\n---\n\nRegular post.\n")
+  end
+
+  def silence_warnings
+    old_verbose = $VERBOSE
+    $VERBOSE = nil
+    yield
+  ensure
+    $VERBOSE = old_verbose
+  end
+
+  # ── Validator 1: Chapter-number consistency ─────────────────────────────
+
+  def test_chapter_number_consistency_all_valid
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test Chapter", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "ch1", title: "1.1 · Test Chapter",
+      body: "See Chapter 1.1 for details. Also Chapter 1.1 has more info.\n")
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "chapter-number-consistency" }
+
+    assert result.passed, "Expected no chapter-number violations, got: #{result.violations.inspect}"
+  end
+
+  def test_chapter_number_consistency_invalid_ref
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test Chapter", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "ch1", title: "1.1 · Test Chapter",
+      body: "See Chapter 9.9 for details.\n")
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "chapter-number-consistency" }
+
+    refute result.passed, "Expected a violation for invalid Chapter 9.9"
+    assert result.violations.any? { |v| v.include?("9.9") }
+  end
+
+  def test_chapter_number_consistency_skips_non_course_posts
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test Chapter", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    # This post has course_chapter: false - should not be scanned
+    write_course_chapter(slug: "regular-post", title: "Regular Post",
+      course_chapter: false, body: "See Chapter 9.9 for details.\n")
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "chapter-number-consistency" }
+
+    assert result.passed, "Non-course posts should not trigger chapter-number violations"
+  end
+
+  def test_chapter_number_consistency_svg_check
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test Chapter", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+
+    dir = "#{@tmpdir}/content/blog/ch1"
+    FileUtils.mkdir_p(dir)
+    write_course_chapter(slug: "ch1", title: "1.1 · Test Chapter", body: "Some content.\n")
+    File.write("#{dir}/diagram.svg", <<~SVG)
+      <svg xmlns="http://www.w3.org/2000/svg">
+        <text>Chapter 9.9 reference in SVG</text>
+      </svg>
+    SVG
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "chapter-number-consistency" }
+
+    refute result.passed
+    assert result.violations.any? { |v| v.include?("9.9") && v.include?(".svg") }
+  end
+
+  def test_chapter_number_consistency_module_callout_wrong
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test Chapter", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "ch1", title: "1.1 · Test Chapter",
+      body: "> **Module 2 · Step 1 of 3** · Course.\n")
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "chapter-number-consistency" }
+
+    refute result.passed
+    assert result.violations.any? { |v| v.include?("Module 2") }
+  end
+
+  # ── Validator 2: Title-YAML match ────────────────────────────────────────
+
+  def test_title_yaml_match_valid
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Form Your Hypothesis", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "ch1", title: "1.1 · Form Your Hypothesis - Extended",
+      og_title: "1.1 · Form Your Hypothesis - Extended",
+      body: "> **Module 1 · Step 1 of 3** · Course.\n")
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "title-yaml-match" }
+
+    assert result.passed, "Expected no title-match violations, got: #{result.violations.inspect}"
+  end
+
+  def test_title_yaml_match_title_mismatch
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Form Your Hypothesis", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "ch1", title: "2.1 · Different Chapter",
+      body: "> **Module 1 · Step 1 of 3** · Course.\n")
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "title-yaml-match" }
+
+    refute result.passed
+    assert result.violations.any? { |v| v.include?("does not start with") }
+  end
+
+  def test_title_yaml_match_og_title_mismatch
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Form Your Hypothesis", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "ch1", title: "1.1 · Form Your Hypothesis",
+      og_title: "2.1 · Different OG Title",
+      body: "> **Module 1 · Step 1 of 3** · Course.\n")
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "title-yaml-match" }
+
+    refute result.passed
+    assert result.violations.any? { |v| v.include?("og_title") && v.include?("does not start with") }
+  end
+
+  def test_title_yaml_match_callout_step_mismatch
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Form Your Hypothesis", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "ch1", title: "1.1 · Form Your Hypothesis",
+      body: "> **Module 1 · Step 5 of 3** · Course.\n")
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "title-yaml-match" }
+
+    refute result.passed
+    assert result.violations.any? { |v| v.include?("Step 5") }
+  end
+
+  # ── Validator 3: Internal-link existence ─────────────────────────────────
+
+  def test_internal_links_all_valid
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_blog_post(slug: "existing-post")
+    write_course_chapter(slug: "ch1", title: "1.1 · Test",
+      body: "Check out this [post](/blog/existing-post/).\n")
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "internal-link-existence" }
+
+    assert result.passed, "Expected no link violations, got: #{result.violations.inspect}"
+  end
+
+  def test_internal_links_missing_target
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "ch1", title: "1.1 · Test",
+      body: "Check out this [post](/blog/nonexistent-post/).\n")
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "internal-link-existence" }
+
+    refute result.passed
+    assert result.violations.any? { |v| v.include?("nonexistent-post") }
+  end
+
+  def test_internal_links_skips_external_urls
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "ch1", title: "1.1 · Test",
+      body: "External [link](https://example.com) and [mailto](mailto:test@test.com).\n")
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "internal-link-existence" }
+
+    assert result.passed, "External links should not trigger violations"
+  end
+
+  def test_internal_links_multiple_course_chapters
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test", "module" => "Chapter 1.1", "goal" => "Test" },
+      { "slug" => "ch2", "title" => "1.2 · Test", "module" => "Chapter 1.2", "goal" => "Test" }
+    ])
+    write_blog_post(slug: "existing-post")
+    write_course_chapter(slug: "ch1", title: "1.1 · Test",
+      body: "See [ch1](/blog/existing-post/) and [ch2](/blog/nonexistent-slug/).\n")
+    write_course_chapter(slug: "ch2", title: "1.2 · Test",
+      body: "See [valid](/blog/existing-post/).\n")
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "internal-link-existence" }
+
+    refute result.passed
+    assert result.violations.any? { |v| v.include?("nonexistent-slug") }
+  end
+
+  # ── Validator 4: Table-width ─────────────────────────────────────────────
+
+  def test_table_width_small_tables_pass
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "ch1", title: "1.1 · Test", body: <<~BODY)
+      | Small | Table |
+      |-------|-------|
+      | a     | b     |
+    BODY
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "table-width" }
+
+    assert result.passed, "2-column tables should not trigger violations"
+  end
+
+  def test_table_width_five_columns_fails
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "ch1", title: "1.1 · Test", body: <<~BODY)
+      | Col1 | Col2 | Col3 | Col4 | Col5 |
+      |------|------|------|------|------|
+      | a    | b    | c    | d    | e    |
+    BODY
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "table-width" }
+
+    refute result.passed, "5-column table should trigger violation"
+    assert result.violations.any? { |v| v.include?("5 columns") }
+  end
+
+  def test_table_width_three_and_four_columns_pass
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "ch1", title: "1.1 · Test", body: <<~BODY)
+      | 3-col | table | here |
+      |-------|-------|------|
+      | x     | y     | z    |
+
+      | 4-col | wider | table | here |
+      |-------|-------|-------|------|
+      | a     | b     | c     | d    |
+    BODY
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "table-width" }
+
+    assert result.passed, "3 and 4 column tables should pass"
+  end
+
+  def test_table_width_non_course_posts_skipped
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "regular", title: "Regular",
+      course_chapter: false, body: <<~BODY)
+        | 5-col | table | should | be | skipped |
+        |-------|-------|--------|-----|---------|
+        | a     | b     | c      | d   | e       |
+    BODY
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "table-width" }
+
+    assert result.passed, "Non-course posts should be excluded from table-width check"
+  end
+
+  # ── Integration: all validators run together ────────────────────────────
+
+  def test_run_all_returns_seven_results
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_course_chapter(slug: "ch1", title: "1.1 · Test Chapter",
+      og_title: "1.1 · Test Chapter", body: "Content.\n")
+
+    results = CourseValidators.run_all
+
+    assert_equal 7, results.length
+    names = results.map(&:name)
+    assert_includes names, "chapter-number-consistency"
+    assert_includes names, "title-yaml-match"
+    assert_includes names, "internal-link-existence"
+    assert_includes names, "table-width"
+    assert_includes names, "disclaimer-consistency"
+    assert_includes names, "no-em-dash"
+    assert_includes names, "year-stamp-fabrication"
+  end
+
+  def test_run_all_with_no_course_chapters
+    write_yaml([])
+    results = CourseValidators.run_all
+
+    assert_equal 7, results.length
+    results.each do |r|
+      assert r.passed, "All validators should pass when no course chapters exist: #{r.name} failed"
+    end
+  end
+
+  # ── Edge cases ──────────────────────────────────────────────────────────
+
+  def test_missing_yaml_file_does_not_crash
+    # Remove the YAML file so it doesn't exist
+    FileUtils.rm_rf("#{@tmpdir}/data")
+    write_course_chapter(slug: "ch1", title: "1.1 · Test", body: "Content.\n")
+
+    results = CourseValidators.run_all
+
+    assert_equal 7, results.length
+    # Should not crash - just produce empty violations
+  end
+
+  def test_internal_links_handles_mixed_urls
+    write_yaml([
+      { "slug" => "ch1", "title" => "1.1 · Test", "module" => "Chapter 1.1", "goal" => "Test" }
+    ])
+    write_blog_post(slug: "real-post")
+    write_course_chapter(slug: "ch1", title: "1.1 · Test", body: <<~BODY)
+      Valid [link](/blog/real-post/), invalid [link](/blog/missing-post/),
+      and external [link](https://example.com).
+    BODY
+
+    results = CourseValidators.run_all
+    result = results.find { |r| r.name == "internal-link-existence" }
+
+    refute result.passed, "Should flag missing-post"
+    assert result.violations.any? { |v| v.include?("missing-post") }
+    refute result.violations.any? { |v| v.include?("real-post") }
+    refute result.violations.any? { |v| v.include?("example.com") }
+  end
+
+  # ── Validator 5: disclaimer consistency ──────────────────────────────────
+
+  def test_disclaimer_consistency_all_chapters_have_it_passes
+    write_course_chapter(slug: "ch-a", title: "A", body: "Founder anecdotes use anonymized names.\n")
+    write_course_chapter(slug: "ch-b", title: "B", body: "Also uses anonymized names here.\n")
+
+    result = CourseValidators.run_all.find { |r| r.name == "disclaimer-consistency" }
+    assert result.passed, "All-have should pass, got: #{result.violations.inspect}"
+  end
+
+  def test_disclaimer_consistency_none_have_it_passes
+    write_course_chapter(slug: "ch-a", title: "A", body: "Plain body.\n")
+    write_course_chapter(slug: "ch-b", title: "B", body: "Another plain body.\n")
+
+    result = CourseValidators.run_all.find { |r| r.name == "disclaimer-consistency" }
+    assert result.passed, "None-have should pass, got: #{result.violations.inspect}"
+  end
+
+  def test_disclaimer_consistency_some_have_it_fails
+    write_course_chapter(slug: "ch-a", title: "A", body: "Uses anonymized names here.\n")
+    write_course_chapter(slug: "ch-b", title: "B", body: "Plain body, no disclaimer.\n")
+
+    result = CourseValidators.run_all.find { |r| r.name == "disclaimer-consistency" }
+    refute result.passed, "Some-have should fail (inconsistent)"
+    assert result.violations.any? { |v| v.include?("ch-a") }
+  end
+
+  # ── Validator 6: no em-dash in content ───────────────────────────────────
+
+  def test_em_dash_flagged_in_body
+    write_course_chapter(slug: "ch-a", title: "A", body: "A sentence — with an em-dash.\n")
+
+    result = CourseValidators.run_all.find { |r| r.name == "no-em-dash" }
+    refute result.passed, "Em-dash in body should fail"
+    assert result.violations.any? { |v| v.include?("ch-a") }
+  end
+
+  def test_em_dash_ignored_inside_code_fence
+    body = "Use a hyphen - like this.\n\n```\nlet x = a — b\n```\n"
+    write_course_chapter(slug: "ch-a", title: "A", body: body)
+
+    result = CourseValidators.run_all.find { |r| r.name == "no-em-dash" }
+    assert result.passed, "Em-dash inside a code fence should be ignored, got: #{result.violations.inspect}"
+  end
+
+  # ── Validator 7: year-stamp client-cohort fabrication ────────────────────
+
+  def test_year_stamp_cohort_phrase_flagged
+    write_course_chapter(slug: "ch-a", title: "A", body: "Most founders we joined in 2026 skipped this.\n")
+
+    result = CourseValidators.run_all.find { |r| r.name == "year-stamp-fabrication" }
+    refute result.passed, "'founders we joined in 2026' should fail"
+    assert result.violations.any? { |v| v.include?("ch-a") }
+  end
+
+  def test_year_stamp_a_year_example_flagged
+    write_course_chapter(slug: "ch-a", title: "A", body: "A 2026 example from a founder.\n")
+
+    result = CourseValidators.run_all.find { |r| r.name == "year-stamp-fabrication" }
+    refute result.passed, "'A 2026 example' should fail"
+  end
+
+  def test_year_stamp_legitimate_date_not_flagged
+    write_course_chapter(slug: "ch-a", title: "A", body: "Jake Knapp published Click in April 2025 after twenty years.\n")
+
+    result = CourseValidators.run_all.find { |r| r.name == "year-stamp-fabrication" }
+    assert result.passed, "Legitimate publication date should NOT be flagged, got: #{result.violations.inspect}"
+  end
+
+  def test_year_stamp_month_year_cohort_flagged
+    write_course_chapter(slug: "ch-a", title: "A", body: "A founder we worked with in February 2026 ran five interviews.\n")
+
+    result = CourseValidators.run_all.find { |r| r.name == "year-stamp-fabrication" }
+    refute result.passed, "'A founder we worked with in February 2026' should fail"
+    assert result.violations.any? { |v| v.include?("ch-a") }
+  end
+
+  def test_year_stamp_rescue_we_joined_month_year_flagged
+    write_course_chapter(slug: "ch-a", title: "A", body: "A B2B SaaS rescue we joined in April 2026 had cleared four paid pilots.\n")
+
+    result = CourseValidators.run_all.find { |r| r.name == "year-stamp-fabrication" }
+    refute result.passed, "'rescue we joined in April 2026' should fail"
+  end
+end
diff --git a/test/unit/hugo_environment_test.rb b/test/unit/hugo_environment_test.rb
new file mode 100644
index 000000000..e455ce903
--- /dev/null
+++ b/test/unit/hugo_environment_test.rb
@@ -0,0 +1,250 @@
+# frozen_string_literal: true
+
+require_relative "../test_helper"
+require "open3"
+require "tempfile"
+
+class HugoEnvironmentTest < Minitest::Test
+  # -- Helpers ---------------------------------------------------------------
+
+  PROJECT_ROOT = File.expand_path("../..", __dir__)
+
+  # Evaluate the export lines from a build script in a clean subshell and
+  # return the resulting HUGO_ENVIRONMENT value. Tests runtime execution,
+  # not just file content — catches syntax errors, wrong variable names,
+  # and default-value logic.
+  #
+  # Uses a tempfile instead of string interpolation to avoid bash variable
+  # expansion issues ($ENVIRONMENT, ${ENVIRONMENT:-} in the export lines get
+  # expanded by outer bash -c double quotes before eval sees them).
+  def eval_export_from_script(script_rel, env_overrides = {})
+    script = File.join(PROJECT_ROOT, script_rel)
+    exports = File.readlines(script).grep(/^(ENVIRONMENT=|export HUGO_ENVIRONMENT)/).join
+
+    Tempfile.create(["hugo_env_test", ".sh"]) do |f|
+      # Unset ENVIRONMENT first for clean slate, then apply overrides
+      f.puts "unset ENVIRONMENT"
+      env_overrides.each { |k, v| f.puts "#{k}=#{v}" }
+      f.puts exports
+      f.puts 'echo "$HUGO_ENVIRONMENT"'
+      f.flush
+
+      stdout, stderr, status = Open3.capture3("bash", f.path)
+
+      assert status.success?,
+        "eval failed for #{script_rel}: #{stderr.strip}"
+      stdout.strip
+    end
+  end
+
+  # Run postcss.config.js in a clean Node process with specific env vars and
+  # check whether autoprefixer is present or absent in the resolved plugins.
+  # Returns true if autoprefixer is present, false if absent.
+  def autoprefixer_present?(env_vars)
+    # Build env string for `env` command
+    env_args = env_vars.map { |k, v| "#{k}=#{v}" }
+    env_args_str = env_args.map { |e| %("#{e}") }.join(" ")
+
+    _stdout, _stderr, status = Open3.capture3(
+      "bash", "-c",
+      <<~SH
+        cd #{PROJECT_ROOT} && \
+        env #{env_args_str} node -e "
+          const config = require('./postcss.config.js');
+          const autoprefixer = require('autoprefixer');
+          process.exit(config.plugins.includes(autoprefixer) ? 0 : 1);
+        "
+      SH
+    )
+    status.success?
+  end
+
+  # Evaluate a non-exported variable from a build script in a clean subprocess.
+  # Greps the `:-` default-assignment line for the variable, writes it to a
+  # tempfile with env overrides, sources via bash, and echoes the value.
+  # Same isolation strategy as eval_export_from_script but for vars like
+  # OUTPUT_DIR, BASE_URL, BUILD_DRAFTS that are never exported.
+  def eval_var_from_script(script_rel, var_name, env_overrides = {})
+    script = File.join(PROJECT_ROOT, script_rel)
+    line = File.readlines(script).grep(/^#{var_name}=/).first
+    raise "#{var_name} not found in #{script_rel}" unless line
+
+    Tempfile.create(["hugo_var_test", ".sh"]) do |f|
+      f.puts "unset #{var_name}"
+      env_overrides.each { |k, v| f.puts "#{k}=#{v}" }
+      f.puts line
+      f.puts "echo \"\$#{var_name}\""
+      f.flush
+
+      stdout, stderr, status = Open3.capture3("bash", f.path)
+      assert status.success?,
+        "var eval failed for #{script_rel}##{var_name}: #{stderr.strip}"
+      stdout.strip
+    end
+  end
+
+  # Source the HUGO_ARGS construction lines from bin/hugo-build with given
+  # env overrides and report whether a specific CLI flag (e.g. --baseURL,
+  # --buildDrafts) is present in the built array.
+  #
+  # This tests the conditional-flag logic:
+  #   [ -n "$BASE_URL" ] && HUGO_ARGS+=(--baseURL "$BASE_URL")
+  # These conditionals are the mistake surface: if the variable check syntax
+  # were wrong, the flag could be silently omitted or always included.
+  def hugo_args_includes_flag?(flag, env_overrides = {})
+    script = File.join(PROJECT_ROOT, "bin/hugo-build")
+    lines = File.readlines(script).grep(/^(OUTPUT_DIR=|ENVIRONMENT=|export HUGO_ENVIRONMENT|BASE_URL=|BUILD_DRAFTS=|HUGO_ARGS=\(|\[ -n "\$|\[ -z)/)
+
+    Tempfile.create(["hugo_args_test", ".sh"]) do |f|
+      f.puts "unset ENVIRONMENT OUTPUT_DIR BASE_URL BUILD_DRAFTS"
+      f.puts "export HUGO_ENVIRONMENT=test"
+      env_overrides.each { |k, v| f.puts "#{k}=#{v}" }
+      lines.each { |l| f.puts l }
+      # Print each element of HUGO_ARGS on its own line for grep-friendly output
+      f.puts 'printf "%s\n" "${HUGO_ARGS[@]}"'
+      f.flush
+
+      _stdout, stderr, status = Open3.capture3("bash", f.path)
+      assert status.success?,
+        "hugo_args eval failed: #{stderr.strip}"
+      _stdout.include?(flag)
+    end
+  end
+
+  # -- Tests: bin/dev --------------------------------------------------------
+  # These tests evaluate the actual export lines from the scripts in a
+  # clean subshell. They catch real regressions: syntax errors, renamed
+  # variables, broken default-value logic — not just string presence.
+
+  def test_bin_dev_exports_development
+    result = eval_export_from_script("bin/dev")
+    assert_equal "development", result,
+      "bin/dev should export HUGO_ENVIRONMENT=development"
+  end
+
+  def test_bin_hugo_build_exports_from_environment_variable
+    result = eval_export_from_script("bin/hugo-build", "ENVIRONMENT" => "production")
+    assert_equal "production", result,
+      "bin/hugo-build should export HUGO_ENVIRONMENT from ENVIRONMENT var"
+  end
+
+  def test_bin_hugo_build_defaults_to_development
+    result = eval_export_from_script("bin/hugo-build")
+    assert_equal "development", result,
+      "bin/hugo-build should default HUGO_ENVIRONMENT to development"
+  end
+
+  def test_bin_hugo_build_defaults_on_empty_string
+    result = eval_export_from_script("bin/hugo-build", "ENVIRONMENT" => "")
+    assert_equal "development", result,
+      "bin/hugo-build should default HUGO_ENVIRONMENT when ENVIRONMENT is empty string"
+  end
+
+  # -- Tests: bin/hugo-build OUTPUT_DIR -------------------------------------
+
+  def test_output_dir_defaults_to_public_dev
+    result = eval_var_from_script("bin/hugo-build", "OUTPUT_DIR")
+    assert_equal "_dest/public-dev", result,
+      "OUTPUT_DIR should default to _dest/public-dev"
+  end
+
+  def test_output_dir_respects_custom_value
+    result = eval_var_from_script("bin/hugo-build", "OUTPUT_DIR",
+      "OUTPUT_DIR" => "_dest/custom")
+    assert_equal "_dest/custom", result,
+      "OUTPUT_DIR should pass through custom value"
+  end
+
+  # -- Tests: bin/hugo-build BASE_URL ---------------------------------------
+
+  def test_base_url_defaults_to_empty
+    result = eval_var_from_script("bin/hugo-build", "BASE_URL")
+    assert_equal "", result,
+      "BASE_URL should default to empty string"
+  end
+
+  def test_base_url_respects_custom_value
+    result = eval_var_from_script("bin/hugo-build", "BASE_URL",
+      "BASE_URL" => "https://example.com")
+    assert_equal "https://example.com", result,
+      "BASE_URL should pass through custom value"
+  end
+
+  def test_base_url_omits_flag_when_unset
+    refute hugo_args_includes_flag?("--baseURL"),
+      "--baseURL flag should be absent when BASE_URL is unset"
+  end
+
+  def test_base_url_includes_flag_when_set
+    assert hugo_args_includes_flag?("--baseURL",
+      "BASE_URL" => "https://example.com"),
+      "--baseURL flag should be present when BASE_URL is set"
+  end
+
+  # -- Tests: bin/hugo-build BUILD_DRAFTS -----------------------------------
+
+  def test_build_drafts_defaults_to_empty
+    result = eval_var_from_script("bin/hugo-build", "BUILD_DRAFTS")
+    assert_equal "", result,
+      "BUILD_DRAFTS should default to empty string"
+  end
+
+  def test_build_drafts_respects_custom_value
+    result = eval_var_from_script("bin/hugo-build", "BUILD_DRAFTS",
+      "BUILD_DRAFTS" => "true")
+    assert_equal "true", result,
+      "BUILD_DRAFTS should pass through custom value"
+  end
+
+  def test_build_drafts_omits_flag_when_unset
+    refute hugo_args_includes_flag?("--buildDrafts"),
+      "--buildDrafts flag should be absent when BUILD_DRAFTS is unset"
+  end
+
+  def test_build_drafts_includes_flag_when_set
+    assert hugo_args_includes_flag?("--buildDrafts",
+      "BUILD_DRAFTS" => "true"),
+      "--buildDrafts flag should be present when BUILD_DRAFTS is set"
+  end
+
+  # -- Tests: postcss.config.js env consumption ------------------------------
+  # These tests shell out to Node to load postcss.config.js with different
+  # HUGO_ENVIRONMENT values and check which plugins resolve. This is the
+  # actual integration point that broke (bun + PostCSS + missing env var).
+  # The autoprefixer plugin is the oracle: it's present in production but
+  # filtered out in development mode via `isDevelopment ? null : require(...)`.
+
+  def test_postcss_resolves_correctly_with_node_available
+    skip "node not available" unless system("which node > /dev/null 2>&1")
+  end
+
+  def test_postcss_skips_autoprefixer_in_development
+    skip "node not available" unless system("which node > /dev/null 2>&1")
+    refute autoprefixer_present?("HUGO_ENVIRONMENT" => "development"),
+      "autoprefixer should be absent in development mode"
+  end
+
+  def test_postcss_includes_autoprefixer_in_production
+    skip "node not available" unless system("which node > /dev/null 2>&1")
+    assert autoprefixer_present?("HUGO_ENVIRONMENT" => "production"),
+      "autoprefixer should be present in production mode"
+  end
+
+  def test_postcss_defaults_to_production_when_unset
+    skip "node not available" unless system("which node > /dev/null 2>&1")
+
+    _stdout, _stderr, status = Open3.capture3(
+      "bash", "-c",
+      <<~SH
+        cd #{PROJECT_ROOT} && \
+        env -u HUGO_ENVIRONMENT node -e "
+          const config = require('./postcss.config.js');
+          const autoprefixer = require('autoprefixer');
+          process.exit(config.plugins.includes(autoprefixer) ? 0 : 1);
+        "
+      SH
+    )
+    assert status.success?,
+      "autoprefixer should be present when HUGO_ENVIRONMENT is unset (production fallback)"
+  end
+end
diff --git a/themes/beaver/assets/css/single-post.css b/themes/beaver/assets/css/single-post.css
index 6bf908dd6..1f3fc7176 100644
--- a/themes/beaver/assets/css/single-post.css
+++ b/themes/beaver/assets/css/single-post.css
@@ -129,3 +129,105 @@
 }
 
 .comment-link {text-decoration: none!important; margin-top: 2rem}
+
+/* Course prev/next chapter strip - inserted at the bottom of every
+   chapter in the Tech for Non-Technical Founders 2026 course via the
+   blog/course-prev-next partial. Three-card flex layout with the
+   center card linking back to the course landing. */
+.course-prev-next {
+  margin: 3rem 0 1.5rem;
+  max-width: 43rem;
+}
+.course-prev-next__inner {
+  display: grid;
+  grid-template-columns: 1fr 1fr 1fr;
+  gap: 0.75rem;
+}
+.course-prev-next__link {
+  display: flex;
+  flex-direction: column;
+  gap: 0.25rem;
+  padding: 1rem 1.25rem;
+  background: #f8f9fb;
+  border: 1px solid #e2e5eb;
+  border-radius: 8px;
+  text-decoration: none;
+  color: #1a1a1a;
+  transition: border-color 0.15s, background 0.15s;
+  min-height: 5rem;
+}
+.course-prev-next__link:hover {
+  border-color: #cc342d;
+  background: #fff5f5;
+  text-decoration: none;
+}
+.course-prev-next__link--placeholder {
+  background: transparent;
+  border-color: transparent;
+  cursor: default;
+}
+.course-prev-next__link--placeholder:hover {
+  background: transparent;
+  border-color: transparent;
+}
+.course-prev-next__link--prev { text-align: left; }
+.course-prev-next__link--home { text-align: center; align-items: center; }
+.course-prev-next__link--next { text-align: right; align-items: flex-end; }
+.course-prev-next__direction {
+  font-size: 0.8125rem;
+  font-weight: 600;
+  color: #cc342d;
+  text-transform: uppercase;
+  letter-spacing: 0.04em;
+}
+.course-prev-next__module {
+  font-size: 0.75rem;
+  color: rgba(33, 37, 41, 0.65);
+  font-weight: 500;
+}
+.course-prev-next__title {
+  font-size: 0.95rem;
+  font-weight: 600;
+  line-height: 1.3;
+  color: #1a1a1a;
+}
+
+@media (max-width: 640px) {
+  .course-prev-next__inner { grid-template-columns: 1fr; }
+  .course-prev-next__link { min-height: auto; }
+  .course-prev-next__link--prev,
+  .course-prev-next__link--home,
+  .course-prev-next__link--next { text-align: left; align-items: flex-start; }
+}
+
+/* Mermaid diagrams in blog posts: keep them readable on mobile.
+   Hugo's render-codeblock-mermaid hook outputs <div class="mermaid">…</div>;
+   Mermaid.js then injects an inline SVG that defaults to its natural pixel
+   width. On phones (≤640px) wide diagrams (sequence, flowchart LR) overflow
+   the column. Wrap in a horizontal scroll container and hint a min-width so
+   labels stay legible without forcing pinch-zoom. */
+.mermaid {
+  overflow-x: auto;
+  -webkit-overflow-scrolling: touch;
+  margin: 1.5rem 0;
+}
+.mermaid svg {
+  /* Keep natural width so labels stay legible; let .mermaid parent scroll
+     horizontally on narrow viewports rather than squashing text. */
+  height: auto;
+  display: block;
+  margin: 0 auto;
+}
+
+/* GFM task lists: Goldmark emits <li><input type=checkbox>...</li> without
+   a class. Hide the default bullet on items that contain a checkbox so the
+   checkbox itself acts as the list marker (matches GitHub rendering). */
+.post-content li:has(> input[type="checkbox"]),
+.single-content li:has(> input[type="checkbox"]) {
+  list-style: none;
+  margin-left: -1.25rem;
+}
+.post-content li > input[type="checkbox"],
+.single-content li > input[type="checkbox"] {
+  margin-right: 0.5rem;
+}
diff --git a/themes/beaver/assets/css/style.css b/themes/beaver/assets/css/style.css
index c299d5826..b44b66a74 100644
--- a/themes/beaver/assets/css/style.css
+++ b/themes/beaver/assets/css/style.css
@@ -203,13 +203,22 @@ input[type=submit]:disabled {
   margin: 48px 0 16px !important;
 }
 
-/* h3: visually distinct from body and from h2 */
+/* h3: visually distinct from body and from h2.
+   Top border creates section dividers between modules/content blocks.
+   First h3 on a page skips the border (no orphaned divider at top). */
 .blog h3:not(.post-title) {
   font-size: 22px;
   line-height: 30px;
   font-weight: 600;
   letter-spacing: -0.25px;
-  margin: 36px 0 12px !important;
+  margin: 52px 0 16px !important;
+  border-top: 1px solid #e5e7eb;
+  padding-top: 24px;
+}
+.blog h3:not(.post-title):first-of-type {
+  border-top: none;
+  padding-top: 0;
+  margin-top: 36px !important;
 }
 
 /* Inline code: dark text on neutral grey, not pink */
@@ -382,10 +391,6 @@ input[type=submit]:disabled {
   margin-top: 56px !important;
   margin-bottom: 20px !important;
 }
-.blog h3:not(.post-title) {
-  margin-top: 44px !important;
-  margin-bottom: 16px !important;
-}
 
 /* Mobile heading scale — preserve hierarchy when H1 drops to 32px on phones */
 @media (max-width: 768px) {
@@ -400,6 +405,11 @@ input[type=submit]:disabled {
     line-height: 28px;
     margin-top: 32px !important;
     margin-bottom: 12px !important;
+    border-top: none;
+    padding-top: 0;
+  }
+  .blog h3:not(.post-title):first-of-type {
+    margin-top: 20px !important;
   }
   .blog ul, .blog ol, .blog blockquote, .blog pre {
     font-size: 17px;
@@ -501,6 +511,7 @@ input[type=submit]:disabled {
   padding: 24px 28px;
   margin: 32px 0;
   border-radius: 10px;
+  background: #282a36;
 }
 .blog pre code {
   font-size: 15.5px;
@@ -539,6 +550,69 @@ input[type=submit]:disabled {
   color: #ffffff;
 }
 
+/* Gate callout — for "Kill Bad Ideas Fast" rule and other must-not-miss
+   sections. Amber/orange treatment distinct from the red insight blockquote. */
+.blog .gate-callout {
+  background: #fffbeb;
+  border-left: 6px solid #f59e0b;
+  padding: 24px 32px;
+  margin: 48px 0;
+  border-radius: 0 8px 8px 0;
+}
+.blog .gate-callout h2,
+.blog .gate-callout h3 {
+  color: #92400e;
+}
+.blog .gate-callout table {
+  margin: 20px 0;
+}
+.blog .gate-callout p {
+  color: #1a1a2e;
+}
+.blog .gate-callout p:last-child {
+  margin-bottom: 0;
+}
+
+/* Details/summary — collapsible tool-stack accordion.
+   Summary looks like a clickable heading, details body has standard spacing. */
+.blog details {
+  margin: 24px 0;
+  border: 1px solid #e5e7eb;
+  border-radius: 8px;
+  overflow: hidden;
+}
+.blog details > summary {
+  cursor: pointer;
+  padding: 14px 20px;
+  font-weight: 600;
+  font-size: 18px;
+  background: #f8f8fa;
+  list-style: none;
+  user-select: none;
+}
+.blog details > summary::-webkit-details-marker {
+  display: none;
+}
+.blog details > summary::before {
+  content: '▸ ';
+  display: inline-block;
+  transition: transform 0.15s ease;
+  margin-right: 4px;
+  color: #6b7280;
+}
+.blog details[open] > summary::before {
+  transform: rotate(90deg);
+}
+.blog details > summary:hover {
+  background: #f3f4f6;
+}
+.blog details > table {
+  width: calc(100% - 40px);
+  margin: 0 20px 20px 20px;
+}
+
+/* Mobile: consolidated tail-end mobile rules — CTA link stacking,
+   nested list indent reduction, and word-break for deep nesting. */
 @media (max-width: 768px) {
   .blog p a.cta-link,
   .blog li a.cta-link,
@@ -548,5 +622,15 @@ input[type=submit]:disabled {
     padding: 16px 24px;
     font-size: 17px;
   }
+  .blog ul ul,
+  .blog ol ol,
+  .blog ul ol,
+  .blog ol ul {
+    padding-left: 16px;
+  }
+  .blog li {
+    overflow-wrap: break-word;
+    word-break: break-word;
+  }
 }
 
diff --git a/themes/beaver/layouts/baseof.html b/themes/beaver/layouts/baseof.html
index 74ed13788..d2ede01b9 100644
--- a/themes/beaver/layouts/baseof.html
+++ b/themes/beaver/layouts/baseof.html
@@ -90,10 +90,16 @@
     {{ partialCached "page/site-scripts" . "site-scripts" }}
     {{ if .Store.Get "features.mermaid" }}
       <script
-        src="https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.min.js"
-        integrity="sha384-o+g/BxPwhi0C3RK7oQBxQuNimeafQ3GE/ST4iT2BxVI4Wzt60SH4pq9iXVYujjaS"
+        src="https://cdn.jsdelivr.net/npm/mermaid@11.15.0/dist/mermaid.min.js"
+        integrity="sha384-yQ4mmBBT+vhTAwjFH0toJXNYJ6O4usWnt6EPIdWwrRvx2V/n5lXuDZQwQFeSFydF"
         crossorigin="anonymous"></script>
       <script>
+        // useMaxWidth: true is Mermaid's default. SVGs scale to fit the
+        // content column on desktop (no big empty space when diagrams
+        // are tall) and shrink on mobile. For diagrams with too many
+        // nodes to fit legibly on mobile, the fix is to simplify the
+        // Mermaid source (fewer nodes, shorter labels, or split into
+        // sub-diagrams), not CSS gymnastics.
         mermaid.initialize({ startOnLoad: true });
       </script>
     {{ end }}
diff --git a/themes/beaver/layouts/blog/list.html b/themes/beaver/layouts/blog/list.html
index 8f1ca231d..d8f8712b7 100644
--- a/themes/beaver/layouts/blog/list.html
+++ b/themes/beaver/layouts/blog/list.html
@@ -73,7 +73,7 @@
                   Rails, AI, and the questions burned founders ask before signing again.
                 </p>
 
-                {{ range (.Paginate .Pages.ByDate.Reverse).Pages }}
+                {{ range (.Paginate (where .Pages "Params.course_chapter" "!=" true).ByDate.Reverse).Pages }}
                   <a class="link" href="{{ .RelPermalink }}">
                     <div class="blog-post">
                       <div class="post-image">
diff --git a/themes/beaver/layouts/course/single.html b/themes/beaver/layouts/course/single.html
new file mode 100644
index 000000000..12e85d769
--- /dev/null
+++ b/themes/beaver/layouts/course/single.html
@@ -0,0 +1,134 @@
+{{ define "header" }}
+
+  {{- $cssFiles := slice
+    (resources.Get "css/dynamic-icons.css" | resources.ExecuteAsTemplate "css/dynamic586.css" .)
+    (resources.Get "css/586.css")
+    (resources.Get "css/style.css")
+    (resources.Get "css/vendors/base-4.min.css")
+    (resources.Get "css/3114-layout.css")
+    (resources.Get "css/bf72bba397177a0376baed325bffdc75-layout-bundle.css")
+    (resources.Get "css/skin-65eda28877e04.css")
+    (resources.Get "css/single-post.css")
+    (resources.Get "css/footer.css")
+  }}
+
+  {{ partial "assets/css-processor.html" (dict
+    "resources" $cssFiles
+    "bundleName" "course-single"
+    "context" .
+    "media" "all"
+    )
+  }}
+
+  <meta property="og:type" content="article" />
+  <meta
+    content="{{ .Lastmod | time.Format "2006-01-02T15:04:05Z07:00" }}"
+    property="article:modified_time" />
+
+  {{/* Course-specific JSON-LD structured data */}}
+  <script type="application/ld+json">
+  {
+    "@context": "https://schema.org",
+    "@type": "Article",
+    "headline": {{ .Title | jsonify }},
+    "description": {{ .Params.description | default .Summary | jsonify }},
+    "author": {
+      "@type": "Organization",
+      "name": "JetThoughts"
+    },
+    "dateModified": "{{ .Lastmod.Format "2006-01-02" }}",
+    "publisher": {
+      "@type": "Organization",
+      "name": "JetThoughts"
+    }
+  }
+  </script>
+{{ end }}
+
+{{ define "main" }}
+
+  <div id="fl-main-content" class="blog" role="main">
+    <div class="fl-row-content fl-row-fixed-width">
+      <article
+        class="single-content"
+        style="max-width: 720px; margin:0 auto; padding-left:18px;padding-right:18px">
+        <header>
+          <h1 class="fl-heading">{{ .Title }}</h1>
+
+          {{/* Author byline + date */}}
+          <div class="post-meta-byline">
+            {{ with .Params.author }}
+              By {{ if or (eq . "JetThoughts") (eq . "JetThoughts Team") }}JetThoughts Team{{ else }}{{ . }}{{ end }}
+            {{ end }}
+            {{ if .Date }}
+              {{ with .Params.author }} - {{ end }}{{ dateFormat "January 2, 2006" .Date }}
+            {{ end }}
+            {{ with .ReadingTime }}
+              - {{ . }} min read
+            {{ end }}
+          </div>
+
+          {{/* Cover image */}}
+          {{ with .Resources.GetMatch "cover.*" }}
+            <figure class="post-cover-figure" style="margin: 0 0 1.25rem; max-width: 43rem;">
+            {{ if site.Params.cdn.enabled }}
+              {{ $src640  := partial "cdn/url" (dict "page" $ "resource" . "params" "w=640&output=webp&q=85") }}
+              {{ $src960  := partial "cdn/url" (dict "page" $ "resource" . "params" "w=960&output=webp&q=85") }}
+              {{ $src1920 := partial "cdn/url" (dict "page" $ "resource" . "params" "w=1920&output=webp&q=82") }}
+              <img
+                class="post-cover"
+                src="{{ $src960 }}"
+                srcset="{{ $src640 }} 640w, {{ $src960 }} 960w, {{ $src1920 }} 1920w"
+                sizes="(max-width: 688px) 100vw, 688px"
+                alt="{{ $.Params.cover_image_alt | default $.Title }}"
+                width="{{ .Width }}"
+                height="{{ .Height }}"
+                loading="eager"
+                fetchpriority="high"
+                style="width: 100%; height: auto; border-radius: 8px; display: block; box-shadow: 0 1px 6px rgba(0,0,0,0.10);" />
+            {{ else }}
+              {{ $w640  := .Resize "640x webp q85" }}
+              {{ $w960  := .Resize "960x webp q85" }}
+              {{ $w1920 := .Resize "1920x webp q82" }}
+              <img
+                class="post-cover"
+                src="{{ $w960.Permalink }}"
+                srcset="{{ $w640.Permalink }} 640w, {{ $w960.Permalink }} 960w, {{ $w1920.Permalink }} 1920w"
+                sizes="(max-width: 688px) 100vw, 688px"
+                alt="{{ $.Params.cover_image_alt | default $.Title }}"
+                width="{{ $w960.Width }}"
+                height="{{ $w960.Height }}"
+                loading="eager"
+                fetchpriority="high"
+                style="width: 100%; height: auto; border-radius: 8px; display: block; box-shadow: 0 1px 6px rgba(0,0,0,0.10);" />
+            {{ end }}
+              {{ with $.Params.cover_image_caption }}
+                <figcaption style="font-size: 0.875rem; color: rgba(33,37,41,0.65); text-align: center; margin-top: 0.75rem; font-style: italic;">{{ . | safeHTML }}</figcaption>
+              {{ end }}
+            </figure>
+          {{ end }}
+        </header>
+
+        <div
+          class="fl-rich-text c-content-block__text"
+          style="max-width: 43rem;">
+          {{ .Content }}
+        </div>
+
+        {{/* Course prev/next nav strip */}}
+        {{ partial "blog/course-prev-next.html" . }}
+
+        {{/* Tags */}}
+        {{ with .Params.tags }}
+          <div class="post-tags" style="margin-top: 2rem; margin-bottom: 1rem;">
+            <span class="post-tags-label">Filed under:</span>
+            {{ range $i, $t := . }}
+              {{ if $i }}<span class="post-tags-sep">,</span>{{ end }}
+              <a href="/blog/tags/{{ . | urlize }}/">{{ . }}</a>
+            {{ end }}
+          </div>
+        {{ end }}
+      </article>
+    </div>
+  </div>
+{{ end }}
diff --git a/themes/beaver/layouts/partials/blog/course-prev-next.html b/themes/beaver/layouts/partials/blog/course-prev-next.html
new file mode 100644
index 000000000..e8872ae55
--- /dev/null
+++ b/themes/beaver/layouts/partials/blog/course-prev-next.html
@@ -0,0 +1,62 @@
+{{/*
+  Course prev/next chapter widget.
+
+  Renders ONLY on chapter pages of the "Tech for Non-Technical Founders
+  2026" course. Looks up the current page's slug in
+  data/course_sequence.yaml and emits a small flex strip with
+  "← Prev" / "Course home" / "Next →" links.
+
+  Insertion point: bottom of the chapter body, ABOVE the
+  "## Continue the course" footer table. The intra-page "Next →"
+  blockquote that some chapters already have is complementary - this
+  partial is the cross-page navigation strip.
+*/}}
+{{ if eq (default true .Page.Params.course_nav) false }}{{ return }}{{ end }}
+{{- $slug := .Params.slug | default .File.BaseFileName -}}
+{{- $sequence := site.Data.course_sequence.sequence -}}
+{{- $idx := -1 -}}
+{{- range $i, $entry := $sequence -}}
+  {{- if eq $entry.slug $slug -}}
+    {{- $idx = $i -}}
+  {{- end -}}
+{{- end -}}
+
+{{- if ge $idx 0 -}}
+  {{- $prev := "" -}}
+  {{- $next := "" -}}
+  {{- if gt $idx 0 -}}
+    {{- $prev = index $sequence (sub $idx 1) -}}
+  {{- end -}}
+  {{- if lt $idx (sub (len $sequence) 1) -}}
+    {{- $next = index $sequence (add $idx 1) -}}
+  {{- end -}}
+
+<nav class="course-prev-next" aria-label="Course navigation">
+  <div class="course-prev-next__inner">
+    {{- if $prev }}
+    <a class="course-prev-next__link course-prev-next__link--prev" href="/course/tech-for-non-technical-founders-2026/{{ $prev.slug }}/">
+      <span class="course-prev-next__direction">← Previous</span>
+      <span class="course-prev-next__module">{{ $prev.module }}</span>
+      <span class="course-prev-next__title">{{ $prev.title }}</span>
+    </a>
+    {{- else }}
+    <span class="course-prev-next__link course-prev-next__link--placeholder" aria-hidden="true"></span>
+    {{- end }}
+
+    <a class="course-prev-next__link course-prev-next__link--home" href="/course/tech-for-non-technical-founders-2026/">
+      <span class="course-prev-next__direction">Course home</span>
+      <span class="course-prev-next__title">All 5 modules</span>
+    </a>
+
+    {{- if $next }}
+    <a class="course-prev-next__link course-prev-next__link--next" href="/course/tech-for-non-technical-founders-2026/{{ $next.slug }}/">
+      <span class="course-prev-next__direction">Next →</span>
+      <span class="course-prev-next__module">{{ $next.module }}</span>
+      <span class="course-prev-next__title">{{ $next.title }}</span>
+    </a>
+    {{- else }}
+    <span class="course-prev-next__link course-prev-next__link--placeholder" aria-hidden="true"></span>
+    {{- end }}
+  </div>
+</nav>
+{{- end -}}
diff --git a/themes/beaver/layouts/single.html b/themes/beaver/layouts/single.html
index 9de8271f7..a82f27fc6 100644
--- a/themes/beaver/layouts/single.html
+++ b/themes/beaver/layouts/single.html
@@ -111,6 +111,11 @@ <h1 class="fl-heading">{{ .Title }}</h1>
           {{ .Content }}
         </div>
 
+        {{/* Course prev/next nav strip - renders only on course chapter
+             pages (slug must be in data/course_sequence.yaml). Empty
+             string output on non-course posts. */}}
+        {{ partial "blog/course-prev-next.html" . }}
+
         {{/* Tags rendered after content - founders see education first,
              tags serve as navigation after reading. Editorial taxonomy
              style (ALL-CAPS labels) replaces hashtag style which signals