diff --git a/.gitignore b/.gitignore index 8fe973de8..f3e19757f 100644 --- a/.gitignore +++ b/.gitignore @@ -26,6 +26,7 @@ hugo.linux # Other .DS_Store .* +!.okf !.claude .claude/**/*.json .claude/**/*.sh @@ -123,3 +124,5 @@ docs/projects/**/sprint-*-verification-report.md docs/projects/**/*-coordinator-report.md docs/projects/**/*-verification-report.md .grepai/ +*.rvf +*.rvf.lock diff --git a/.okf/build/hugo-build.md b/.okf/build/hugo-build.md new file mode 100644 index 000000000..830900233 --- /dev/null +++ b/.okf/build/hugo-build.md @@ -0,0 +1,31 @@ +--- +type: Build Pipeline +title: Hugo build (bin/hugo-build) +description: Canonical build + validation entry point; runs Hugo plus the course validators including the banned-strings ratchet. +resource: bin/hugo-build +tags: [build, hugo, validation] +timestamp: 2026-07-13T00:00:00Z +--- + +`bin/hugo-build` builds the site into `_dest/public-dev/` (repo-root +`public/` is a stale artifact - never review it) and runs the validation +suite. Zero build breaks is a hard rule - all content changes must pass it +before commit. + +# Key facts + +- Course pages get extra validators, including the banned-strings ratchet + driven by [data/course_banned_strings.yaml](/content/banned-strings-ratchet.md). +- The ratchet scans course chapter SOURCE markdown (`index.md` bodies, + case-sensitive substring match) - not rendered HTML, and never SVG artwork + or mermaid diagram labels. Defects inside artwork need the + [visual scroll gate](/workflows/render-verification.md). +- Build twice as a control before blaming an edit for output flicker: + Hugo stats/PurgeCSS interactions can produce nondeterministic diffs + (term-casing races, header partialCached race). + +# Examples + +```bash +bin/hugo-build # build + validate +``` diff --git a/.okf/build/index.md b/.okf/build/index.md new file mode 100644 index 000000000..ebb1f25de --- /dev/null +++ b/.okf/build/index.md @@ -0,0 +1,5 @@ +# Build & Test + +* [Hugo build pipeline](hugo-build.md) - bin/hugo-build with the 8 course validators +* [Test gates](test-gates.md) - the three suites and when each is a commit blocker +* [Template PDFs](pdf-templates.md) - regenerating the downloadable course PDFs diff --git a/.okf/build/pdf-templates.md b/.okf/build/pdf-templates.md new file mode 100644 index 000000000..9529215ca --- /dev/null +++ b/.okf/build/pdf-templates.md @@ -0,0 +1,20 @@ +--- +type: Build Pipeline +title: Course template PDFs +description: bin/generate-template-pdfs regenerates the downloadable course PDFs from built pages; run it after editing any template chapter. +resource: bin/generate-template-pdfs +tags: [build, pdf, course] +timestamp: 2026-07-13T00:00:00Z +--- + +The course offers downloadable PDF versions of its template chapters +(worksheet, ownership checklist, and siblings). They are generated FROM the +built HTML pages, so any content change to a template chapter silently +stales its PDF. + +# Steps + +1. Edit the template chapter markdown. +2. `bin/hugo-build` +3. `bin/generate-template-pdfs` +4. Commit the regenerated PDFs together with the content change. diff --git a/.okf/build/test-gates.md b/.okf/build/test-gates.md new file mode 100644 index 000000000..c8e8c37b2 --- /dev/null +++ b/.okf/build/test-gates.md @@ -0,0 +1,35 @@ +--- +type: Playbook +title: Test gates and when they block commits +description: bin/rake test:critical always; bin/test AND bin/dtest are both mandatory for any themes/, layouts/, or CSS change. +tags: [testing, visual-regression, gates] +timestamp: 2026-07-13T00:00:00Z +--- + +# The three suites + +| Command | What it is | When required | +|---|---|---| +| `bin/rake test:critical` | Critical Minitest suite (46 runs / 84 screenshots) | After every change, before every commit | +| `bin/test` | Visual regression on macOS host (baselines in `test/fixtures/screenshots/macos/`) | Any edit to `themes/`, `layouts/`, `*.css`, or post body HTML | +| `bin/dtest` | Same suite in Linux/Docker (baselines in `linux/`) - CI runs Linux | Same trigger as bin/test; skipping it ships green-locally / red-in-CI | + +# Hard-won caveats + +- The snapshot tool REWRITES baselines when a run passes. Never edit CSS + while a suite is running - a raced run once saved a corrupt baseline + missing its hero image. Catch with pixel-compare, restore via `git checkout`. +- Visual failures are commit blockers, not warnings. Either fix the + regression or update BOTH baseline dirs (macos/ and linux/) in the same + commit with the intentional change. +- Content-only + standalone-SVG waves need + [bin/hugo-build](/build/hugo-build.md) + `test:critical` + the + [visual scroll gate](/workflows/render-verification.md) on edited pages - + the command matrix above is not the complete gate on its own. +- Changes to `lib/` (validators, helpers) additionally require + `bundle exec rake test:unit` - CI runs the unit suite and `test:critical` + does NOT include it (2026-07-17: a validator change shipped green locally, + red in CI, because its unit fixture was never run). +- Docker runs via Colima; fresh worktrees need `bun install` first. +- Tests must assert behavior shape (`q=\d+`, has ``), never tunable + config values (exact quality/width numbers). diff --git a/.okf/content/banned-strings-ratchet.md b/.okf/content/banned-strings-ratchet.md new file mode 100644 index 000000000..a69177a20 --- /dev/null +++ b/.okf/content/banned-strings-ratchet.md @@ -0,0 +1,27 @@ +--- +type: Validator +title: Banned-strings ratchet +description: data/course_banned_strings.yaml pins every fixed prose defect so it cannot silently regress; entries can be scoped to a single page. +resource: data/course_banned_strings.yaml +tags: [validation, course, regression] +timestamp: 2026-07-13T00:00:00Z +--- + +When a review sprint fixes a prose defect (a wrong tool name, a banned +phrase, a stale threshold), the exact defective string is added to +`data/course_banned_strings.yaml`. [bin/hugo-build](/build/hugo-build.md) +fails if it reappears in any course chapter's SOURCE markdown body +(case-sensitive substring match against `index.md`). + +# Rules + +- Entries support per-page scoping via an optional `scope` regex matched + against the bundle directory name (e.g. ban "Airtable" only on the + operating-kit page). There is NO exemption mechanism - if a string must + stay legal on some page, scope the entry AWAY from that page instead. +- The ratchet reads source markdown only - it is blind to text inside SVG + artwork and mermaid labels. Artwork defects are caught by the + [render-verification playbook](/workflows/render-verification.md) instead. +- After fixing any prose defect, grep your own replacement text for the + exact pattern you just removed - re-introducing the defect being fixed is + a blocking failure. diff --git a/.okf/content/course-canon.md b/.okf/content/course-canon.md new file mode 100644 index 000000000..6ea321687 --- /dev/null +++ b/.okf/content/course-canon.md @@ -0,0 +1,61 @@ +--- +type: Reference +title: Course canon numbers +description: The single source of truth for every recurring number in the course; any chapter that contradicts these is defective. +tags: [course, canon, consistency] +timestamp: 2026-07-13T00:00:00Z +--- + +# Canonical values + +| Fact | Canon | +|---|---| +| Founding Hypothesis score | ≥14/20 across four lenses | +| Smoke test traffic | 300 cold visitors | +| Interviews | 10 (from a 30-name list, expanded if replies run thin) | +| Build / pivot / kill gate | 7+ strong signals build · 4-6 pivot · under 4 kill | +| Prototype test subjects | 5 interview subjects | +| Sean Ellis must-have test | 40% - directional at ≥10 respondents, useful at 20+, sliceable at 30+ | +| Cold reply bands | 3-8% realistic; <5% stop and diagnose · 5-10% continue · >10% accelerate | +| Paid pilot deposit | $500+ refundable, via Stripe | +| Tracking tool | Google Sheet - never Airtable | +| AI token pass-through | disciplined $80-$120/dev/mo · undisciplined $300-$500; industry range $80-$300 | +| Slopsquatting source | Lasso Security research March 2025; "slopsquatting" coined by Infosecurity Magazine April 2025 | + +# Recurring cast (keep consistent across chapters) + +- **Mia** - the walkthrough protagonist (TutorMatch). +- **Marcos** (author) and **Priya** (reviewer) - the PR-review example pair. + Spelling is "Marcos", never "Marcus". PR #847 = the refund-branch review + story; the weekly-report admin-search example uses PR #843. + +Structural home: [course structure](/content/course-structure.md). +Enforcement: [banned-strings ratchet](/content/banned-strings-ratchet.md). + +# External sources for cited claims + +- Sean Ellis 40% test: [Lenny's Podcast interview](https://www.lennysnewsletter.com/p/the-original-growth-hacker-sean-ellis) (cutoff + wording). +- Slopsquatting: [Lasso Security research](https://www.lasso.security/blog/ai-package-hallucinations) + [Infosecurity Magazine, April 2025](https://www.infosecurity-magazine.com/news/ai-hallucinations-slopsquatting/) (coined the term). +- First-10-customers network finding: [Lenny Rachitsky's B2B first-customers research](https://www.lennysnewsletter.com/p/how-todays-fastest-growing-b2b-businesses). +- Interview method: Teresa Torres, [Customer Interviews](https://www.producttalk.org/customer-interviews/) and [Learning to Interview Continuously](https://www.producttalk.org/learning-to-interview-continuously/) (Product Talk). +- Reply bands, deposit bands, token pass-through ranges: internal editorial + canon (JT practice numbers) - no external citation; do not invent one. + +# Progressive elaboration rule (expand, never restart) + +Later lessons MAY deepen an earlier artifact; they MUST NOT re-derive it +from a blank page. Mechanically: any lesson touching an earlier artifact +opens WITH it - "open your [artifact] from Lesson N.N, paste it here" - +and adds a named delta. Every prompt slot names its source artifact. +Good: 2.3's three sentences ("your 1.1 blanks, unpacked - copy the +sentence in"). Bad: a persona prompt asking Sam to describe the customer +fresh when the ICP map already exists. Owner rule 2026-07-17: "it's ok to +expand previous results; but if we start over to do the same it's +confusing." + +# Terminology + +Numbered core units are **Lessons** ("Lesson N.N", never "Chapter N.N" or +"Ch N.N" - enforced by the lesson-number validator; decided in the 30.03 +format spec). "Chapters" remains only for the non-numbered long-form set +(Going Further, continuation, supplementary references). diff --git a/.okf/content/course-structure.md b/.okf/content/course-structure.md new file mode 100644 index 000000000..bb6ae9464 --- /dev/null +++ b/.okf/content/course-structure.md @@ -0,0 +1,43 @@ +--- +type: Content Architecture +title: Course structure (From Idea to First Paying Customer) +description: 5-module linear spine defined in data/course_sequence.yaml, plus a non-linear Going Further set, per-module Mia walkthroughs, and template chapters. +resource: content/course/tech-for-non-technical-founders-2026/ +tags: [course, structure, hugo] +timestamp: 2026-07-17T00:00:00Z +--- + +# The spine + +The reading order lives in `data/course_sequence.yaml` - the Overview +(how-this-course-works) then Modules 1-5 (hypothesis → smoke test → +interviews → brief/build → first paying customer). The prev/next strip, +branch-aware forks, and the `course-stat` shortcode all derive from that +file. Never hardcode exact chapter counts in prose; use near numbers +("20+ lessons"). + +# Outside the spine + +- **Going Further set** (linked from the 5.7 closing callout): continuation + chapters (churn triage, pivot-or-persevere), the hire-track reference, + demoted management chapters (engineering org chart, friday demo rule, + three questions standup, weekly dev report), and the AI-in-production trio + (agency AI questions → AI token bill → slopsquatting, badged Step 1-3 of 3). +- **Mia walkthroughs**: one per module (`module-N-walkthrough-mia`). +- **Templates**: worksheet/checklist/script chapters with + [generated PDFs](/build/pdf-templates.md). +- **Reference deep-dives** under `reference/` - every module now has them + (M1: hypothesis-sprint-full, smoke-test-channel-guide, + stripe-price-test-full; M2: mom-test-full, persona-rehearsal-full, + find-10-people-full (shared by 2.3+2.4), prototype-build-full; + M3: product-brief-full, outcomes-not-features-full; M4: hire-decision-full, + ownership-full, stack-tools-full, mvp-build-phases-full, + ceiling-signals-full; M5: must-have-survey-full, channel-selection-full, + paid-pilot-full, outbound-full). Lessons point at them via a + `Deeper reference:` footer line; the module landing cards link them as + "Optional reference". As of 2026-07-17 ALL five modules are migrated to + the v2 micro-lesson format - no v1 long-form lessons remain. +- **Floating glossary**: five-tech-words-stop-nodding-at, reachable from every + chapter, not in the linear order. + +All chapter facts must agree with the [course canon](/content/course-canon.md). diff --git a/.okf/content/index.md b/.okf/content/index.md new file mode 100644 index 000000000..344404089 --- /dev/null +++ b/.okf/content/index.md @@ -0,0 +1,6 @@ +# Content + +* [Course structure](course-structure.md) - the 5-module spine, Going Further set, and course_sequence.yaml +* [Course canon](course-canon.md) - the numbers every chapter must agree on +* [Voice rules](voice-rules.md) - Sam voice, banned patterns, and the em-dash rule +* [Banned-strings ratchet](banned-strings-ratchet.md) - how fixed prose defects stay fixed diff --git a/.okf/content/voice-rules.md b/.okf/content/voice-rules.md new file mode 100644 index 000000000..40939e201 --- /dev/null +++ b/.okf/content/voice-rules.md @@ -0,0 +1,42 @@ +--- +type: Style Guide +title: Course voice rules (write for Sam) +description: The reader is Sam, an idea-stage non-technical first-time founder; plain-words glossing, dash style, and the banned structural patterns. +tags: [voice, style, course] +timestamp: 2026-07-13T00:00:00Z +--- + +Full guides: `docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md` +and the course-specific rules in `CLAUDE.md`. This concept records the +rules that recur in review sprints. + +# Core rules + +- **Write for Sam, not Paul.** Sam is an idea-stage non-technical founder. + Course bodies never use rescue/trauma framing (that ICP is the website's + "Alex", not the course's Sam); the Going Further rescue chapters are the + exemption. +- **Gloss at first mention** - every acronym/tool/term gets a plain-words + parenthetical the first time it appears in the reading order (SOW, MSA, + SLA, FTE, PLG, ARPU, MAU, RAG-status, 0day...). +- **Dashes**: always "-", never "—" - in prose AND inside SVG/mermaid artwork. +- **Progressive disclosure**: orientation blocks orient; thresholds and + mechanics belong where the reader acts on them. +- **Callout rhythm**: no two adjacent same-form callouts. + +# Banned structural patterns (reject on sight) + +Slogany reveal-twist flips ("X wasn't Y - it was Z"), cinematic time-cut +narration, anonymous-founder-vignette openers repeated 3+ chapters in a row, +aphoristic flourish closers, fabricated cohort stats without a source, +`## Why this matters` headings, "Founders who / Most founders / Founders we +worked with", dual-source statistical openers, sustained staccato. + +Sentence-level slop scoring is necessary but NOT sufficient - shape-tell +review (essay arc, pivot sentences, cloned scaffolding) runs alongside it. + +Regression sweep before any handback: + +```bash +grep -rn "## Why this matters\|Founders who\|Most founders\|Founders we worked with" content/course/ +``` diff --git a/.okf/design/course-typography.md b/.okf/design/course-typography.md new file mode 100644 index 000000000..ee1bedd9e --- /dev/null +++ b/.okf/design/course-typography.md @@ -0,0 +1,34 @@ +--- +type: Design System +title: Course reading typography +description: Course pages read at 20px/1.65 body scale (blog keeps 22.4px); overrides must mirror the full single-post.css selector chain or they silently lose. +resource: themes/beaver/assets/css/style.css +tags: [css, typography, course] +timestamp: 2026-07-13T00:00:00Z +--- + +# The scale (course pages only) + +| Element | Value | +|---|---| +| Body p / li | 20px / 1.65 | +| li margin | 12px | +| Blockquote/callout p | 19px / 1.6 | +| Worksheet card p, ws-checks li | 17px / 1.55 | +| ws-route p | 16.5px | + +The blog keeps its thoughtbot-anchored 22.4px scale - the course override is +scoped with a `.section-course` prefix. + +# The specificity trap + +`single-post.css` sets body type via +`.blog article.single-content .fl-rich-text p` (specificity 0,3,2). Any +course override weaker than that silently loses - a plain +`.section-course .blog p` (0,2,1) does nothing. Mirror the FULL chain: +`.section-course .blog article.single-content .fl-rich-text p`. + +Also: broad element rules (e.g. the 20px li rule) can invert component +hierarchies - the worksheet-card checklist items got bumped to 20px and had +to be re-pinned to 17px. After any type change, run both visual suites per +[test gates](/build/test-gates.md). diff --git a/.okf/design/cover-pipeline.md b/.okf/design/cover-pipeline.md new file mode 100644 index 000000000..7e0a2b32d --- /dev/null +++ b/.okf/design/cover-pipeline.md @@ -0,0 +1,29 @@ +--- +type: Playbook +title: Course cover rebuild pipeline +description: Covers are rebuilt as full HTML per .stitch/design.md rendered headless at 2400x1260; chip-composite for single-fact edits. +resource: .stitch/design.md +tags: [covers, design, stitch] +timestamp: 2026-07-13T00:00:00Z +--- + +Original covers were Stitch-made and their downloads are auth-gated, so the +working rebuild path is: author a full HTML page implementing the spec and +screenshot it headless at 2400x1260. + +# Spec essentials (.stitch/design.md) + +- Titles: Space Grotesk 800, letter-spacing -0.03em +- Chip labels: Inter 600, 22px, letter-spacing 0.14em +- Chip values: Space Grotesk 700 +- Status line: JetBrains Mono +- Palette: JetVelocity - obsidian dark, Ruby red #cc342d, neon purple #a855f7 + +# Techniques + +- Full rebuild: HTML file in scratchpad → headless Chrome screenshot → + `cover.png` (update the `cover_image_alt` frontmatter to match). +- Single-fact edit (one chip's wording): chip-composite - render just the + corrected chip and composite it over the existing PNG with magick. +- Watch sub-glyph grazes on chips ("%", trailing "E"); fix with explicit + `
` splits and ` ` slack, verify with zoomed re-renders. diff --git a/.okf/design/house-visual-spec.md b/.okf/design/house-visual-spec.md new file mode 100644 index 000000000..b3aa5500c --- /dev/null +++ b/.okf/design/house-visual-spec.md @@ -0,0 +1,32 @@ +--- +type: Design System +title: House in-post visual spec +description: Hand-drawn SVG house style - paper tones, 2-2.5px strokes, semantic colors (green = money only), labels inside shapes. +resource: .stitch/prompts/course-inpost-visual-prompt.md +tags: [svg, design, course] +timestamp: 2026-07-13T00:00:00Z +--- + +# The spec in one table + +| Element | Rule | +|---|---| +| Backgrounds | Paper tones: #fff5f5 (red-tint), #faf7f2 (cream), #f0f9f0 (green), #fbe9ff (purple) | +| Strokes | 2-2.5px, hand-drawn feel | +| Red | Action / anti-pattern | +| Purple | Alternate path | +| Green | ONLY money/success outcomes | +| Amber | Warnings | +| Typography | Caveat / Patrick Hand / Comic Sans MS cursive stack | +| Labels | INSIDE shapes (Sweller split-attention rule); never bare diamonds | +| Dashes | "-" only, including inside artwork | + +# Exemplars + +`invoice-loop.svg` (ai-token-bill) and `network-buckets.svg` are the +canonical compact hand-drawn exemplars - numbered step cards, outcome cards, +dashed loop, header + italic subtitle, ~960x470. + +Diagrams taller than 2x viewport read as a wall, not a hook - replace with a +compact SVG or table. Verify every new visual with the +[render-verification playbook](/workflows/render-verification.md). diff --git a/.okf/design/index.md b/.okf/design/index.md new file mode 100644 index 000000000..bac55cdfa --- /dev/null +++ b/.okf/design/index.md @@ -0,0 +1,6 @@ +# Design + +* [Mermaid theme](mermaid-theme.md) - the Caveat webfont root-cause fix and the theming gotchas +* [House visual spec](house-visual-spec.md) - paper tones, semantic colors, hand-drawn identity +* [Cover pipeline](cover-pipeline.md) - rebuilding course covers from the design spec +* [Course typography](course-typography.md) - the course-scoped reading scale and the specificity trap diff --git a/.okf/design/mermaid-theme.md b/.okf/design/mermaid-theme.md new file mode 100644 index 000000000..022d1c214 --- /dev/null +++ b/.okf/design/mermaid-theme.md @@ -0,0 +1,40 @@ +--- +type: Design System +title: Mermaid house theme and the Caveat webfont fix +description: Mermaid renders in Caveat handwritten cursive, loaded explicitly and awaited via document.fonts.ready; label metrics gotchas documented. +resource: themes/beaver/layouts/baseof.html +tags: [mermaid, fonts, design] +timestamp: 2026-07-13T00:00:00Z +--- + +# Root cause worth remembering + +The Caveat webfont was historically NEVER loaded - mermaid fell back to the +platform's generic cursive (Apple Chancery on macOS) and measured labels +with different metrics than it rendered, causing a whole class of recurring +last-character clipping. The fix in `baseof.html`: + +1. Google Fonts Caveat `` (+ preconnects), gated on `features.mermaid`. +2. `startOnLoad: false` and `document.fonts.ready.then(() => mermaid.run())`. +3. Font stack `'Caveat', 'Patrick Hand', 'Comic Sans MS', cursive` - mirrors + the in-post SVGs' fallback. + +# Theming gotchas + +- NEVER set font-size/padding on `.edgeLabel` via `themeCSS` - it applies + AFTER measurement and reintroduces the measure/render mismatch. +- Labels ending in wide glyphs (%) clip; append ` ` inside the label or + keep edge labels to 1-2 words. +- Bare diamond decision nodes are banned - use rects. +- Flowchart spacing: `nodeSpacing: 45, rankSpacing: 55, padding: 14`. +- Mermaid code fences render via + `themes/beaver/layouts/_markup/render-codeblock-mermaid.html`, which sets + `features.mermaid`. + +# Brand rule + +Handwritten typography in diagrams is a non-negotiable brand identity - +the owner rejected a clean-sans mermaid theme on sight the same day he had +approved it in the abstract. Fix legibility structurally (compact SVG, +table) rather than by changing the font. See the +[house visual spec](/design/house-visual-spec.md). diff --git a/.okf/index.md b/.okf/index.md new file mode 100644 index 000000000..091b515fb --- /dev/null +++ b/.okf/index.md @@ -0,0 +1,16 @@ +--- +okf_version: "0.1" +--- + +# JetThoughts Blog & Course — Knowledge Bundle + +Curated operational knowledge for the Hugo static site at +`jetthoughts.github.io`, with emphasis on the 2026 course project +(`content/course/tech-for-non-technical-founders-2026/`). + +# Sections + +* [Build & Test](build/) - build pipeline, validators, and the blocking test gates +* [Content](content/) - course structure, canonical numbers, and voice rules +* [Design](design/) - mermaid theme, house visual spec, covers, typography +* [Workflows](workflows/) - render-verification recipes and review-swarm patterns diff --git a/.okf/log.md b/.okf/log.md new file mode 100644 index 000000000..bab56abdd --- /dev/null +++ b/.okf/log.md @@ -0,0 +1,32 @@ +# Bundle Update Log + +## 2026-07-13 +* **Update**: taste anchor established at `.stitch/course-taste-design.md` - Stitch-skill DESIGN.md encoding the course design language + anti-pattern bans; used as the scoring lens for taste-critic passes (see [review-swarm](/workflows/review-swarm.md)). +* **Update**: [render-verification](/workflows/render-verification.md) - render from `_dest/public-dev/` (relative URLs), never the stale repo-root `public/`; stale-tree reviews produce false missing-asset findings. +* **Initialization**: Created the bundle with build/, content/, design/, and workflows/ sections distilled from CLAUDE.md, docs/workflows/, .stitch/design.md, and the 2026-07 course review sprints. + +## 2026-07-17 - M2 compression migration +Module 2 (last unmigrated module, 1,652-5,124 body words/lesson) compressed to +exemplar parity (1,265-2,038; migrated 1.4 exemplar = 1,258 on the same basis). +Depth moved to four new reference companions: mom-test-full, +persona-rehearsal-full, find-10-people-full (shared 2.3+2.4), +prototype-build-full. Operative rule learned: the 30.03 numeric bands are +unreachable when mandated keeps (full prompts, teaching tables, reuse bridges) +exceed the band - EXEMPLAR PARITY on an identical measurement basis is the +real gate, not the raw number. M3 (3.1/3.2 at ~2,900w) is the remaining +unmigrated pair. + +## 2026-07-17 (later) - Full-course migration complete +M3 (3.1/3.2), M4 (all five), and M5 (5.1/5.2/5.6/5.7) migrated to v2 +micro-lesson form in one 5-fixer wave; 11 new reference companions created +(every module now has its deep-dive set). Canon punch-list applied (Cursor +seat range, "Sixty percent" stat, PR #847 collision, fast/easy/free columns, +Chapter 0 -> Overview, faq 12-rules pointer). Cold-eyes M3+ reuse review +fixed 4 restart defects (5.3 warm-list seeding, SOW brief-as-scope, 5.1 +persona reconciliation, PRD Section 2). No v1 long-form lessons remain. +Gotcha: claude-flow daemons recreate .git/index.lock continuously - commit +via retry loop (rm lock + immediate git add/commit, up to 10 attempts). +Voice wave (same day): 16-page opener-shape rotation shipped - max 4 pages +per shape, 4 composite-disclaimed vignettes kept, attribution phrases +("we picked up"/"we worked with") now zero course-wide. Teaching numbers +preserved as mechanism descriptions. diff --git a/.okf/workflows/index.md b/.okf/workflows/index.md new file mode 100644 index 000000000..de645119b --- /dev/null +++ b/.okf/workflows/index.md @@ -0,0 +1,4 @@ +# Workflows + +* [Render verification](render-verification.md) - headless Chrome + slicing recipes for the visual scroll gate +* [Review swarm](review-swarm.md) - the two-critic review pattern and its failure modes diff --git a/.okf/workflows/render-verification.md b/.okf/workflows/render-verification.md new file mode 100644 index 000000000..29e2532b7 --- /dev/null +++ b/.okf/workflows/render-verification.md @@ -0,0 +1,51 @@ +--- +type: Playbook +title: Render verification (visual scroll gate) +description: The working headless-Chrome capture, page-slicing, and SVG re-render recipes used to inspect every scroll view of a page. +tags: [verification, chrome, screenshots] +timestamp: 2026-07-13T00:00:00Z +--- + +Text validators cannot see rendered output - mermaid clipping, SVG text +crossing borders, stale cover badges, and wrong-direction "diagram above" +references are all invisible to grep. Canonical protocol: +`docs/workflows/visual-scroll-gate.md`. + +# Render from _dest/public-dev, NEVER public/ + +[bin/hugo-build](/build/hugo-build.md) outputs to `_dest/public-dev/` with +RELATIVE asset URLs (covers and SVGs work over file://). The repo-root +`public/` directory is a stale artifact of raw `hugo` runs or the dev +server (localhost:1717 or canonified production URLs baked in) - reviewing +it produces false "missing image / missing cover / nav overlap" findings. +The 2026-07-13 review wave lost a whole finding class to this. + +# Working capture recipe (macOS) + +Chrome never exits on its own - background it and kill after a sleep: + +```bash +'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome' \ + --headless --disable-gpu --user-data-dir=$(mktemp -d) \ + --hide-scrollbars --window-size=1280,20000 --virtual-time-budget=8000 \ + --screenshot=page.png "file:///path/to/public/.../index.html" & P=$! +sleep 14; kill $P +``` + +- First-fold check is its own capture: rerun with `--window-size=1280,800` + (the tall 20,000px canvas shows content, not what fits the fold). +- 390-wide window for mobile first-fold; raw headless is NOT full mobile + emulation (no viewport-meta scaling; body text fake-clips at the right + edge) - true mobile checks need chrome-devtools MCP device emulation. +- Slice for inspection: `magick page.png -trim +repage -crop 1280x2400 +repage p-%02d.png` +- Standalone SVGs: `rsvg-convert -w 1400 file.svg -o out.png` then inspect. +- Line-fraction crop estimates are unreliable (tables/code expand); iterate + crops or measure with getBoundingClientRect. + +# The gate + +Walk EVERY slice at 1280x800 and 390x844 and actually look at each one +before handback. Score new visuals on: great look / functional / earns the +next scroll / helpful. Any NO on the last two = rollback or redesign. +Diagram checklist lives in the [house visual spec](/design/house-visual-spec.md) +and [mermaid theme](/design/mermaid-theme.md). diff --git a/.okf/workflows/review-swarm.md b/.okf/workflows/review-swarm.md new file mode 100644 index 000000000..05e0a215f --- /dev/null +++ b/.okf/workflows/review-swarm.md @@ -0,0 +1,51 @@ +--- +type: Playbook +title: Two-critic review swarm +description: The proven module-review loop - a design critic (full render walk) plus a content-canon critic, followed by verified fixer waves. +tags: [swarm, review, process] +timestamp: 2026-07-17T00:00:00Z +--- + +# The loop + +1. Build the site so critics inspect fresh output. +2. Spawn a DESIGN critic (renders every page via the + [render-verification recipe](/workflows/render-verification.md), scores + worst-first) and a CONTENT-CANON critic (diffs numbers against the + [course canon](/content/course-canon.md), sweeps banned patterns, checks + links) in parallel, in the background. +3. Adjudicate reports; VERIFY every claim against the actual files/renders + before acting - critics are sometimes wrong about line numbers or values. +4. Fix surgically (one attribute = one edit; never re-theme the page). +5. Add ratchet entries for fixed prose defects + ([banned-strings ratchet](/content/banned-strings-ratchet.md)). +6. Gates per [test gates](/build/test-gates.md), commit to the sprint + branch, one bundled PR per sprint. + +# Taste pass (premium bar) + +After defect review, run taste critics scoring 1-10 against +`.stitch/course-taste-design.md` - defect checklists miss "technically +fine but not premium" (monotone callout runs, brand living only in the +cover, wall-shaped diagrams). Adjudicate critic conflicts against the +anchor text, not majority vote: taste-e's red-metric ruling beat +taste-a's recolor suggestion because the anchor names Ruby as the brand +accent ink. + +# Mechanical runbook + +The full audit is codified as a command+pass-rule checklist that +less-powerful models can execute: `docs/workflows/course-audit-checklist.md` +(8 phases: length, structure, terminology, canon, reuse/seams, render gate, +judged checks with escalation rules, fix/report protocol). Hand agents that +file instead of re-deriving audit briefs per session. + +# Known failure modes + +- Agents often go idle WITHOUT sending their report - nudge via SendMessage, + and verify their work in the tree regardless. +- Session-limit failures kill whole waves; respawn after the reset rather + than retrying immediately. +- Fixer geometry claims (SVG sizes, clipping fixed) must be re-verified by + your own re-render - one wave shipped a wording truncation nobody saw. +- Parallel sessions contend on .git/index.lock - wait-loop before git ops. diff --git a/.stitch/course-taste-design.md b/.stitch/course-taste-design.md new file mode 100644 index 000000000..ff0d9e651 --- /dev/null +++ b/.stitch/course-taste-design.md @@ -0,0 +1,91 @@ +# Design System: From Idea to First Paying Customer (course pages) + +Stitch-compatible DESIGN.md for the 2026 course. Single source of truth for +taste-scoring course pages and for generating Stitch concepts of in-post +visuals. Where this conflicts with generic design advice, THIS file wins - +the handwritten identity is owner-mandated brand (sans artwork was rejected +on sight 2026-07-12). + +## 1. Visual Theme & Atmosphere + +A founder's annotated field notebook: warm paper surfaces, hand-drawn +diagrams with confident 2-2.5px strokes, dark editorial covers that snap +against the cream page. Density "Daily App Balanced" (5) - every H2's worth +of prose earns one visual break. Variance "Offset Asymmetric" (5) - diagrams +are horizontal strips and card rows, never symmetric 3-up grids. Motion +"Static Restrained" (2) - the page holds still; the hand-drawn line carries +the energy. + +## 2. Color Palette & Roles + +- **Paper Cream** (#faf7f2) - default diagram card fill +- **Blush Paper** (#fff5f5) - red-tinted fill for action/anti-pattern cards +- **Mint Paper** (#f0f9f0) - green-tinted fill, money/success outcomes ONLY +- **Lilac Paper** (#fbe9ff) - purple-tinted fill for alternate paths +- **Ruby Ink** (#cc342d) - action, anti-pattern, "stop" accents; brand red +- **Forest Ink** (#2e7d32) - money and success outcomes ONLY, never decoration +- **Violet Ink** (#a855f7) - alternate path, optional branch +- **Amber Ink** (#d97706 on #fffbeb) - warnings and conditional states +- **Notebook Black** (#1a1a1a) - primary artwork text; never #000000 +- **Pencil Gray** (#555/#666) - captions, subtitles, annotations + +Covers only (JetVelocity): obsidian dark ground, Ruby red #cc342d, neon +purple #a855f7 - the dark cover is the one deliberate contrast slam per page. + +## 3. Typography Rules + +- **Artwork (SVG/mermaid):** `"Caveat", "Patrick Hand", "Comic Sans MS", cursive` + - the full stack is MANDATORY (SVG-as-img cannot load webfonts; Comic Sans + MS is the only handwritten face reliably installed - omitting it re-enters + the platform font lottery). +- **Covers:** Space Grotesk 800 titles (-0.03em), Inter 600 chip labels + (22px / 0.14em), Space Grotesk 700 chip values, JetBrains Mono status. +- **Body prose:** theme sans at 20px/1.65 (course scope), li margin 12px, + callouts 19px/1.6. +- **Depicted UI/code inside artwork:** sans/mono is CORRECT when the artwork + imitates a real screen, email, or terminal - the handwritten voice is for + the diagram's own labels, headers, and annotations. +- **Dashes:** "-" everywhere, including inside artwork. "—" is banned. + +## 4. Component Stylings + +* **Diagram cards:** paper fill, 2-2.5px Notebook Black or semantic-ink + border, 12-14px radius, label INSIDE the shape (Sweller split-attention). +* **Step strips:** numbered pill chips (Ruby fill, white numeral) + arrows, + header + italic Pencil Gray subtitle - exemplar `invoice-loop.svg`. +* **Callouts:** red-left-border aside is the default; `bq-good` (green) / + `bq-bad` (red) variants for good/bad exemplars; `bq-tldr` for TL;DR. Never + two same-form callouts adjacent. +* **Tables:** decision aids and comparisons; 6+ visually identical rows need + per-row differentiation (color-coded labels, icons, or grouped sub-tables). +* **Worksheet cards (`ws-*`):** cream card, checkbox squares, dashed verdict + strip, green go-route / purple alt-route. + +## 5. Layout Principles + +- Diagrams are compact horizontal strips (~960x300-560); anything taller + than 2x viewport reads as a wall and must become a strip or table. +- First fold (1280x800) always carries a visual hook - dark cover or + handwritten strip. Pure-text heroes are a defect. +- One visual break per H2 run; 3+ H2s of plain prose is a rhythm defect. +- No overlap: labels never cross borders; artwork text never grazes edges + (verify by render - Caveat metrics differ from sans). + +## 6. Motion & Interaction + +None inside the course pages. Mermaid renders after `document.fonts.ready` +(never remove - it kills the measure/render font mismatch class of bugs). + +## 7. Anti-Patterns (Banned) + +- Sans-serif diagram labels/headers (except depicted-UI mimicry, §3) +- Green used for anything but money/success; conditional states in green +- Bare diamond decision nodes; mermaid edge labels over 2 words +- Font stacks missing the Comic Sans MS fallback +- Em-dashes anywhere; year-stamped "LABEL // 2026" typography +- Fabricated metrics in artwork (numbers must come from the page's canon) +- Decorative visuals that add no information (delete instead) +- Corporate-slide look: symmetric 3-equal-card rows, glossy gradients, + neon glows, stock photography, generic icon arrays +- "Scroll to explore" filler, emoji in artwork, pure #000000 +- Repeating one callout form 3+ times in a row on a page diff --git a/.stitch/prompts/course-inpost-visual-prompt.md b/.stitch/prompts/course-inpost-visual-prompt.md new file mode 100644 index 000000000..14e76a306 --- /dev/null +++ b/.stitch/prompts/course-inpost-visual-prompt.md @@ -0,0 +1,79 @@ +# Master prompt — in-post course visuals (inline SVG + mermaid) + +Reusable AI-design prompt for redesigning the diagrams that live INSIDE course +pages (not covers). Written 2026-07-12 after a design-critic triage of all ~70 +in-post visuals. Covers get `.stitch/prompts/course-landing-hero-prompt.md`; +this file governs everything rendered in the reading column. + +--- + +Redesign an informational diagram that sits inline in a long-form lesson for a +non-technical first-time founder ("Sam"). The diagram interrupts reading, so it +must pay for the interruption: a reader who looks ONLY at the diagram should +learn the section's core decision or structure in under 5 seconds. + +CONTEXT CONSTRAINTS: +- Renders in a ~688px-wide reading column on WHITE page background (mobile: + ~360px, may scroll horizontally inside its own container but must stay + legible without zooming). +- It is content, not decoration: labels INSIDE shapes (Sweller split-attention + rule); if a separate paragraph is needed to explain it, the diagram failed. +- One diagram = one idea. If it needs two ideas, make two diagrams or a table. + +HOUSE FAMILY - "informational sketch, drawn by a confident hand": +- Paper-tone fills: #fff5f5 (warm) / #faf7f2 (cream) / #f0f9f0 (success tint) + / #fbe9ff (purple tint) on white; NEVER dark backgrounds inline. +- Stroke grammar: uniform 2-2.5px strokes, rounded corners (rx 10-16), slight + per-card rotation (max ±1.5°) allowed for the sketch feel - but ALL shapes in + one diagram share the same stroke weight and corner language. +- Color = meaning, never mood: red #cc342d for the action/anti-pattern side, + purple #a855f7 for the alternate branch, green #2e7d32 ONLY for + pass/money/success, amber #b8860b sparingly for warnings, gray #666 for + neutral structure. Two accent colors max per diagram plus green if there is + a success state. +- Typography: Caveat / Patrick Hand for labels (>=15px effective at column + width), plain sans-serif is acceptable for dense table-like cells; NEVER + mix a third family; NEVER let a font fallback to system defaults (embed or + restrict text to the declared stack + sans-serif tail). The handwritten + family is the house identity - the owner rejected a clean-sans diagram + variant on sight (2026-07-12). +- Hierarchy: exactly one visual entry point (title or biggest shape); reading + order left-to-right or top-to-bottom, marked with arrows that touch the + shapes they connect; annotations in gray italic BELOW or BESIDE, never + across artwork. + +MERMAID-SPECIFIC (when the diagram stays a mermaid block): +- The handwritten family STAYS. A clean-sans mermaid theme was shipped and + rejected by the owner on sight the same day (2026-07-12: "typography is + not handwritten") - and it clipped labels anyway (sans glyphs are wider + than mermaid's measured boxes). Fix legibility STRUCTURALLY: an + oversized / awkward / all-red flowchart becomes a compact hand-drawn + SVG in the house family (exemplar: ai-token-bill invoice-loop.svg) or + a decision table - not a font change. +- Always include the house init: theme base, fontFamily 'Caveat, Patrick + Hand, cursive', fontSize >=20px, primaryColor #fff5f5, + primaryBorderColor #cc342d, lineColor #333, primaryTextColor #1a1a1a. + The site-level default in baseof.html already carries these; the + per-diagram init is for repo-greppable self-containment. +- Rect nodes with the question/threshold INSIDE; never bare diamonds (they + crush cursive text). +- Edge labels: mermaid's measured label box runs ~1 glyph short, so labels + ending in a wide glyph (%, digits, K) clip their last character. Append + ` ` inside the label (`-->|Over 40% |`) or keep edge labels to + 1-2 short words and move thresholds into the node. Never set font-size + or padding on .edgeLabel via themeCSS - it applies after measurement. +- Max ~6 nodes per direction; a sequential checklist of gates is NOT a + flowchart - render it as a decision TABLE instead (proven pattern: + engineering-org-chart, pivot-or-persevere). +- LR for <=6 short-label nodes in a row; TD for branching; never a staircase + (LR+TD mixed) - it scales the whole render down to micro-text. + +QUALITY GATES (reject if any fails): +- Screenshot at 688px column width: every label legible without zoom. +- No text within 12px of any border it doesn't belong to; nothing crosses + another element's text. +- Squint test: the diagram's ONE idea survives blurring (hierarchy holds). +- Family test: put it beside network-buckets.svg and page-anatomy.svg - it + must look drawn by the same hand. +- Information test: delete the diagram - if the section loses nothing, the + diagram should not exist (fix by adding the missing info, not ornament). diff --git a/CLAUDE.md b/CLAUDE.md index 98a311de0..3d93263cc 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -30,6 +30,19 @@ Always read these files before making changes. They define the project's archite --- +## 📚 OKF Knowledge Bundle (`.okf/`) + +Distilled operational knowledge lives in the OKF v0.1 bundle at `.okf/` (markdown + YAML frontmatter, one concept per file). **Consume it via progressive disclosure**: read `.okf/index.md` first, then follow links into only the concepts relevant to the task. + +- `.okf/build/` — build pipeline, blocking test gates, template-PDF regeneration +- `.okf/content/` — course structure, canonical numbers, voice rules, banned-strings ratchet +- `.okf/design/` — mermaid/Caveat theme, house visual spec, cover pipeline, course typography +- `.okf/workflows/` — render-verification recipes, review-swarm pattern + +**Maintain it as you work**: when you learn something durable (a new canon number, a root-cause fix, a workflow gotcha), update the affected concept file and its `timestamp`, refresh the section `index.md`, and append a dated entry to `.okf/log.md`. Validate with `/okf:validate .okf --strict` before committing bundle changes. + +--- + ## 🔍 Research Protocol (MANDATORY) **Session start**: Always read `@docs/workflows/BASE_HANDBOOK.md` and `@docs/workflows/flow-router.md`. diff --git a/content/course/tech-for-non-technical-founders-2026/_index.md b/content/course/tech-for-non-technical-founders-2026/_index.md index 311bb0f6d..7a8ee3179 100644 --- a/content/course/tech-for-non-technical-founders-2026/_index.md +++ b/content/course/tech-for-non-technical-founders-2026/_index.md @@ -32,7 +32,7 @@ hero_chips: - "5 modules" - "Evenings & weekends pace" hero_primary_url: "/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/" -hero_primary_text: "Start Chapter 1.1 →" +hero_primary_text: "Start Lesson 1.1 →" hero_secondary_url: "/course/tech-for-non-technical-founders-2026/quickstart/" hero_secondary_text: "3-minute Quickstart" --- @@ -41,7 +41,7 @@ Five modules take you from that idea to a signed paid pilot: test demand with st The first checkpoint comes fast. Two to three weeks in, at an evenings-and-weekends pace, you'll know whether the idea is worth building at all - a go/iterate/kill verdict on your **Founding Hypothesis** (the one-sentence version of your idea: who the customer is, what problem you solve, why they'd pick you) from real demand data instead of polite nods from friends. -New here? Read [How This Course Works](/course/tech-for-non-technical-founders-2026/how-this-course-works/) once - the 10-minute route map - then start [Chapter 1.1](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/). Short on time tonight? The [Quickstart](/course/tech-for-non-technical-founders-2026/quickstart/) (3 min) is the compressed version, and the [FAQ](/course/tech-for-non-technical-founders-2026/faq/) answers the most common blockers. +New here? Read [How This Course Works](/course/tech-for-non-technical-founders-2026/how-this-course-works/) once - the 10-minute route map - then start [Lesson 1.1](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/). Short on time tonight? The [Quickstart](/course/tech-for-non-technical-founders-2026/quickstart/) (3 min) is the compressed version, and the [FAQ](/course/tech-for-non-technical-founders-2026/faq/) answers the most common blockers. *Returning? [Skip to the syllabus ↓](#module-map)* @@ -94,13 +94,13 @@ Read the modules in order. Each module's output is the next module's input, and Start here if you've never talked to 10+ potential customers about the problem you want to solve.

  1. 2.1 The Mom Test: Ask About the Past, Not the Future
    2. -
  2. 2.2 Sharpen Your Question List with AI Personas optional
    Skip if you've interviewed before. The Mom Test in 2.1 is the core; this chapter rehearses your questions with AI personas first.
    3. +
  3. 2.2 Sharpen Your Question List with AI Personas optional
    Skip if you've interviewed before. The Mom Test in 2.1 is the core; this lesson rehearses your questions with AI personas first.
  4. 2.3 Find 10 People: Where to Look
  5. 2.4 Find 10 People: What to Say
  6. 2.5 Mom Test Synthesis: Build, Pivot, or Kill
  7. 2.6 Build a Clickable Prototype
-

Templates in this module: Interview Script · Validated Problem Statement · Outreach Sequence · See it in action: Mia interviews ten parents - a full Module 2 walkthrough

+

Templates in this module: Interview Script · Validated Problem Statement · Outreach Sequence · Optional reference: Mom Test deep dive · Persona rehearsal · Find 10 People deep dive · Prototype build deep dive · See it in action: Mia interviews ten parents - a full Module 2 walkthrough

You leave with: 10 scored interview transcripts, a written build/pivot/kill decision, and a prototype 5 real customers have clicked through - evidence you can quote back to yourself when doubt creeps in.

@@ -113,7 +113,7 @@ Read the modules in order. Each module's output is the next module's input, and
  • 3.1 The One-Page Product Brief (Vibe PRD)
  • 3.2 Quality-check Your Brief: Features to Outcomes
    • -

    Template in this module: Vibe PRD · Course glossary (reference, not in the linear path): Five Tech Words to Stop Nodding At · See it in action: Mia writes the one-page brief

    +

    Template in this module: Vibe PRD · Optional reference: Product Brief deep dive · Outcome rewrite deep dive · Course glossary (reference, not in the linear path): Five Tech Words to Stop Nodding At · See it in action: Mia writes the one-page brief

    You leave with: a one-page Product Brief where every feature traces back to something a customer actually said.

    @@ -129,7 +129,7 @@ Read the modules in order. Each module's output is the next module's input, and
  • 4.4 The Self-Serve MVP Stack: Build Phases
  • 4.5 Vibe Coding Done Right: 5 Ceiling Signals optional
    Skip on first pass. Come back when your no-code build hits a wall - a feature you can't add, a query you can't tune, an auth flow Lovable can't handle.
    • -

    Templates in this module: Build Path Decision Worksheet · Ownership Checklist · Self-Serve Stack Walkthrough · See it in action: Mia ships TutorMatch

    +

    Templates in this module: Build Path Decision Worksheet · Ownership Checklist · Self-Serve Stack Walkthrough · Optional reference: Build-vs-hire deep dive · Ownership deep dive · Stack tools deep dive · Build phases deep dive · Ceiling signals deep dive · See it in action: Mia ships TutorMatch

    You leave with: a live MVP at a real URL that you built and you own - every account in your name from Day 1.

    @@ -147,7 +147,7 @@ Read the modules in order. Each module's output is the next module's input, and
  • 5.6 Charge Before You Ship: The Paid Pilot Contract
  • 5.7 Going Outbound Without a Sales Team optional
    Skip if your personal network in 5.3-5.5 produced your first 10 customers. This is the systematic path for when warm intros run out.
    • -

    Template in this module: First Paying Customer Operating Kit · See it in action: Mia gets paid

    +

    Template in this module: First Paying Customer Operating Kit · Optional reference: Sean Ellis survey deep dive · Channel selection · Paid pilot playbook · Cold outbound deep dive · See it in action: Mia gets paid

    You leave with: a signed paid pilot and your first dollar from a customer, not a favor.

    @@ -156,7 +156,7 @@ Read the modules in order. Each module's output is the next module's input, and 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](https://lovable.dev) + [Supabase](https://supabase.com) + [Stripe](https://stripe.com) 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. +- **How to hire a CTO or build an engineering team.** Hiring is covered as a build-path decision (Lesson 4.1), not as an org-design course. - **How to raise venture capital.** The course produces the artifacts investors want to see. It does not teach pitch decks or fundraising mechanics. - **How to manage a 20-person engineering team.** Friday Demo Rule + Weekly Dev Report (in Going Further) 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. @@ -171,22 +171,28 @@ These conditional chapters kick in once you've passed the Module 5 gate. Read ea **Diagnose what's slowing growth** -- Customers leaving faster than you can replace them → [Churn Triage Before Acquisition](/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/) -- A key metric flat for 2+ months → [Pivot or Persevere](/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/) -- Hit the self-serve ceiling, time to hire your first engineer → [Hire Track Reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/) +| Trigger | Continuation chapter | +|---|---| +| Customers leaving faster than you can replace them | [Churn Triage Before Acquisition](/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/) | +| A key metric flat for 2+ months | [Pivot or Persevere](/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/) | +| Hit the self-serve ceiling, time to hire your first engineer | [Hire Track Reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/) | **Working with a dev agency in the AI era** -- Before the discovery call → ["We Use AI" Follow-Up Questions](/course/tech-for-non-technical-founders-2026/agency-uses-ai-follow-up-questions/) -- Surprise AI tokens on the invoice → [AI Token Bill](/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/) -- Worried about AI supply-chain risk in the code they ship → [Slopsquatting](/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/) +| Trigger | Continuation chapter | +|---|---| +| Before the discovery call | ["We Use AI" Follow-Up Questions](/course/tech-for-non-technical-founders-2026/agency-uses-ai-follow-up-questions/) | +| Surprise AI tokens on the invoice | [AI Token Bill](/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/) | +| Worried about AI supply-chain risk in the code they ship | [Slopsquatting](/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/) | **Manage a hired team without writing code** -- Need a structure for who reports to whom → [Engineering Org Chart](/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/) -- Want a weekly heartbeat to confirm something shipped → [Friday Demo Rule](/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/) -- Want a 3-question standup that catches problems early → [Three Standup Questions](/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/) -- Need a plain-English weekly report from the team → [Weekly Dev Report](/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/) +| Trigger | Continuation chapter | +|---|---| +| Need a structure for who reports to whom | [Engineering Org Chart](/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/) | +| Want a weekly heartbeat to confirm something shipped | [Friday Demo Rule](/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/) | +| Want a 3-question standup that catches problems early | [Three Standup Questions](/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/) | +| Need a plain-English weekly report from the team | [Weekly Dev Report](/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/) | ## Already started building? 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 index 41794c6b1..3b4ccf5d7 100644 --- 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 @@ -24,17 +24,13 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 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 +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. 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. +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. Three failed questions is a walkaway. -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. +Two failures hide behind the "AI-native" pitch, and both cost real money. The first is where the AI-written code lands. An agency moving fast with Cursor commits secrets straight into the repo - an OpenAI API key, a Stripe live key, a database password sitting in plaintext at line 14 of `config/database.yml`, on a GitHub repo that defaults to public. The second is the token bill. An agency that never priced its own AI usage runs up charges it cannot attribute - **$4,800 of OpenAI spend in 30 days** with no project tags and no per-developer breakdown, quietly passed through on top of the $34K four-week MVP. The five questions below surface both inside the first 20 minutes of a discovery call, before you sign. 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. @@ -48,6 +44,10 @@ If the agency declines to answer in advance, that is a 0 on every question. Exer ## The five questions +Keep this card open during the call - the pass signal sits beside the fail signal for each question, with a box to score 0 or 1 in real time. The full criteria for each are in the sections below. + +![The five agency AI questions on one card - the pass signal beside the fail signal for each, with a box to score 0 or 1 in real time](scorecard-at-a-glance.svg) + ### 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." @@ -62,7 +62,7 @@ If the agency declines to answer in advance, that is a 0 on every question. Exer > "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. +**Pass:** A per-developer dollar range ($80 to $300 per month in Anthropic and OpenAI API usage on top of the $20-40 Cursor seat; undisciplined agent-loop users can hit $500 - the [AI Token Bill lesson](/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/) has the full bands), 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. @@ -82,7 +82,7 @@ If the agency declines to answer in advance, that is a 0 on every question. Exer *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?" +> "In March 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/). @@ -109,7 +109,7 @@ The AI-theatre pattern: the salesperson takes every question. Answers come back 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." +> Good: "Open PR #1247 - Marcos 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 diff --git a/content/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/scorecard-at-a-glance.svg b/content/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/scorecard-at-a-glance.svg new file mode 100644 index 000000000..dd39bbedd --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/scorecard-at-a-glance.svg @@ -0,0 +1,66 @@ + + The five agency AI questions on one card: the pass signal beside the fail signal for each, scored 0 or 1 + + + + + Score the call from this card + Give 1 point when the answer lands on the Pass side, 0 when it lands on Fail. Full criteria below. + + + + + + + Question + PASS = 1 point + FAIL = 0 points + + + + + Q1 + Workflow: ticket to code + Tools by version + a real PR + “Senior decides,” no PR + + + + Q2 + Cost: $/dev/mo, who pays + $ range + pass-through in SOW + “Included in the rate” + + + + Q3 + Verify: reviewer checks + Opens real PR, names checks + “We trust the model / CI” + + + + Q4 + Slopsquatting defense + Allowlist/scanner + says word + “Our devs know packages” + + + + Q5 + Accountability: owned it + Dated incident + root cause + “Never had one” / not my job + + + Score in real time. A total of 2 or below out of 5 - do not sign, no matter how good the pitch. + 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 index f6de52d91..1c45c8fe9 100644 --- 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 @@ -40,9 +40,7 @@ course_nav: false 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. +Ask the senior engineer on that call to open one such PR on screenshare, and the deck meets the repo. A team that ships the footer opens a real PR in seconds. One that only added the line to the deck the week before scrolls GitHub for forty seconds, then offers to email the link "by end of day" - and the link never arrives. The claim lives in the pitch deck; no commit in the repo carries it. At $14,200 a week, that gap is a $56,800 four-week commitment resting on a delivery practice that does not exist. The five questions below surface it inside the first 20 minutes, before any contract conversation. ### The 5-question scorecard at a glance @@ -51,7 +49,7 @@ 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" | +| Q2 | **Cost:** per-developer monthly AI token spend, who pays | Dollar range, pass-through written into the SOW (statement of work), 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" | @@ -72,7 +70,7 @@ The full Pass/Fail rubric, scoring template, and "what to send 24 hours before t ### 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." +> **Q1** - "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. @@ -80,7 +78,7 @@ The agencies running theatre answer in slogans. The Q3 2026 founder above never ### 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?" +> **Q2** - "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. @@ -90,7 +88,7 @@ The [agency-ai-five-questions script](/course/tech-for-non-technical-founders-20 ### 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." +> **Q3** - "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. @@ -100,17 +98,17 @@ Ask which human's name shows up on the agency's `Assisted-by:` lines this week. ### 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?" +> **Q4** - "In March 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/). +They use the word "slopsquatting" without you prompting and can 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/). 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." +> **Q5** - "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. @@ -134,23 +132,14 @@ The agency runs AI theatre. Send a "we are pausing the search to refine our requ ### 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 full Pass/Fail rubric, scorecard, and theatre-vs-direction examples live in [the 5-Question Script](/course/tech-for-non-technical-founders-2026/agency-ai-five-questions/) - print that page. ## 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'}}}%% +%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, Comic Sans MS, 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"] @@ -161,10 +150,12 @@ flowchart TD 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 cond fill:#fffbeb,stroke:#d97706,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 D pass + class E cond class F fail ``` @@ -182,7 +173,7 @@ Three concrete moves for the next 24 hours, in order. - Veracode, [2025 GenAI Code Security Report](https://www.veracode.com/blog/genai-code-security-report/) - 45% of tested LLM-generated code samples carried 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). +- Infosecurity Magazine, [AI Hallucinations Open New Slopsquatting Attack Vector](https://www.infosecurity-magazine.com/news/ai-hallucinations-slopsquatting/) - 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. 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 index b5c2afe7a..48cbd2979 100644 --- 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 @@ -1,7 +1,7 @@ --- 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." +description: "Lesson 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 Lesson 2.1 before booking real interviews." date: 2026-05-18 draft: false course_chapter: true @@ -24,73 +24,35 @@ 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" + og_description: "Lesson 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 Lesson 2.1 before booking real interviews." +cover_image_alt: "JetThoughts cover for Lesson 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 · Lesson 2.2 · [OPTIONAL]** · [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) + your `[customer]` blank from the Ch 1.1 hypothesis (the role, company size, and situation it names - that description is your ICP, your Ideal Customer Profile) +> **Input:** your draft Mom Test question list (5-8 questions from Lesson 2.1) + your `[customer]` blank from the Lesson 1.1 hypothesis (the role, company size, and situation it names - that description is your ICP, your Ideal Customer Profile) > -> **Output:** a sharpened question list (5-7 solid questions) + top 3 objections, ready to take into Ch 2.3-2.4 recruitment and real interviews +> **Output:** a sharpened question list (5-7 solid questions) + top 3 objections, ready to take into Lesson 2.3-2.4 recruitment and real interviews > -> **Progress:** M2 · 2 of 6 · Results so far: draft question list · Interviewed customers before? Skip straight to [Ch 2.3: Find 10 People](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) - 2.1 is the core +> **Progress:** M2 · 2 of 6 · Results so far: draft question list · Interviewed customers before? Skip straight to [Lesson 2.3: Find 10 People](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) - 2.1 is the core > > **Cost:** $0 (free tier on Claude or ChatGPT) -> **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 quietly burns 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. +You drafted 5-8 Mom Test questions in Lesson 2.1. Before you spend one of your ~10 scarce interview slots on a question like "Would you use a tool like this?" - which generates a polite "sounds great" from anyone and teaches you nothing - run the list past a Claude persona that matches your ICP. A free rehearsal catches the broken question at your desk instead of on call 5 of 10. After this lesson you will be able to: **spot and repair pitch-shaped questions before they cost you a real interview slot.** -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-2.4 (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 can save you several 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
    + your customer blank from Ch 1.1"]) - 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"]) +The pattern: rehearsal tells you whether the question is broken; real interviews tell you whether the hypothesis is right. There's a second reason to rehearse - interviewing is a skill you build by doing it and getting feedback, not by reading about it. Teresa Torres' teams practice with mock interviews and a feedback loop before the questions ever reach a real customer; the clumsy run is where the learning happens ([Product Talk](https://www.producttalk.org/learning-to-interview-continuously/)). A Claude persona gives you that same loop without spending a real interviewee on a question you could have caught first. - 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. +![The rehearsal flow at a glance: bring in your draft question list plus the Lesson 1.1 customer blank, run Prompts 1-2 to build 3 ICP personas and test each question in-character, Prompt 3 for Claude's out-of-character diagnosis, Prompts 4-5 to surface 3 objections and sharpen weak questions past-anchored, and leave with 5-7 sharpened questions plus an Objection Tracker for real interviews](rehearsal-loop.svg) ## 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. +You don't need a sophisticated setup. Describe the person you're trying to interview in terms Claude can work with, 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. ### Prompt 1 - Persona Setup @@ -111,157 +73,51 @@ Stay in character for this entire conversation. Do not break character to explai | 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]` | Your Ch 1.1 `[customer]` blank - the company size and situation it names | -| `[PROBLEM DESCRIPTION]` | Founding Hypothesis `[problem]` blank (Ch 1.1) | +| `[ROLE]` | Founding Hypothesis `[customer]` blank (Lesson 1.1) - e.g. "solo chiropractor managing insurance claims" | +| `[INDUSTRY]` + `[COMPANY SIZE]` | Your Lesson 1.1 `[customer]` blank - the company size and situation it names | +| `[PROBLEM DESCRIPTION]` | Founding Hypothesis `[problem]` blank (Lesson 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) | +| `[YOUR DRAFT QUESTION 1]`, `2`, `3`, ... | Pick one question at a time from your Lesson 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 deep-research prompt on the [full sprint reference](/course/tech-for-non-technical-founders-2026/reference/hypothesis-sprint-full/) linked from Ch 1.1 - 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-2.4 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. +| `[PERSONA NAME]`, `[FREQUENCY]`, `[DURATION]`, `[BUDGET RANGE]`, `[REASON]` | Your judgment, anchored to deep-research findings if you ran the deep-research prompt on the [full sprint reference](/course/tech-for-non-technical-founders-2026/reference/hypothesis-sprint-full/) linked from Lesson 1.1 - see fallback below | -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). +> **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 Lesson 2.3-2.4 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 Lesson 1.1 hypothesis is not specific enough - tighten it before rehearsing. -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? -``` +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 might be: one at a 10-person seed startup, one at a 60-person Series A, one at a 200-person growth-stage company. Each has different objections, workarounds, and reasons to care. A question that works cleanly on one and collapses on another tells you something before you spend real calendar slots finding out. -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. +## Run the rehearsal -### Prompt 5 - Sharpening +Once the persona is set, run your draft questions through four follow-up prompts (the full text of each is in the [persona-rehearsal reference](/course/tech-for-non-technical-founders-2026/reference/persona-rehearsal-full/)): -```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. -``` +1. **Prompt 2 - Ask** each draft question in-character. The persona answers as a busy professional would. +2. **Prompt 3 - Diagnose:** tell Claude to break character and assess whether that question would produce useful data on a real call. Read the diagnosis, not the polite in-character answer - Claude is trained to be helpful, so a coherent answer is not proof the question works. +3. **Prompt 4 - Surface objections:** ask what would make the persona want to end the call or feel pitched. This gives you 3 objections to listen for in real interviews. +4. **Prompt 5 - Sharpen:** rewrite every vague question as a past-anchored version under 20 words. Run all three personas against the same list before you judge any single question. -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. +**Success check:** you end with 5-7 solid questions (down from 5-8 loose ones) and a top-3 objection list - the two deliverables you carry into [booking real interviews](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/). --- -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 5-8 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. Hearing an objection in rehearsal also does something quieter: when a real person raises it, you've already sat with it, so you take notes instead of getting defensive and pitching to win them back. 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 (and which personas raised it) | What phrasing to listen for | Heard 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 | +**If this fails: all 3 personas produce nearly-identical answers.** +- **Why:** your persona descriptions are too generic - three variations of the same person, not three different people. +- **Fix:** rewrite them with sharper role, company-size, and urgency differences. If you can't write three distinct personas at all, go back to [Lesson 1.1](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) and tighten the `[customer]` blank first. -**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 your next round of interviews | A rehearsal pass between rounds surfaces question gaps before you spend new slots on them | -| **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. If you notice you're struggling to write three distinct personas at all, that's a signal worth acting on: go back to [Ch 1.1](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) and tighten the [customer] blank before rehearsing questions against a customer you can't describe. - -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. - -> **What this AI rehearsal can and cannot do for you.** -> -> **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-2.4 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) (free tier to start) - it runs your hypothesis through several frontier models 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 several 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 +Look at the one question every persona answered cleanly. Would a real stranger with no stake answer it the same easy way? If yes, it's probably still hypothetical - sharpen it before you book a single call. -- 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) - 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:** you have a sharpened question list (5-7 solid questions) and an Objection Tracker with the top 3 objections to listen for. > -> **You have now:** a question list rehearsed against pushback (2.2) on top of your 2.1 draft. +> **You have now:** a question list rehearsed against pushback (2.2) on top of your 2.1 draft. The rehearsal proved the questions are ready - it did NOT validate the hypothesis; only the 10 real interviews do that. +> +> **Next:** [2.3 · Find 10 People: Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) - build the 30-name list, then [2.4 · What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) sends the messages using the sharpened list you just built. > -> **Next:** [2.3 · 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.4 · What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) sends the messages. +> **If blocked:** see "If this fails" above. > -> **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. +> **Deeper reference:** [The four full rehearsal prompts, the keep/revise/cut rubric, and the Objection Tracker](/course/tech-for-non-technical-founders-2026/reference/persona-rehearsal-full/) --- diff --git a/content/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/rehearsal-loop.svg b/content/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/rehearsal-loop.svg new file mode 100644 index 000000000..2556b52e7 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/rehearsal-loop.svg @@ -0,0 +1,93 @@ + + The rehearsal flow at a glance: bring in your draft Mom Test question list plus the customer blank from Lesson 1.1. Prompts 1-2 build 3 ICP personas and test each draft question in-character. Prompt 3 gets Claude's out-of-character diagnosis of each question. Prompts 4-5 surface 3 likely objections and sharpen the weak questions to be past-anchored. You leave with 5-7 sharpened questions plus an Objection Tracker, ready for real interviews. + A left-to-right strip of five cards joined by arrows: an input card, three numbered prompt-step cards, and an output card. Input: your draft question list plus the customer blank. Step 1 (Prompts 1-2): build 3 ICP personas, test each draft question in-character. Step 2 (Prompt 3): get Claude's out-of-character diagnosis. Step 3 (Prompts 4-5): surface 3 objections and sharpen weak questions past-anchored. Output: 5-7 sharpened questions plus an Objection Tracker, into real interviews. + + + + + + + + + The rehearsal flow at a glance + Sharpen the question list with 3 free Claude prompts before booking real interviews. + + + + + INPUT + Draft question + list (5-8) + + customer blank + (Lesson 1.1) + + + + + + + 1 + PROMPTS 1-2 + Build 3 personas + Test each draft + question + in-character + + + + + + + 2 + PROMPT 3 + Diagnose + Claude's out-of- + character read + on each Q + + + + + + + 3 + PROMPTS 4-5 + Objections + fix + Surface 3 objections. + Rewrite weak Qs + past-anchored + + + + + + OUTPUT + 5-7 sharpened Qs + + Objection + Tracker + → real interviews + + + + + + + + + + The in-character answer is plausible by default - the out-of-character diagnosis is where you learn. + 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 index ce5fd0f98..93964f7e5 100644 --- 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 @@ -35,7 +35,7 @@ course_nav: false > > **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 +> **Output:** monthly AI cost predicted within ±20% + 3 contract clauses you add to the next SOW (statement of work) **Supplementary content.** This chapter is relevant after you've shipped (Module 4+) and your product touches AI in production. Bookmark and return when needed. @@ -47,7 +47,7 @@ That is the gap this post closes. By the end of one coffee you will know the per | 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 | +| Cursor or Copilot Enterprise seat | $20-40 | 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 | @@ -97,7 +97,7 @@ Take your invoice in three numbers. - 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 +- If invoice shows $1,800: undisciplined developer (like Devon in the invoice table below), 30% hidden margin, or both - 15-minute conversation either way **Worked example - 2-dev team with one heavy agent-loop user:** @@ -113,21 +113,7 @@ The trade-off you are accepting: ±20% is a wide band. AI usage is genuinely var 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 -%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%% -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 -``` +![The month-2 invoice loop: sign the SOW with the 3 clauses, predict the bill (devs x avg AI cost x margin), compare the invoice. Within plus-or-minus 20 percent: pay it and mark the baseline. 20 percent or more over: demand the itemized breakdown - a hard ticket raises the budget alert, margin or padding gets pushed back under Clause 1. Quarterly, review the dashboards under Clause 3 and re-predict.](invoice-loop.svg) ### Clause 1 - Pass-through caps diff --git a/content/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/invoice-loop.svg b/content/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/invoice-loop.svg new file mode 100644 index 000000000..01d066d69 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/ai-token-bill-dev-shop-pass-through-cost/invoice-loop.svg @@ -0,0 +1,93 @@ + + The month-2 invoice loop: sign the SOW with the 3 clauses, predict the bill, compare the invoice. Within plus-or-minus 20 percent, pay it and mark the baseline. 20 percent or more over, demand the itemized breakdown - a hard ticket updates the budget alert, margin or padding gets pushed back citing Clause 1. Quarterly, review the dashboards under Clause 3. + Three numbered step cards in a row: sign the SOW, predict the bill with the formula devs times average times margin, month-2 invoice arrives. The invoice card forks into two outcome cards: a green card for within 20 percent - pay it, mark it the baseline - and an amber card for 20 percent or more over - demand the itemized breakdown, with two inner lines: a check for a hard ticket that updates the budget alert, and a cross for margin or padding that gets pushed back under Clause 1. A dashed loop arrow returns to the predict step with the caption: quarterly, review the dashboards under Clause 3. + + + + + + + + + + + + The month-2 invoice loop + Predict the bill first - then the invoice is a comparison, not a surprise. + + + + + + 1 + Sign the SOW + with the 3 clauses below + + + + + + + 2 + Predict the bill + devs × avg AI cost × margin + + + + + + + 3 + The invoice lands + compare it to the prediction + + + + + + + + + + + + + + Within ±20% of the prediction + Pay it. Mark it as the baseline + for every month after. + + + + + + 20%+ over: demand the breakdown + ✓ One dev hit a hard ticket → raise the + budget alert and carry on. + ✗ Margin or padding → push back, cite Clause 1. + + + + + Quarterly: open the usage dashboards yourself (Clause 3), then re-predict next month's bill. + diff --git a/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/build-path-decision-worksheet.pdf b/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/build-path-decision-worksheet.pdf index 4a1ef50f6..a0ea01492 100644 Binary files a/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/build-path-decision-worksheet.pdf and b/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/build-path-decision-worksheet.pdf 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 index b79d23a39..b16eac193 100644 --- 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 @@ -24,9 +24,7 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 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 +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. *Print one side of paper. Pen. 30 minutes alone. Walk out with a defensible build decision and the next module to read.* @@ -34,13 +32,15 @@ related_posts: false ## Why this exists -A wellness-coaching founder who came to us in early 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. +A wellness-coaching founder 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. + +*Illustrative composite based on patterns from real founder builds, not a single client story.* -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. +Run the same 5 questions on this worksheet against her situation and the matrix lands on Path 3 (Fractional CTO at $2,400/mo, 8 hours/week), not Path 4 (the agency at $24K/mo) - a decision already sitting in the validation 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.5, 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. +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 Lesson 2.5, your filled-in [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) from Lesson 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 Mom Test interviews" is a count on your call log, 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. @@ -50,170 +50,82 @@ Total time budget: 30 minutes alone, 20 minutes with one peer, 0 minutes second- ## 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: ________________________ -``` +
    +
    FounderDate
    +
    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 4 below are true: - [ ] 10 or more Mom Test interviews complete - [ ] Strong past-behavior signal in at least 7 of 10 - [ ] Smoke test cleared the 6%+ "Promising" band - - the share of visitors who left their email on - your test page (Module 1, Chapter 1.4) - [ ] Prototype test: 4 of 5 people reached the right - screen without you coaching them (from Module 2) - -LinkedIn likes do not count. "They said they would -buy" does not count. What people DID counts - the -sign-ups on the smoke test and the prototype run, not -what they said they would do. Pre-orders and paid -pilots come later (Module 5); you do not need them -to answer YES here. - -VERDICT: [ ] Yes [ ] No - -If NO -> stop here. Path 1 (Validate without code). - Run the Airbnb test this week. - -If YES -> go to Q2. -``` +
    +

    Counts as YES only if all 4 below are true:

    +
      +
    • 10 or more Mom Test interviews complete
      • +
    • Strong past-behavior signal in at least 7 of 10
      • +
    • Smoke test cleared the 6%+ "Promising" band - the share of visitors who left their email on your test page (Module 1, Lesson 1.4)
      • +
    • Prototype test: 4 of 5 people reached the right screen without you coaching them (from Module 2)
      • +
    +

    LinkedIn likes do not count. "They said they would buy" does not count. What people DID counts - the sign-ups on the smoke test and the prototype run, not what they said they would do. Pre-orders and paid pilots come later (Module 5); you do not need them to answer YES here.

    +
    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: - [ ] Live updates that appear on screen without - anyone refreshing the page (like watching - someone type in Google Docs or Slack) - [ ] Heavy jobs that run in the background and keep - retrying if they fail (mass emails, big uploads) - [ ] An AI model runs every time someone uses the - feature, and each run costs real money (more - than a cent per use) - [ ] Many separate companies use the same app and - none can ever see another company's data - [ ] The app connects to 5 or more outside services - (payments, email, maps, calendars, and so on) - [ ] Regulated data - health records (HIPAA), stored - credit-card numbers (PCI), or enterprise - security audits (SOC 2) - -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 the hire-track - supplementary reference, linked in the - verdict table below). - Read the SOW guide before kickoff. - -If LIGHT or MID -> go to Q3. -``` +
    +

    Check every TRUE row:

    +
      +
    • Live updates that appear on screen without anyone refreshing the page (like watching someone type in Google Docs or Slack)
      • +
    • Heavy jobs that run in the background and keep retrying if they fail (mass emails, big uploads)
      • +
    • An AI model runs every time someone uses the feature, and each run costs real money (more than a cent per use)
      • +
    • Many separate companies use the same app and none can ever see another company's data
      • +
    • The app connects to 5 or more outside services (payments, email, maps, calendars, and so on)
      • +
    • Regulated data - health records (HIPAA), stored credit-card numbers (PCI), or enterprise security audits (SOC 2)
      • +
    +
    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 the hire-track supplementary reference, linked in the verdict table below). 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 / Ch 4.3 then 4.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 the hire-track - supplementary reference, linked in the - verdict table below). -``` - -### 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 / Ch 4.3 then 4.4). - Use them for the monthly architecture call - + worst-route code review. - -If NO -> Path 3 (Fractional CTO bridge - see the - hire-track supplementary reference). - Buy the same insurance commercially. - -====================================================== -THE 4-PATH VERDICT (write your row at the top of -your Notion doc) -====================================================== -``` +
    +

    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: 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 / Lesson 4.3 then 4.4), at any budget. Use them for the monthly architecture call + worst-route code review.
    +
    If NO → go to Q5.
    +
    + +### Q5: 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 / Lesson 4.3 then 4.4). Paste one-page brief into Lovable, and line up a senior review before you scale.
    +
    If $1.6K-$4K or $5K-$30K → Path 3 (Fractional CTO bridge - see the hire-track supplementary reference). Buy the architecture insurance commercially.
    +
    If $30K+ → Path 4 (Hire a team - see the hire-track supplementary reference, linked in the verdict table below).
    +
    ## 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 your 30-name outreach list. | $0 - $300 in tools + optional $100-200 in paid ads | -| **2. Self-serve build** ([Ch 4.3](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) then [4.4](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/)) | Q1 yes, Q2 light or mid, and either Q4 = $0-$400/wk of your own time, or Q4 = $1.6K-$4K/mo with a senior engineer in your network (Q5 yes) | Paste one-page brief into Lovable. Hook Supabase + Stripe + Resend. | $200 - $1,200 / month | -| **3. Fractional CTO bridge** ([hire-track reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge)) | Q1 yes, Q2 light or mid, and either Q4 = $1.6K-$4K/mo with no senior engineer (Q5 no), or Q4 = $5K-$30K/mo | Hire 5-10 hrs/wk Fractional CTO. Use for architecture, PR review, hiring, cost watch. | $1,600 - $4,000 / month | -| **4. Hire a team** ([hire-track reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/)) | Q2 heavy (any budget), or Q4 = $30K+/mo | Read draft SOW clause-by-clause. Confirm GitHub/AWS/domain ownership before kickoff. | $30K - $80K / month | +| **2. Self-serve build** ([Lesson 4.3](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) then [4.4](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/)) | Q1 yes, Q2 light or mid, and a senior engineer in your network (Q4 yes) at any budget - or Q5 = $0-$400/wk of your own time | Paste one-page brief into Lovable. Hook Supabase + Stripe + Resend. | $200 - $1,200 / month | +| **3. Fractional CTO bridge** ([hire-track reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge)) | Q1 yes, Q2 light or mid, no senior engineer (Q4 no), and Q5 = $1.6K-$4K or $5K-$30K/mo | Hire 5-10 hrs/wk Fractional CTO. Use for architecture, PR review, hiring, cost watch. | $1,600 - $4,000 / month | +| **4. Hire a team** ([hire-track reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/)) | Q2 heavy (any budget), or Q5 = $30K+/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 30 click. Pivot the pitch or the problem. @@ -231,25 +143,25 @@ your Notion doc) The good answer is countable: 12 calls, 9 strong signals, an 8% smoke-test sign-up rate, 4 of 5 testers through the prototype. The bad answer is a vibe metric (likes) and a hypothetical (love the idea). Likes are not behavior. 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** +**Q4 - Senior engineer in your network** -> Bad: *"We have $400K in the bank and we will spend whatever it takes to ship."* +> Bad: *"Yes, my college roommate is a software engineer at Google."* -> 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."* +> 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 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. +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. -**Q5 - Senior engineer in your network** +**Q5 - Monthly engineering budget** -> Bad: *"Yes, my college roommate is a software engineer at Google."* +> Bad: *"We have $400K in the bank and we will spend whatever it takes to ship."* -> 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."* +> 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 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. +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. ## What to do after -- **Write your verdict at the top of a fresh Notion doc.** One line: *"Path X (name). Started: [date]. Next: [Ch 4.3 self-serve / hire-track reference / back to Module 2 to re-validate]."* Pin the doc. Re-read the line every Monday for 4 weeks. +- **Write your verdict at the top of a fresh Notion doc.** One line: *"Path X (name). Started: [date]. Next: [Lesson 4.3 self-serve / hire-track reference / back to Module 2 to re-validate]."* 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. diff --git a/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/channel-decision.svg b/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/channel-decision.svg new file mode 100644 index 000000000..f6d09ac95 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/channel-decision.svg @@ -0,0 +1,49 @@ + + Pick one channel from interview evidence, score it out of 12, then commit to one full send-reply-follow-up arc before switching + + + + + + + + Pick one channel - then commit to it + + + + 10 interview + transcripts + from Module 2 + + + + + + + Score each channel 1-3 + Price / Buyer / Time / Signal + = your total / 12 + + + + + + + 9+ / 12 - commit to it + + + 7-8 / 12 - pilot your top 2 + + + 6 or less - re-read transcripts + + + + Then run ONE full send / reply / follow-up arc before you switch channels. + Reply rate over 5% and demos turning into paid chats - keep going. All flat - fix the script first. + 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 index 05b3819fb..882c2e018 100644 --- 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 @@ -25,14 +25,14 @@ 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" +cover_image_alt: "JetThoughts blog cover for Lesson 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 · Lesson 5.2 · [OPTIONAL] - skip if you already know your channel** · [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.4) + the ICP (Ideal Customer Profile - the specific kind of person your hypothesis names; introduced in Ch 1.1) you sharpened across Modules 1-2 +> **Input:** 10 Mom Test interview transcripts from Module 2 + your live MVP from Module 4 (Lesson 4.4) + the ICP (Ideal Customer Profile - the specific kind of person your hypothesis names; introduced in Lesson 1.1) you sharpened across Modules 1-2 > > **Output:** one channel hypothesis committed long enough to read the signal > @@ -40,83 +40,36 @@ related_posts: false > **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 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 a smarter channel - it's committing to one from your interview evidence through a full send/reply/follow-up arc. -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. +After this lesson you will be able to: **pick one outreach channel from your interview evidence and write a commitment statement you'll hold before scaling.** -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.5](/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. +![Pick one channel from your interview transcripts, score each candidate out of 12, then commit to one full send-reply-follow-up arc before you switch](channel-decision.svg) -## The 4 channels for newbie B2B and B2C +## Commit before you read the signal -At this stage you are choosing from four options. Here is what each one actually requires: +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 still before the "not now" replies reveal whether non-replies are disinterest or bad timing. Run a batch, call the channel dead on 2 quick replies, and you threw away the signal. -| 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 free tier); 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) (free tier available) | Open rate (share of recipients who open your email) <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 | +Your 10 interview transcripts from [Module 2](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) already name the channel. Your interviewees told you how they find tools like yours - they just did not use the word "channel." Pull them up and look for how they discover tools ("Slack group," "Google search," "network referral"), which channel they first came to you through, and what tools they use every day. -Pick the one that matches your buyer type, your price point, and your honest time budget - then commit. +## Score and pick -> **A fifth play: Engineering as Marketing - a slower-burn, zero-CAC (Customer Acquisition Cost - what you spend to land one customer) option, not one of the four channels you score above.** 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. +Score each candidate channel 1-3 on four dimensions - price fit, buyer type, your honest time budget, and interview signal - for a total out of 12. **≥9/12 = commit to that channel.** 7-8/12 = run a 1-week pilot on your top two to break the tie; the higher reply rate wins. ≤6/12 = no channel fits yet; re-read your transcripts for missing signal before scaling outbound at all. The full scoring rubric and the 4-channel comparison (LinkedIn, cold email, community, social) live in the [deeper reference](/course/tech-for-non-technical-founders-2026/reference/channel-selection-full/). -## AI-augmented channel research +## Pressure-test with AI first -After you pull the signal from your transcripts, run one Claude prompt to pressure-test your hypothesis before you commit to it: +After you pull the signal from your transcripts, run one [Claude](https://claude.ai) 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]. +I am a founder building [paste your one-sentence Founding Hypothesis from Lesson 1.1]. +My must-have user is [customer] (your Lesson 5.1 must-have segment - 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] +- [customer quote] from your Lesson 2.5 transcripts +- [customer quote] from your Lesson 2.5 transcripts - [... up to 5 signals] I am considering [channel A] vs [channel B] for my first stretch of outbound. @@ -124,125 +77,35 @@ 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. +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. If your interview evidence points one way (8 of 10 saying "I found it on LinkedIn") while your gut points another (cold email feels safer), name the gap to yourself: which signal are you ignoring, and why? -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? +> **What the prompt can and cannot tell you.** It pressure-tests your hypothesis against interview evidence, surfaces the assumptions behind each choice, and flags contradictions between your transcripts and your gut. It cannot tell you which channel will actually convert, your real reply rate, or whether the channel degrades over time - only a real send/reply/follow-up arc can. **The real gate:** ≥9/12 channel-fit score + a full arc with reply rate >5%. -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-2.4 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. +--- -> **What the Claude prompt above can and cannot tell you.** -> -> The prompt in the section above is your channel-choice pressure-test. 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. +> **Do this now:** > -> **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%. -> -## 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. +> 1. Open your 10 interview transcripts. Mark every channel signal (how they discover tools, where they came from, daily tools). +> 2. Score each candidate channel 1-3 on the four dimensions. Total each out of 12. +> 3. Run the Claude prompt against your transcripts to pressure-test your top pick. +> 4. Write the channel name + your commitment statement (why + evaluation criteria) in a [Notion](https://www.notion.so) doc. The clock starts the day you send your first outbound message. +> 5. **Success check:** one channel scored ≥9/12, one written commitment statement, and you will not switch until you have run a full send/reply/follow-up arc. --- -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. +**If this fails: no channel scores ≥9/12.** +- **Why:** your interview transcripts are missing channel signal. +- **Fix:** re-read them for "how do you find tools like this" and "what tools do you use every day" - the answers are usually already in there. If they truly are not, [Lesson 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) works your personal network first, where the channel is simply "people who already know you." -The first place to apply this is your personal network in [Chapter 5.3 (Build Your 50-Name Network List)](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/). 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 - Build Your 50-Name Network List](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) before your first send - that's the playbook for getting the first conversations on the channel you just picked. +--- -Pick the channel your interviews already named, commit to it long enough to read the signal, and stop running pilots against your own attention. +The decision matters more than the channel itself. Committing to one channel and iterating on the script beats splitting your time across three, because the learning loop is tighter. With 30 focused messages you get a reply rate you can diagnose; with 10 spread across three channels you get nothing to act on. -## Further reading +The first place to apply this is your personal network in [Lesson 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/). Once that is exhausted, [going outbound without a sales team](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/) covers running the channel you just chose: the filter, the script, the Calendly-to-Stripe pipeline, and what the reply rate actually means. -- 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. -- Lenny Rachitsky, [How the biggest consumer apps got their first 1,000 users](https://www.lennysnewsletter.com/p/how-the-biggest-consumer-apps-got) - 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. +> **Deeper reference:** [The full channel-selection walkthrough and worksheet](/course/tech-for-non-technical-founders-2026/reference/channel-selection-full/) - the commitment-rule phase table, reading signals from transcripts, the 4-dimension scoring, the 4-channel comparison, the Engineering-as-Marketing side door, and the fill-in worksheet. -> **Done:** your worksheet is filled, one channel is chosen, and you have written your commitment statement (channel name + why + evaluation criteria). +> **Done:** you scored your candidate channels, chose one at ≥9/12, and wrote your commitment statement (channel name + why + evaluation criteria). > > **You have now:** a committed channel (5.2) chosen from your interview evidence. The 50-name list to run it on is next. > 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 index 2a0ada195..27b206aee 100644 --- 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 @@ -25,14 +25,14 @@ metatags: image: cover.png og_title: "2.6 · 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.6 - hand-drawn three-screen clickable prototype with five user-test sessions and pass/fail signal markers" +cover_image_alt: "JetThoughts cover for Lesson 2.6 - 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 · Lesson 2.6 · [CORE]** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > -> **Input:** a BUILD decision plus your validated problem statement from [2.5](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/), and 5 of the 10 Mom Test interviewees (recruited in [2.3](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/), messaged in [2.4](/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) +> **Input:** a BUILD decision plus your validated problem statement from [2.5](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/), and 5 of the 10 Mom Test interviewees (recruited in [2.3](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/), messaged in [2.4](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/)) - pick the strongest-signal ones (scored per the Lesson 2.1 rubric) > > **Output:** 5 of them watched navigating a throwaway clickable prototype, with pass/fail per session > @@ -40,35 +40,23 @@ related_posts: false > **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-2.4:** [Ch 2.3-2.4](/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-2.4 validated THE PROBLEM; Ch 2.6 validates THE SOLUTION SHAPE. +> **How this lesson relates to Lesson 2.3-2.4:** [Lesson 2.3-2.4](/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 lesson takes 5 of those 10 (the ones who scored 7+) and re-engages them for a 30-minute 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. Lesson 2.3-2.4 validated THE PROBLEM; Lesson 2.6 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. +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. After this lesson you will be able to: **watch 5 real customers try to use your solution before it exists - and score what they do, not what they say.** -A founder we advised 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.3](/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. +One founder we advised ran 8 strong Mom Test interviews, then built a working app over several weeks - and when 5 interviewees logged in, several stalled on screen 2, unable to figure out which button to click next. Validating the problem had not validated whether the shape was navigable. A throwaway prototype in front of 5 subjects surfaces that in an afternoon. ([Full story](/course/tech-for-non-technical-founders-2026/reference/prototype-build-full/).) > **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. +> You 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.3](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) defines the stack, [Ch 4.4](/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 +> Polish this prototype into your MVP later and 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 ([Lesson 4.3](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) defines the stack, [Lesson 4.4](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/) walks the phases), started from the one-page brief (Lesson 3.1) with real auth, real Stripe, real domain. -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. +## What a prototype catches that interviews miss -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: +A Mom Test interview pulls the interviewee into the past. A prototype session puts them into a possible future and watches what they do. Three things break at the prototype stage that looked clean in interviews: | Failure | What happens | Why interviews miss it | |---|---|---| @@ -76,70 +64,18 @@ Three things break at the prototype stage that looked clean in interviews: | **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. +None of these show up in a Mom Test interview - they only appear the moment a real person touches the interface. The [full reference](/course/tech-for-non-technical-founders-2026/reference/prototype-build-full/) has the three-pillar theory (smoke test → Mom Test → prototype) in depth. -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 -## 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 available, 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: **Screen 1** is the entry point (one dominant action), **Screen 2** is the core action (where value is delivered - and where users stall if the vocabulary is wrong), **Screen 3** is the confirmation or result. -[Lovable](https://lovable.dev) is an AI app builder that generates a working web app from a prompt. Free trial available. 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. - -![Wireframe of a passing 3-screen prototype: Screen 1 entry point with a fake file list and a Match transactions button, Screen 2 core action showing a Stripe-vs-QuickBooks match table where testers stall, and Screen 3 result with a summary card and Download report - the screen a passing tester reaches without coaching](wireframe-strip.svg) - -> **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 lift the cap - check Lovable's pricing page.** They only become worth it if you later need higher message volume - not required for this chapter. -> -> If you hit the daily message cap mid-build: 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 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. +> **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 lesson 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 Lesson 1.1) before continuing. Do NOT keep adding messages hoping to brute-force coherence. 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]. +Build a 3-screen clickable prototype for a [PRODUCT CATEGORY] tool targeting [customer]. 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. @@ -161,131 +97,25 @@ SCREEN 3 - [RESULT/CONFIRMATION NAME]: 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. +Where the blanks come from: `[customer]` is your `[customer]` blank from Lesson 1.1; `[PRIMARY ACTION ...]` is the top workaround-replacing action from your Lesson 2.5 validated problem statement; `[FAKE DATA EXAMPLE]` is names and numbers pulled from your interview transcripts. Use the vocabulary you heard in interviews, not the words you use with other founders - if 7 of 10 interviewees called it "matching" and you call it "reconciliation," the prototype uses "matching." -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." +![Build the 3-screen prototype in three moves: open Lovable and paste the prompt template with placeholders filled, read the fake data out loud and change the vocabulary to match the words you heard in interviews, then test all three screens yourself as if you've never seen the idea - leaving with a prototype ready to share as a link to 5 interviewees](prototype-build-strip.svg) -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 | +> **Deeper reference:** the [full build walkthrough](/course/tech-for-non-technical-founders-2026/reference/prototype-build-full/) has a filled-in worked example (a reconciliation tool for freelance bookkeepers), the Lovable free-tier onramp, and the screen-by-screen build detail. -### Setup - recruit and book +## Run a silent-observation session with 5 interviewees -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 for 30 minutes of a different kind of time: watching them use the interface, not answering your questions. +Choose 5 of the 10 interviewees whose Mom Test scores were 7 or higher. Book 30-minute video calls. Send the Lovable prototype link 10 minutes before each call - not earlier, so they don't explore it solo before you can observe. -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 Lesson 2.3-2.4 thread): -**The re-engagement message** (paste into LinkedIn DM or reply to your original Ch 2.3-2.4 thread): +> *"Hi [name] - thank you for the 30 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?"* -> *"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 - the *"I built something based on what you told me"* line signals you listened. During the session, stay silent and record behavior: write down the first buttons they reach for, note any pause over 5 seconds, and never answer their questions or coach them toward the right path. When they finish Screen 3, ask one question: "Describe in one sentence what that tool just did." Write down their exact words. -Expect 4-5 of 5 to say yes. They invested 40 minutes in the first call; the second ask is shorter and a different motion. The *"I built something based on what you told me"* line is what gets them to say yes - 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. +The [full reference](/course/tech-for-non-technical-founders-2026/reference/prototype-build-full/) has the verbatim opening script, the four closing questions, the async slow-path variant for part-time founders, and the three common fixable failures. -> **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 a handful of testers - check current limits) 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. Recordings surface less than live sessions do (you miss the "what were you about to click" follow-ups), and still far more 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.5](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/) - if you haven't run that test yet, the $49-$299 band from the [full price-test reference](/course/tech-for-non-technical-founders-2026/reference/stripe-price-test-full/) 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 +## Pass/fail scoring Score each session immediately after the call ends. Use three signals. @@ -295,98 +125,35 @@ Score each session immediately after the call ends. Use three signals. | 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. +A session is a **pass** only if all three signals are green. The prototype gate: -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/). +- **4 or 5 passes of 5:** Shape is legible. Advance to [Module 3 · One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/), using the "describe in one sentence" words from the closing questions. - **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. +- **0 or 1 pass:** The shape is wrong. Return to Lesson 2.1 before writing any brief - a shape mismatch usually means the interview signal was off. -**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. +Catching a shape mismatch here costs one throwaway prototype. Catching it in Module 4, after the real build has started, costs the real build. -**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.6, you have five artifacts. Each one feeds a specific downstream destination - this table is the map: - -| Artifact | Where it goes next | -|---|---| -| **Validated Problem Statement** (Ch 2.5 synthesis applied to your Ch 2.3-2.4 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-4.4 Lovable prompts. The user's words beat your marketing copy. | -| **10 raw transcripts** (Ch 2.3-2.4 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-2.4 step 2, Reddit/forum complaints) | Reference for Ch 3.1 Section 1 supplementary evidence + the bank for Ch 2.3-2.4 cold-message subject lines in any future round 2. | - -## Iterate or proceed? The combined Module-2 decision matrix - -Each signal has its own iteration guidance (Ch 2.5's build/pivot/kill call on the scored interviews, and the Ch 2.6 pass count above). The COMBINED decision uses both signals together: - -| Interview signal (Ch 2.5 synthesis) | Ch 2.6 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) | -| 4-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) | -| 4-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) | -| Under 4 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.5 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/). +> **If this fails:** the user cannot get past Screen 1 and asks what the product does before touching it. **Why:** Screen 1 has no instruction in the user's own words, or it has clutter competing with the primary CTA. **Fix:** add one line of microcopy above the CTA naming the action in the user's vocabulary, and remove everything on Screen 1 that is not the primary button. Test with one fresh session before advancing. ## What to do next | Step | Action | Output | |---|---|---| -| **1** | Open Lovable and paste this chapter's 3-screen prompt template with every `[PLACEHOLDER]` filled in. 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 | +| **1** | Open Lovable and paste this lesson's 3-screen prompt with every `[PLACEHOLDER]` filled in. Aim for a navigable prototype within ~10 exchanges; stop at 3 screens. | 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. -- Y Combinator, [How to Talk to Users (Startup Library)](https://www.ycombinator.com/library) - 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:** 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 · Module 2 bundle:** 10 scored Mom Test transcripts (from Ch 2.3 + 2.4) + the validated problem statement (Ch 2.5) + 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. > -> **You have now:** all Module 2 artifacts - scored interviews (2.1-2.4), the build/pivot/kill decision (2.5), and prototype feedback from 5 real customers (2.6). Module 2 closes here. +> **You have now:** all Module 2 artifacts - scored interviews (2.1-2.4), the build/pivot/kill decision (2.5), and prototype feedback from 5 real customers (2.6). Drop them all in your `Founder OS` folder; Lesson 3.1 reads the vocabulary into Section 3 of the brief. Module 2 closes here. > -> **Next:** [3.1 · The One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) +> **Next:** [3.1 · The One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) - reads your validated problem statement into Section 1 and your prototype vocabulary into Section 3. > -> **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.3), (3) 10 interview transcripts scored per the Ch 2.1 rubric (calls booked in Ch 2.4), (4) a one-page validated problem statement with build/pivot/kill verdict (Ch 2.5 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. +> **If blocked:** see "If this fails" above. If 0-1 of 5 sessions passed, the solution shape is wrong - read the "what did you expect to see" answers (that is the user's mental model) and return to Lesson 2.1 before writing the brief. +> +> **Deeper reference:** [Full prototype build, session script, and Module 2 decision matrix](/course/tech-for-non-technical-founders-2026/reference/prototype-build-full/) - the screen-by-screen build, the worked example, the verbatim session script, the combined interview + prototype decision matrix, and the artifacts map. --- diff --git a/content/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/prototype-build-strip.svg b/content/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/prototype-build-strip.svg new file mode 100644 index 000000000..15eb5c42f --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/prototype-build-strip.svg @@ -0,0 +1,77 @@ + + Building the 3-screen prototype in three moves: open Lovable and paste the prompt template with your placeholders filled in; read the fake data out loud and change the vocabulary to match the words you heard in interviews; test all three screens yourself as if you have never seen the idea. You leave with a prototype ready to share as a link to 5 interviewees. + A left-to-right strip of four cards joined by arrows: three numbered build-step cards and one output card. Step 1: open Lovable, paste the prompt template with placeholders filled. Step 2: read the fake data out loud, change vocabulary to match interview language. Step 3: test all 3 screens yourself as if new to the idea. Output: prototype ready, share the link to 5 interviewees. + + + + + + + + + Build the 3-screen prototype + Three moves in Lovable, then hand the link to 5 interviewees. + + + + + + 1 + Open Lovable + Paste the prompt + template with your + placeholders filled + + + + + + + 2 + Read it out loud + Change vocab to + match the words you + heard in interviews + + + + + + + 3 + Test it yourself + Click all 3 screens + as if you've never + seen your idea + + + + + + PROTOTYPE READY + Share the link + to 5 of your Mom + Test interviewees + + + + + + + + + The constraint is the test - stop at 3 screens; a 4th is the prototype turning into the MVP. + 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 index 4e82932d5..30f42ed7f 100644 --- 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 @@ -47,7 +47,9 @@ related_posts: false 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. +*Illustrative composite based on patterns from real founder builds, not a single client story.* + +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 (customer-acquisition cost - what you spend to win one customer) numbers for a $29/month SMB (small and mid-size business) 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. @@ -86,11 +88,11 @@ The cohort tool already groups users by signup week, so this is a matter of read 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. +R. ran this slice in 70 minutes flat. Her overall 30-day retention was 19%. Solid not-a-business numbers. Sliced by segment: 3-person teams 70%, 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. +Cohorts that finish day 30 above the 40% retention line are habitual, below it are novelty. (Sean Ellis's 40% is a different number - the survey very-disappointed share from [Lesson 5.1](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/); don't conflate the two.) | Cohort | Day 7 → Day 30 retention | Verdict | |---|---|---| @@ -110,24 +112,24 @@ The trade-off worth naming: a 90-minute cohort analysis on 32 users is direction 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'}}}%% +%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, Comic Sans MS, 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] + A[Cohort numbers from the 90-minute floor] --> B[Per-segment 30-day retention spread?] + B -->|All low| C[Decision 3 - KILL THE SKU
    All segments under 25%
    Sunset gracefully + pivot] + B -->|All medium| D[Decision 1 - FIX THE PRODUCT
    All segments 20-35%
    Rebuild one workflow] + B -->|One high| E[Decision 2 - CHANGE THE SEGMENT
    One over 50%, rest under 20%
    Refund the wrong half] C --> CK[Go to Pivot or Persevere
    in Going Further] - D --> DK[Go to the rescue chapters
    Going Further] + D --> DK[Read the Going Further chapters
    Going Further] 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; + classDef navbox fill:#faf7f2,stroke:#1a1a1a,stroke-width:2px; class C redbox class D yellowbox class E purplebox - class CK,DK,EK greenbox + class CK,DK,EK navbox ``` ### Decision 1 - FIX THE PRODUCT @@ -138,9 +140,9 @@ The fix is to stop adding features and rebuild one workflow until it actually wo ### 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. +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 - 70% 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.3 personal-network outreach](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) within the segment that retains. +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 [Lesson 5.3 personal-network outreach](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) 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. @@ -176,14 +178,14 @@ Here is the email template that worked for R.'s 18 wrong-segment customers. Send 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. +The honest trade-off: a refund-the-wrong-segment campaign cuts your customer count and your MRR (monthly recurring revenue - what your subscriptions bring in each month) 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 [hire-track supplementary reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge) for the salvage-vs-rebuild decision 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.3 - personal-network outreach](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) 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. +2. **If Decision 2 (CHANGE THE SEGMENT):** re-run [Lesson 5.3 - personal-network outreach](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) 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 [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 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 index a736103d8..335266436 100644 --- 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 @@ -32,15 +32,17 @@ course_nav: false > **Going Further · Manage a Hired Team** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > -> **Input:** a team in place + a signed SOW +> **Input:** a team in place + a signed SOW (statement of work) > > **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. +**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. + +Marina, a FinTech founder I worked with 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. + +*Illustrative composite based on patterns from real founder builds, not a single client story.* 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. @@ -93,7 +95,7 @@ Ask flat. Watch the pause. [DataToBiz describes the practice plainly](https://ww ### 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. +A shop with a real on-call rotation can tell you the schedule, the escalation path, and the SLA (service-level agreement - the response time they committed to) 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?" @@ -118,7 +120,7 @@ Run the six on your next status call, in order. Every answer in the right column ## 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. +Email your agency tonight. One line: "Please send me the current org chart with names, roles, and FTE (full-time equivalent) 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 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 index ecbb99715..b9037d62b 100644 --- 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 @@ -2,17 +2,17 @@ PR reviewer attention math: 4 projects, 15 minutes per PR, what gets missed 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 index ca41f5bdc..70d369c64 100644 --- 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 @@ -48,7 +48,7 @@ If you're running your first ever smoke test, use [the email-only version](/cour ## The setup (15 minutes) -The Stripe Payment Link mechanic is the same as in [Chapter 1.5 (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: +The Stripe Payment Link mechanic is the same as in [Lesson 1.5 (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." @@ -78,17 +78,17 @@ Based on Pieter Levels' [70-product startups portfolio](https://levels.io/startu 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 product will retain users once shipped (that's [Lesson 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/)). +- Whether the people who pre-ordered will actually use the product (that's interview-stage research - [Lesson 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.4 (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.2 (build the page)](/course/tech-for-non-technical-founders-2026/smoke-test-build-page/) - the email-only version this page upgrades. -- [Chapter 1.5 (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. +- [Lesson 1.4 (the standard smoke test - run-it phase)](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) and [Lesson 1.2 (build the page)](/course/tech-for-non-technical-founders-2026/smoke-test-build-page/) - the email-only version this page upgrades. +- [Lesson 1.5 (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. --- 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 index 55dfe0770..194a56dbd 100644 --- a/content/course/tech-for-non-technical-founders-2026/faq/index.md +++ b/content/course/tech-for-non-technical-founders-2026/faq/index.md @@ -37,7 +37,7 @@ If you're stuck, start here. These are the questions founders ask most often - r **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. +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 [Lesson 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?** @@ -49,7 +49,7 @@ Don't skip - sign up for Stripe tonight and let it verify in the background whil **Q: Which landing page builder should I use?** -Mixo (~60 seconds from idea to page). If the templates don't fit, Carrd (no-code drag-drop). Don't comparison-shop for a week - you're testing demand, not builders. [Ch 1.2](/course/tech-for-non-technical-founders-2026/smoke-test-build-page/) has the workflow for both. +Mixo (~60 seconds from idea to page). If the templates don't fit, Carrd (no-code drag-drop). Don't comparison-shop for a week - you're testing demand, not builders. [Lesson 1.2](/course/tech-for-non-technical-founders-2026/smoke-test-build-page/) has the workflow for both. --- @@ -57,19 +57,19 @@ Mixo (~60 seconds from idea to page). If the templates don't fit, Carrd (no-code **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 (Ideal Customer Profile - the specific kind of person your hypothesis names). Tighten to "12-person law-firm office manager." (2) Search second-degree keywords: "boarding costs" instead of "pet sitter." The [Ch 2.3 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. +Two fixes: (1) Your hypothesis is too vague - "small business owners" is not a searchable ICP (Ideal Customer Profile - the specific kind of person your hypothesis names). Tighten to "12-person law-firm office manager." (2) Search second-degree keywords: "boarding costs" instead of "pet sitter." The [Lesson 2.3 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)?** +**Q: Should I skip the AI persona rehearsal (Lesson 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.3](/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. +If you've run customer interviews before and your questions reliably produce concrete past-tense answers, skip it - go straight to [Lesson 2.3](/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: Fewer than 7 of my 10 interviewees have actually spent time or money on the problem. What does that mean?** -Pivot or kill, depending on the count. The [Ch 2.5 gate](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) reads: 7 or more of 10 interviewees with real past spend = build, 4-6 = pivot, under 4 = kill. 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. +Pivot or kill, depending on the count. The [Lesson 2.5 gate](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) reads: 7 or more of 10 interviewees with real past spend = build, 4-6 = pivot, under 4 = kill. 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. --- @@ -77,7 +77,7 @@ Pivot or kill, depending on the count. The [Ch 2.5 gate](/course/tech-for-non-te **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. +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 [Lesson 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.** @@ -89,15 +89,15 @@ Your Section 3 is too vague. Rewrite every feature as a "When / I want / So I ca **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.5 ceiling signal](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) - not before. +Run the [Lesson 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 [Lesson 4.5 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.3 chapter](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) for the full list. +Only 3 rules need to be true before you open Lovable: (1) your one-page brief passed the Lesson 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. [Lesson 4.3](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) teaches the 3 pre-flight rules; the [full stack reference](/course/tech-for-non-technical-founders-2026/reference/stack-tools-full/) has all 12. **Q: Lovable generated a sprawling 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.3](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) to audit your build against your brief. +Your brief's Section 3 is feature-shaped. Go back to [Lesson 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 [Lesson 4.3](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) to audit your build against your brief. --- @@ -105,15 +105,15 @@ Your brief's Section 3 is feature-shaped. Go back to [Ch 3.2](/course/tech-for-n **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.6 chapter](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) has the exact contract template. +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 [Lesson 5.6 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 - people who already know you reply and close at many times the rate of cold strangers, which is why [Ch 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) runs the warm list first. If your network truly has zero applicable names, skip to [Ch 5.7 cold outbound](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/). +Five is enough to start. Message all five before you try cold outbound - people who already know you reply and close at many times the rate of cold strangers, which is why [Lesson 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) runs the warm list first. If your network truly has zero applicable names, skip to [Lesson 5.7 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 (annual contract value - what one customer pays in year one) 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. +No. A verbal yes is not a paid pilot. Reframe: the deposit is credited toward year-one ACV (annual contract value - what one customer pays in year one), 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. --- @@ -137,7 +137,7 @@ If you validated the problem (10+ customer interviews), start at [Module 3 - Des --- -**Back to the course:** [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) - or jump back into the module you came from. Ready to start? [Chapter 1.1 · Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/). +**Back to the course:** [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) - or jump back into the module you came from. Ready to start? [Lesson 1.1 · Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/). --- diff --git a/content/course/tech-for-non-technical-founders-2026/faq/module-strip.svg b/content/course/tech-for-non-technical-founders-2026/faq/module-strip.svg index a7c3566ad..96ec055a4 100644 --- a/content/course/tech-for-non-technical-founders-2026/faq/module-strip.svg +++ b/content/course/tech-for-non-technical-founders-2026/faq/module-strip.svg @@ -1,14 +1,19 @@ - + FAQ map: questions are grouped as General, then Module 1 Hypothesis and smoke test, Module 2 Validate the problem, Module 3 Design from evidence, Module 4 Build it yourself, and Module 5 First paying customer - in that order. @@ -24,40 +29,40 @@ - - M1 + + M1 Hypothesis & smoke test - - M2 + + M2 Validate the problem - - M3 + + M3 Design from evidence - - M4 + + M4 Build it yourself - - M5 + + M5 First paying customer diff --git a/content/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/find10-journey.svg b/content/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/find10-journey.svg new file mode 100644 index 000000000..44052fc52 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/find10-journey.svg @@ -0,0 +1,91 @@ + + The find-10 journey: from your Lesson 1.1 hypothesis through four steps to ten booked interviews. + A left-to-right strip of six cards. It starts with your hypothesis from Lesson 1.1, then runs four numbered steps: step 1 AI ICP map, paste your three sentences into Claude; step 2 read where they complain; step 3 build the 30-name list; step 4 write to each one personally. It ends with ten interviews booked on the calendar. Arrows connect each card to the next. + + + + + + + + + The find-10 journey + Read where they already complain, then write to those specific people. + + + + + Hypothesis + from Lesson 1.1 + your starting + bet + + + + + + + 1 + AI ICP map + paste into + Claude + + + + + + + 2 + Read the + threads + where they complain + + + + + + + 3 + 30-name + list + named people only + + + + + + + 4 + Write each + personally + name their post + + + + + + 10 interviews + booked + on the + calendar + + + + + + + + + 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 index 8d30338ad..f8f7063b0 100644 --- 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 @@ -31,71 +31,44 @@ related_posts: false > **Module 2 · Lesson 2.3 · [CORE]** · [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) +> **Input:** a hypothesis you suspect is real (from Lesson 1.1) + a sharpened Mom Test question list (built in Lesson 2.1, polished in Lesson 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.4](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) +> **Output:** a 30-name list of specific people you can name because you read what they wrote, ready for the outreach templates in [Lesson 2.4](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) > > **Progress:** M2 · 3 of 6 · Results so far: question list ready to run -> **TL;DR (Part 1 of 2):** Expand your one-sentence hypothesis from Ch 1.1 into three sentences (a short step below), paste them into Claude, and get back the ICP profile (ICP = Ideal Customer Profile - the specific kind of person your hypothesis's [customer] blank names) + 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. +> **TL;DR (Part 1 of 2):** Expand your one-sentence hypothesis from Lesson 1.1 into three sentences (a short step below), paste them into Claude, and get back the ICP profile (ICP = Ideal Customer Profile - the specific kind of person your hypothesis's [customer] blank names) + 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. -The instinctive first move is "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 instinctive first move is "I'll just message my LinkedIn network" - sixty polite DMs that produce 3 calls, two of them old colleagues being nice. The technique below replaces it: read where strangers already complain about your exact problem, then write back to those specific complainers. Same hypothesis, same hours, different place to look - and it fills a calendar with 10+ booked interviews instead of 2-3 polite ones. After this lesson you will be able to: **build a 30-name list of specific people who already complained about your problem in public - people you can name because you read what they wrote.** -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 -``` +The full journey, top to bottom - this page covers the first three steps (map, read, list); [Part 2](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) covers writing to each person and booking the 10 calls: -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.** +![The find-10 journey as a left-to-right strip of six cards: your hypothesis from Lesson 1.1, then four numbered steps - step 1 AI ICP map paste into Claude, step 2 read where they complain, step 3 build the 30-name list, step 4 write each one personally - ending in 10 interviews booked on the calendar.](find10-journey.svg) -> **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-1.4 smoke test should have cleared roughly 6%+ email conversion (the "Promising" band) or 5%+ Stripe-click on the Ch 1.5 price-button variant. 3-6% 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. +> **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 Lesson 1.2-1.4 smoke test should have cleared roughly 6%+ email conversion (the "Promising" band) or 5%+ Stripe-click on the Lesson 1.5 price-button variant. 3-6% is the "iterate the message" zone, not a green light. Below 3% means you have a demand-side problem - go back to [Lesson 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. One time-box before you start: if you catch yourself on day three still polishing the list instead of moving to outreach, stop - the list is a means to 10 conversations, and 25 good rows now beat 30 perfect rows next week. +One time-box: if you catch yourself on day three still polishing the list instead of moving to outreach, stop - 25 good rows now beat 30 perfect rows next week. ## 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: +These are not new homework - they are your 1.1 Founding Hypothesis blanks, unpacked for people-hunting. Open your `Founding Hypothesis` doc, copy the sentence in, and expand two of its blanks into full sentences (the third - Business - is the one genuinely new line). Without them, every interview answer sounds encouraging and you can't tell confirm from kill: | 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 +| **Customer (one sentence)** | Your `[customer]` blank, expanded: *who* is this person in real-world detail - role, company size, the moment in their week when the pain happens. (If you ran the optional Lesson 2.2 persona rehearsal you already sketched role/industry/size - reuse it here.) | 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)** | The one line your hypothesis doesn't carry: 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)** | Your `[approach]` blank, rewritten as the change it makes. 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" | -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. +If you can't write all three on a single napkin, do that first. -### Translate the hypothesis into an ICP map +## 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. +Ran the Lesson 1.2 research prompt? Paste 2-3 of those sourced complaints into the prompt as seed pains - they sharpen the search strings better than the hypothesis alone. + Paste this prompt into Claude or ChatGPT: ```text @@ -106,10 +79,16 @@ My hypothesis (3 sentences): - Business: [paste your business sentence] - Solution: [paste your solution sentence] -Two competitors or adjacent products serving a similar customer: +Two competitors or adjacent products serving a similar customer +(start from the `[competition]` blank in your 1.1 hypothesis - what +your customer uses today): - [competitor 1 URL] - [competitor 2 URL] +Seed pains from real posts (optional, from your Lesson 1.2 research): +- "[customer quote]" +- "[customer quote]" + 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. @@ -121,13 +100,11 @@ If you cannot describe a real community for any item, respond with "NOT FOUND - > No competitor URLs yet? Ask Claude or ChatGPT to name 3-5 competitors for your one-sentence hypothesis, or Google your problem in plain words plus `tool` or `software` and 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 a community the AI proposes is 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 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. +Ran the research prompt back in [Lesson 1.2](/course/tech-for-non-technical-founders-2026/smoke-test-build-page/)? Then you've skimmed these places once already - but that pass collected *phrases* for your landing page. This pass collects the *named people* behind the complaints: every quote you keep now comes with a username and a URL, because these are the people you'll message in 2.4. Start with the threads Perplexity already found for you. **The simplest way:** @@ -137,89 +114,31 @@ Read before you write a single message. You're looking for the exact words peopl 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. [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](https://www.g2.com/) and [Capterra](https://www.capterra.com/) reviews (the two big business-software review sites)** - 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 almost always show - the mutual contact is on the line for it. - -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. +When you're done you should have 30 real sentences and 30 named people. Don't paraphrase - the exact wording is the point, and it becomes your subject lines in Part 2. The per-channel walk (Reddit, LinkedIn, G2, Slack, Twitter, personal network), the Reddit karma rules, and the keyword-variation gallery live in the [full reference](/course/tech-for-non-technical-founders-2026/reference/find-10-people-full/). -**This is the most important step in the chapter.** A list of 30 individuals you can name - because you read what they wrote - replies far more often than a list of strangers a tool exported for you - the quoted line is the difference. +## Build a list of 30 specific people -If you run out of named posters before you hit 30, [Apollo](https://apollo.io)'s free tier (credit-based, no credit card - a small monthly allowance of email and export credits) lets you filter on role + industry + company size and export the rest (the monthly export allowance is small, so this fills the gap over several weeks, not one sitting). Treat it as backfill, not the source - the hand-picked names always perform better. +Turn the 30 sentences into 30 names. Open each thread you saved, 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), and **one specific line they wrote** (the phrase you'll quote back). -> **Save the Apollo filter and whatever contacts your monthly export credits cover (a small monthly allowance 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.7 cold outbound](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/). +Your Lesson 1.2 complaints each came with a thread URL - those posters are named leads with a known pain; enter them as the first rows (name, post URL, quoted line). -Filter the final list on six dimensions: +**This is the most important step in the chapter.** A list of 30 individuals you can name - because you read what they wrote - replies far more often than a list of strangers a tool exported for you - the quoted line is the difference. Aim for 30 hand-picked people in one focused sitting, then filter the list on [six dimensions](/course/tech-for-non-technical-founders-2026/reference/find-10-people-full/#filter-the-list-six-dimensions) (buyer-or-user, company size, one industry, one timezone) so the calls are bookable. -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 or Gemini Deep Research (both paid tiers) 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; pricing is per completed interview - check the panel's current rates. 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) (no signup) surfaces the high-frequency keywords inside any subreddit. [F5Bot](https://f5bot.com) sends email alerts when your keywords appear on Reddit, Hacker News, or Lobste.rs. [Reddinbox](https://reddinbox.com) watches Reddit for your keywords and collects the matching conversations in one inbox so you can reply from there. 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) - 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. +> **Save the Apollo filter and whatever contacts your monthly export credits cover (a small monthly allowance on the free tier) to a tab named "Module 5 cold seed" in your outreach spreadsheet.** You will reuse this exact filter in [Lesson 5.7 cold outbound](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/). > **Done:** 30-name list is built in your spreadsheet with name, role+company, post URL, and one quoted line per row. +> > **You have now:** a question list (2.1-2.2) + a 30-name list of real people (2.3). Outreach is next. > -> **Next:** [2.4 · 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 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 jumping to a paid Apollo plan. +> **Next:** [2.4 · 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 for the list you just built. +> +> **If blocked:** If the AI returned "NOT FOUND" for every community, your hypothesis is too vague. Go back to Lesson 1.1 and rewrite the customer sentence with a specific role, company size, and the moment in their week when the pain happens. If your name list stops at 3 people, search a related keyword ("boarding costs" instead of "pet sitter") - 30 minutes of keyword variation turns 3 names into 12. +> +> **Deeper reference:** [Full channel walk + search-string galleries + list filters + Apollo backfill + monitoring tools + offline-vertical panels](/course/tech-for-non-technical-founders-2026/reference/find-10-people-full/) --- *See it in action: [Module 2 walkthrough: Mia interviews ten parents](/course/tech-for-non-technical-founders-2026/module-2-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/) curriculum.* + 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 index a7526a1af..cc63d8b89 100644 --- 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 @@ -1,7 +1,7 @@ --- title: "2.4 · 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." +description: "The message templates that book 10 customer interviews. 3-message sequence, volume targets, research panel fallback. Part 2 of Lesson 2.3." date: 2026-05-18 draft: false course_chapter: true @@ -33,120 +33,65 @@ related_posts: false > > **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 and the first outreach batch sent - you'll run the calls with the Ch 2.1 script, then score them in Ch 2.5 +> **Output:** 10 interview calls booked and the first outreach batch sent - you'll run the calls with the Lesson 2.1 script, then score them in Lesson 2.5 > > **Progress:** M2 · 4 of 6 · Results so far: question list + 30-name prospect list > **TL;DR:** Send 30 staggered messages referencing specific posts you read, using a 3-message sequence (Day 0 intro + Day 3 bump + Day 7 close). Reply rate runs 20-30% when each message names a specific post; 1-5% when it doesn't. Plan to extend the list once or twice before all 10 calls are booked. -> **Read [Chapter 2.3 - Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) first.** It covers the ICP mapping, reading threads, and building the 30-name list. You need that list before the templates below will work - generic openers collapse to 1-5% reply rates. +> **Read [Lesson 2.3 - Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) first.** It covers the ICP mapping, reading threads, and building the 30-name list. You need that list before the templates below will work - generic openers collapse to 1-5% reply rates. -> **How this chapter relates to Ch 2.6:** this chapter recruits 10 fresh interviewees and runs PAST-BEHAVIOR interviews about whether the problem is real. [Ch 2.6](/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-2.4 first to validate THE PROBLEM, then Ch 2.6 to validate THE SOLUTION SHAPE. +> **How this chapter relates to Lesson 2.6:** this chapter recruits 10 fresh interviewees and runs PAST-BEHAVIOR interviews about whether the problem is real. [Lesson 2.6](/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. -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.7 cold-email script here; it scares interview subjects who don't yet know you have a product. +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 Lesson 5.7 cold-email script here; it scares interview subjects who don't yet know you have a product. After this lesson you will be able to: **send outreach that names something the person actually wrote - and book 10 interviews from your 30-name list.** ## What to write so they don't ignore you -Nervous about messaging strangers? The asymmetry works in your favor: you're asking someone to talk about their own expertise and frustrations to a person who is actually listening - more people are flattered by that than bothered by it. - Send 30 messages staggered, not in one burst. A handful a day, by hand, beats a single bulk-send. In outreach runs we've coached, reply rates land around 20-30% when each message names a specific post you read - 2-3 booked calls per batch of 30; stack batches until 10 calls are on the calendar. -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/) (daily caps vary by plan - check Google's current limits) 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 a first-time founder typically writes 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 projects: - -```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! -``` - -That message gets almost no replies - nothing in it tells the reader why them. Here's why each sentence dies: +You can do this from Gmail and a [NeetoCal](https://www.neeto.com/neetocal) booking link. Reply by hand - the back-and-forth is where the interview actually gets booked. Too slow at 6 a day? The [full reference](/course/tech-for-non-technical-founders-2026/reference/find-10-people-full/#slow-path-variant-for-the-part-time-founder) covers Gmail multi-send and the part-time batch-send variant. -- **"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 Day-0 message that has to work -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 Day-0 message is the one that has to work - the whole sequence rests on a first line that names something they actually wrote. Copy it verbatim, replace the brackets 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: -### 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]." -``` +> Subject: your post about [their exact words] +> +> Hi [name] - you wrote that [ONE SPECIFIC LINE FROM THEIR POST, PARAPHRASED]. I'm researching exactly that problem and would trade 20 minutes for everything you learned the hard way. No pitch, nothing to sell - I don't even have a product yet. Would [DAY] or [DAY] work? Booking link if that's easier: [NEETOCAL LINK] -**Day-3 bump message - pick the version that fits your stage:** +Full 3-message sequence (Day 0 + Day 3 bump + Day 7 close) - copy it from the [Outreach Sequence Template](/course/tech-for-non-technical-founders-2026/outreach-sequence-template/). -- **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 20 minutes if you have it." -- **Experienced variant (you have 10+ interviews done):** "Hi [name] - circling back on the [topic] piece. [TRUE NUMBER] conversations in so far - they're sharper than I expected; happy to share the pattern if you have 20 min." Use your real count - never claim conversations you have not had. +That three-message shape is the whole engine. 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 [full reference](/course/tech-for-non-technical-founders-2026/reference/find-10-people-full/) has the bad-first-draft teardown (why each generic line dies) and the LinkedIn-DM variation. -The Day-3 bump reliably recovers another slice of non-responders - people who meant to reply and lost the tab. Subject line: `re: [their workaround]`. +### Why people say yes (or don't) -```text -Day 7 - close (catches a few last stragglers) -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." -``` +Teresa Torres names three reasons a stranger turns down an interview ask, and the sequence above already answers two of them ([Product Talk](https://www.producttalk.org/customer-interviews/)): -That three-message shape is the whole engine - in the runs we've coached it reliably beats single-send by a wide margin 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). +- **Limited time** - ask for 20 minutes, not "a quick chat" or an open-ended hour. The Day-0 template already does this. +- **Unclear benefit** - say what they get out of it. Talking about their own expertise to someone actually listening is the benefit; the opener leans on it. +- **Fear of the unknown** - people hesitate when they can't picture how the time will be spent. This is the one most first drafts skip. Tell them exactly what happens with one added sentence: *"We'll walk through what happened the last time you [problem] - no prep, no pitch."* Drop it into the Day-0 message right after the ask. ### Volume targets Work through the 30-name list first, then extend it with Part 1's second-degree searches until 10 interviews are booked - plan on 50-100 messages total. Target a reply rate of 20% or higher. Under 10% means your opener is too generic or you're in the wrong channel - rewrite the Day-0 message before sending more. 10-20% is workable: let the sequence run and tighten the subject line on the next batch. Of the replies who say yes, expect roughly half 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. +## Three tracks to 10 booked calls -Everything up to here costs $0 - Gmail and the 30-name list you built in Part 1. A research panel is the paid shortcut: you pay the service to book interviewees for you, which usually runs a few hundred dollars total for a round of calls. That is why it is not the default - use it only when the cold-outreach path can't reach your ICP and replies run thin. When it does work, run it 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.4](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) (built in [1.2](/course/tech-for-non-technical-founders-2026/smoke-test-build-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?" - -That opener out-performs every cold variant in this chapter - the person already raised a hand. +Cold outreach is the main track. Two others run alongside it when they fit: ```mermaid -%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%% +%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, Comic Sans MS, 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.2 + 1.3] + A --> D[Smoke-test track: landing page from Lesson 1.2 + 1.3] B --> E[10 interviews booked] C --> E D --> E - E --> F[Apply Mom Test script from Chapter 2.1] + E --> F[Apply Mom Test script from Lesson 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 @@ -159,56 +104,24 @@ flowchart TD 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 noticeably lower reply rate 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. +- **Research panel** - if your ICP can't be reached cold (a CFO at a regulated bank, an oncology nurse), a paid panel like [User Interviews](https://userinterviews.com) or [Respondent](https://respondent.io) books screened interviewees for a few hundred dollars. Use it only when replies run thin. +- **Smoke-test landing page** - the page from [Lesson 1.4](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) doubles as your warmest opener: *"You signed up for the waitlist on [page] last Tuesday - up for a 20-minute call?"* -> **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. Plan 20-30 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.6 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.6 input - and later, your Module 5 onramp invitees in Ch 4.3-4.4, 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) - 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. +Both tracks, the parallel-run logic, and the part-time founder's batch-send variant are in the [full reference](/course/tech-for-non-technical-founders-2026/reference/find-10-people-full/). > **Done:** 10 interview calls are booked on your calendar and you have sent the first batch of outreach messages. -> **You have now:** question list (2.1-2.2) + 30-name list (2.3) + 10 booked interviews (2.4). > -> **Next:** 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. +> **You have now:** question list (2.1-2.2) + 30-name list (2.3) + 10 booked interviews (2.4). The problem itself is still unvalidated - the interviews you run next test it. +> +> **Next:** 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. The [full reference](/course/tech-for-non-technical-founders-2026/reference/find-10-people-full/#what-happens-after-the-10-calls-are-booked) has the complete artifact chain from booked call to validated problem statement. +> > **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). +> +> **Deeper reference:** [Message teardowns, the panel fallback, the slow-path variant, and the post-booking artifact chain](/course/tech-for-non-technical-founders-2026/reference/find-10-people-full/) --- *See it in action: [Module 2 walkthrough: Mia interviews ten parents](/course/tech-for-non-technical-founders-2026/module-2-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/) curriculum.* + diff --git a/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/first-paying-customer-operating-kit.pdf b/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/first-paying-customer-operating-kit.pdf index 19a3353e8..3e7ba2ab0 100644 Binary files a/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/first-paying-customer-operating-kit.pdf and b/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/first-paying-customer-operating-kit.pdf 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 index af3f7633c..010bfedfe 100644 --- 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 @@ -1,7 +1,7 @@ --- -title: "The First-Paying-Customer Operating Kit (DPA Template Live)" +title: "The First-Paying-Customer Operating Kit" 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." +description: "The six-template kit for Module 5. Every component lives in a Module 5 lesson or reference page - this is the one-page index. No email signup." date: 2026-05-13 draft: false course_chapter: true @@ -23,135 +23,71 @@ 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." + og_title: "The First-Paying-Customer Operating Kit" + og_description: "The six-template kit for Module 5. Every component lives in a Module 5 lesson or reference page - this is the one-page index. 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 - the Design Partner Agreement is live below; the other five ship as they are ready. +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 - each one lives in a Module 5 lesson or its reference page, and this kit is the one-page index. -> **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. +> **How this works:** every component below links straight to the lesson or reference page that hosts it, copy-pasteable at the source. The DPA deposit clause is inline below as well. There is no email signup and nothing to wait for - just the links. *Prefer paper? Download the PDF - same content, print-ready.* -# 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 runs seven lessons (5.1-5.7): the Sean Ellis 40% test, channel choice, the personal-network outreach arc, the paid-pilot contract, and the cold-outbound pipeline. The lessons reference these templates. 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; -``` +Module 5 of this course runs seven lessons (5.1-5.7): the Sean Ellis 40% test, channel choice, the personal-network outreach arc, the paid-pilot contract, and the cold-outbound pipeline. The lessons carry these templates; this page is the index that points at each one. + +![The First-Paying-Customer Operating Kit and its six numbered components: the 50-name network list, cold-email scripts, the Design Partner Agreement, the Stripe Checkout setup, the Sean Ellis 40% survey, and the First 10 Customers tracker](kit-components.svg) ## The 6 components ### 1. 50-name network list template (Google Sheets) -The fill-in spreadsheet from [Chapter 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/). 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. +The fill-in spreadsheet from [Lesson 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/). 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. Seed it before hunting LinkedIn: your 2.4 interviewees, 1.4 waitlist signups, and 2.3 30-name list are the champions and hot rows already. 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.7](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/). Three sector-specific versions: +The verbatim 4-line scripts: the B2B SaaS variant is inline in [Lesson 5.7](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/); the services and B2C variants live in the [outbound reference](/course/tech-for-non-technical-founders-2026/reference/outbound-full/). Three sector-specific versions: -- **B2B SaaS Rails context** - the script for founders who built on Rails and are selling to operators in the same space. +- **B2B SaaS, shipped-MVP context** - the script for founders who shipped an MVP on Lovable + Supabase + Stripe and are selling to operators who flagged the same problem. - **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). +Each script is 4-6 lines including the subject, opens with one specific personalized reference, and carries one currency anchor (deposit or beta price). Follow up with non-responders once only. 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.6](/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). +The one-page DPA from [Lesson 5.6](/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. Copy the block into Google Docs; export to PDF or import into DocuSign from there when a customer wants to print or e-sign. -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. +Typical fills: $1,500 deposit for a B2B SaaS pilot, $5,000 for a B2B services pilot - both inside the 10-30% of year-one ACV band. 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] +**The full six-section DPA template lives in [Lesson 5.6](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/#dpa-template). The clause that carries the pilot is the deposit:** + +```text +DESIGN PARTNER AGREEMENT + +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. +``` + +Copy it verbatim from [Lesson 5.6's DPA block](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/#dpa-template), then apply the $1,500 or $5,000 sector fills described above. ### 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. +Five steps to a working Stripe payment link, no engineer required - the setup walk lives in [Lesson 5.6](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) with the framework detail in the [paid-pilot reference](/course/tech-for-non-technical-founders-2026/reference/paid-pilot-full/). Optional Rails / Django / Laravel snippets are 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. @@ -159,27 +95,21 @@ What it does: 15-minute payment-link setup so the first deposit arrives Wednesda ### 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. +The exact 5 questions, verbatim, are in [Lesson 5.1](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/) - type them into Typeform, Tally, or a Google Form (five questions, two minutes to set up). The CSV scoring walk, including the per-segment must-have % formula, is in the [survey reference](/course/tech-for-non-technical-founders-2026/reference/must-have-survey-full/): pivot the Q1 column by the Q5 segment column and the per-segment number appears. Result: 24 hours from "I should run the test" to a scored result you can act on. -### 6. The "First 10 Customers" Airtable tracker +### 6. The "First 10 Customers" Google Sheet tracker -The Airtable base from [Chapter 5.7](/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." +The tracker from [Lesson 5.7](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/) - build it as a Google Sheet with these 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) +![Sample row from the First 10 Customers Google Sheet 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. ### Bonus: the 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: +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/) lesson 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 | |--------|---------|---------------|--------| @@ -200,7 +130,7 @@ 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 2 (personal network).** Fill the 50-name template (template 1), seeding it with your 2.4 interviewees, 1.4 waitlist signups, and 2.3 30-name list first. 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. @@ -210,11 +140,11 @@ By Friday of week 4, you should have: a segment-isolated persona doc, 50 sent me ## 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. +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 Sheet breaks and you graduate to a real CRM. It also does not replace the must-have-segment test from [Lesson 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; work 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. +Every component is copy-pasteable from its linked lesson or reference page, and the DPA deposit clause is inline above. No mailing list, no funnel - just the links. ## Where this fits in the course @@ -225,8 +155,8 @@ This kit is the template companion to Module 5 of the [From Idea to First Paying - 5.6 [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. - 5.7 [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. +Module 5 ends here. Every kit artifact is live in its linked lesson or reference page. ## 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 open for the same reason. +[JetThoughts](https://jetthoughts.com), a Rails-first dev shop that has built alongside non-technical founders for 20 years. We published this course because the same five mistakes kept showing up in first calls with founders. The kit ships open for the same reason. diff --git a/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/kit-components.svg b/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/kit-components.svg new file mode 100644 index 000000000..b8865c25a --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/kit-components.svg @@ -0,0 +1,94 @@ + + The First-Paying-Customer Operating Kit and its six components: the 50-name network list, cold-email scripts, the Design Partner Agreement, the Stripe Checkout setup, the Sean Ellis 40 percent survey, and the First 10 Customers tracker. + + + + + + + + + + + First-Paying-Customer Operating Kit + Six templates that run Module 5 + + + + + + + + + + + + + + + + 1 + 50-name network list + Google Sheet · Lesson 5.3 + + + + + + + 2 + Cold-email scripts + 3 sector variants · Lesson 5.7 + + + + + + + 3 + Design Partner + Agreement + One-page LOI · Lesson 5.6 + + + + + + + 4 + Stripe Checkout setup + Rails / Django / Laravel + + + + + + + 5 + Sean Ellis 40% survey + 5 questions · Lesson 5.1 + + + + + + + 6 + First 10 Customers + tracker + Google Sheet · Lesson 5.7 + + + From live MVP to signed paid pilot in 4 weeks - one template per step. + 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 index c1df70ffa..bb86c76f6 100644 --- 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 @@ -1,5 +1,5 @@ - Sample row from the First 10 Customers Airtable tracker + Sample row from the First 10 Customers Google Sheet tracker - First 10 Customers tracker - sample rows from the Airtable template + First 10 Customers tracker - sample rows from the Google Sheet template diff --git a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/index.md b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/index.md index 3ed57317d..38d618c65 100644 --- a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/index.md +++ b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/index.md @@ -28,7 +28,7 @@ related_posts: false > **Module 5 · Lesson 5.3 · [CORE]** · [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/) +> **Input:** must-have-user persona + 1 named segment from [Lesson 5.1](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/) > > **Output:** 50 names sorted into 4 outreach buckets > @@ -38,7 +38,7 @@ related_posts: false --- -Sixty percent of the fastest-growing B2B startups got their first 10 customers from people who already knew the founder. Founders skip this step because it feels like begging. It's not. It's the highest-probability first sale you'll ever make. +Nearly every one of today's fastest-growing B2B startups got their first 10 customers from people who already knew the founder. Founders skip this step because it feels like begging. It's not. It's the highest-probability first sale you'll ever make. After this lesson you will be able to: **sort 50 names into 4 outreach buckets so you know exactly who to message first.** @@ -59,27 +59,30 @@ Open a Google Sheet. Six columns: Name, Company, Role, Bucket, Relationship stre ![The 4-bucket grid - how 50 names get sorted before the first message goes out](network-buckets.svg) -> **First, count your network.** Filter your 1st-degree LinkedIn connections by your must-have segment from Ch 5.1 (title + company size + industry). +> **First, count your network.** Filter your 1st-degree LinkedIn connections by your must-have segment from Lesson 5.1 (title + company size + industry). > > | Count | What this means | Your path | > |---|---|---| > | **30+** | Standard warm motion works. | Continue below. | -> | **15-29** | Reduced warm motion. Build smaller buckets: 2 champions + 5 hot + 8 warm + 5 cold. You'll need cold outbound ([Ch 5.7](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/)) in parallel. | -> | **Under 15** | Your network doesn't contain the ICP segment. | Skip to [Ch 5.7](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/) cold outbound. | +> | **15-29** | Reduced warm motion. Build smaller buckets: 2 champions + 5 hot + 8 warm + 5 cold. You'll need cold outbound ([Lesson 5.7](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/)) in parallel. | +> | **Under 15** | Your network doesn't contain the ICP segment (ICP = Ideal Customer Profile - the specific kind of person your product is for). | Skip to [Lesson 5.7](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/) cold outbound. | --- > **Build:** > +> 0. **Your champions and hot buckets are already built - drop them in by name first:** your [2.4 interviewees](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) (ten people who spent 30 minutes describing the pain), your [1.4 smoke-test waitlist signups](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) (they raised a hand for this exact product), and your [2.3 30-name list](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) (each with the exact line they wrote about the problem). Then use the steps below to top up to 50. > 1. Open LinkedIn. Filter 1st-degree connections by your must-have segment criteria. > 2. Export the filtered list with [LinkedIn's data export](https://www.linkedin.com/help/linkedin/answer/a566336) (free, takes 24 hours; you can use yesterday's). > 3. Cross-reference your phone contacts, email inbox, and last three jobs' Slack workspaces if you still have access. > 4. Sort every name into one of the 4 buckets. Champions first. If you can't name 5 people who complained to you about this problem in the last 12 months, re-read your verbatim Q2-Q3 quotes from [5.1](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/). -> 5. **✅ Success check:** 50 names sorted across all 4 buckets, champions row fully filled. +> 5. **Success check:** 50 names sorted across all 4 buckets, champions row fully filled. --- -**If this fails: your network is under 15 names after filtering.** **Why:** your must-have segment isn't represented in your professional network. **Fix:** skip to [Ch 5.7 cold outbound](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/). Use community fallbacks (Indie Hackers, sector Slack, Reddit) as warm-cold hybrid messages. +**If this fails: your network is under 15 names after filtering.** +- **Why:** your must-have segment isn't represented in your professional network. +- **Fix:** skip to [Lesson 5.7 cold outbound](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/). Use community fallbacks (Indie Hackers, sector Slack, Reddit) as warm-cold hybrid messages. --- diff --git a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/network-buckets.svg b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/network-buckets.svg index b1522ab9f..90a7ca5da 100644 --- a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/network-buckets.svg +++ b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/network-buckets.svg @@ -2,11 +2,11 @@ The 50-name network list sorted into 4 outreach buckets
    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 -``` +![Refactoring real versus fake: one messy 400-line OrdersController either splits into small Cart, Checkout, and Receipt controllers behind the same Stripe webhook with tests still green (real refactor), or gets rewritten into a 3,800-line v2 with the Stripe secret hard-coded that broke checkout at the board demo and cost a $9K invoice (fake refactor)](refactor-check.svg) ### 🐳 2. Docker @@ -102,7 +73,7 @@ Listen for which side of this table your team lands on: | "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." +An EdTech founder 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 @@ -151,25 +122,37 @@ A healthy architecture for a pre-Series-A Rails SaaS is one Rails monolith on He 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 | +**Customer & validation words** - who you serve and whether the demand is real: + +| Term | Plain English | Where it shows up | |---|---|---| -| **ICP** | Ideal Customer Profile - the specific kind of person your hypothesis names | Ch 1.1, 2.3 | -| **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.6 | -| **ACV** | Annual Contract Value - what one customer pays in year one (deposit math is 10-30% of ACV) | Ch 5.6 | -| **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.6 | -| **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.6 | -| **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 | +| **ICP** | Ideal Customer Profile - the specific kind of person your hypothesis names | Lesson 1.1, 2.3 | +| **JTBD** | Jobs To Be Done - what a customer "hires" your product to do (instead of feature list) | Lesson 3.1, 3.2 | +| **PMF** | Product-Market Fit - the survey question "would you be very disappointed if you could no longer use this?" 40%+ "very disappointed" = signal | Lesson 5.1 | +| **NPS** | Net Promoter Score - "how likely are you to recommend us?" 0-10 scale; less useful at idea stage than PMF | Lesson 5.1 sidebar | +| **Retention** | What % of users come back next week / next month - the only metric that proves the product solves a real problem | Lesson 5.1 | +| **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 | Lesson 4.3 Concierge MVP | + +**Money & market words** - the numbers that decide whether it is a business: + +| Term | Plain English | Where it shows up | +|---|---|---| +| **MRR** / **ARR** | Monthly / Annual Recurring Revenue - what one customer pays per month or year | Lesson 1.1, 5.6 | +| **ACV** | Annual Contract Value - what one customer pays in year one (deposit math is 10-30% of ACV) | Lesson 5.6 | +| **CAC** / **LTV** | Customer Acquisition Cost / Lifetime Value - what you spend to land one customer vs what they pay you over their lifetime | Lesson 5.2, 5.6 | +| **Unit economics** | Revenue per customer minus cost to serve per customer - whether the math works at scale | Lesson 1.1 Money lens | +| **Runway** | Months of cash until you must show paying customers or close the company | Lesson 4.1 Q3 | | **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.3 | -| **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.3 Concierge MVP | + +**Strategy, deal & tool words** - the frameworks, contracts, and tools you touch: + +| Term | Plain English | Where it shows up | +|---|---|---| +| **SWOT / PESTEL / Porter's Five Forces** | Three classic strategy-school checklists - VenturusAI runs all three on your hypothesis | Lesson 1.1 sidebar | +| **Pixel** | A small JavaScript tracking snippet from an ad platform (Meta/LinkedIn/Reddit) - paste it on your page and the platform learns who converted | Lesson 1.4 | +| **DPA** | Design Partner Agreement - a one-page contract where a customer pays a deposit to test your product as a co-design partner | Lesson 5.6 | +| **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 | Lesson 3.1 | ## What to do tomorrow 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 index 957c5d906..83b6b742a 100644 --- 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 @@ -9,7 +9,7 @@ .box-l { fill: #fff5f5; stroke: #cc342d; stroke-width: 2.5; stroke-linejoin: round; stroke-linecap: round; } .box-r { fill: #f5f0ff; stroke: #a855f7; stroke-width: 2.5; stroke-linejoin: round; stroke-linecap: round; } .arrow { stroke: #1a1a1a; stroke-width: 2.5; stroke-linecap: round; fill: none; } - .caption { font-family: "Caveat", "Patrick Hand", cursive; font-size: 18px; fill: #666; font-style: italic; } + .caption { font-family: "Caveat", "Patrick Hand", "Comic Sans MS", cursive; font-size: 18px; fill: #666; font-style: italic; } diff --git a/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/refactor-check.svg b/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/refactor-check.svg new file mode 100644 index 000000000..c02b72d07 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/five-tech-words-stop-nodding-at/refactor-check.svg @@ -0,0 +1,103 @@ + + Refactoring, real versus fake: one messy 400-line controller either splits into small controllers behind the same Stripe webhook with tests still green (a real refactor), or gets rewritten into a 3,800-line v2 with the Stripe secret hard-coded that broke checkout at the board demo and cost a 9,000-dollar invoice (a fake refactor). + + + + + + + + Refactoring: real vs fake + One messy controller. Two ways the word lands on your invoice. + + + + + OrdersController + 400 lines, messy, + hard to read + + + + + + + + REAL REFACTOR ✓ + + + + Cart · 120 lines + + + + Checkout · 140 lines + + + + Receipt · 130 lines + + + + + + + Same Stripe webhook + Tests stay green + + + + + + + ✓ Same behavior + Cleaner structure + 3-line commit cap + + + + FAKE REFACTOR ✗ + + + + OrdersController v2 + 3,800 lines, no tests + + + + + + + Stripe secret + hard-coded in controller + + + + + + + ✗ Checkout broke + at the board demo + $9K for the rewrite + + + A real refactor leaves a working feature untouched. A fake one rewrites it on your dime. + 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 index 12a5e2b20..53dcc5d71 100644 --- 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 @@ -1,19 +1,46 @@ - - - If we help - - customer - solve - - problem - with - - approach - they'll choose it over - - competition - because - - differentiation - Five blanks. One sentence. No vagueness allowed. + + The founding-hypothesis Mad Libs sentence with five blanks: If we help [customer] solve [problem] with [approach], they'll choose it over [competition] because [differentiation]. + Five fill-in-the-blank pills stitched into one sentence. Three red pills name the customer, the problem, and the approach; two purple pills name the competition and the differentiation. Caption: five blanks, one sentence, no vagueness allowed. + + + + + + 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 index a00473d26..d94121953 100644 --- 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 @@ -41,7 +41,7 @@ A first-time founder usually treats their strategy as a fact ("parents need this A **Founding Hypothesis** is a fill-in-the-blanks sentence (Mad Libs style) 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]."* +> *"If we help `[customer]` solve `[problem]` with `[approach]`, they'll choose it over `[competition]` because `[differentiation]`."* Five blanks. One sentence - not a deck - because a sentence can't hide vague thinking, and because you'll reuse it everywhere: it feeds your landing-page headline in 1.2 (reshaped into a customer-plus-outcome one-liner) and tells Module 2 who to interview and which problem to ask about (you keep the sentence to yourself in interviews - pitching it contaminates the answers). The discipline is filling all five blanks with specifics, not categories. @@ -49,23 +49,23 @@ Each blank is an assumption, and each assumption has a test waiting for it later | Blank | Where it gets tested | |---|---| -| [customer] + [problem] | Strangers recognize themselves in your headline (1.2), then ten Mom Test interviews confirm the pain (Module 2) | -| [approach] | A clickable prototype in front of 5 interviewees (Module 2) | -| [competition] + [differentiation] | 300 cold strangers convert on your page - or don't (1.4) | +| `[customer]` + `[problem]` | Strangers recognize themselves in your headline (1.2), then ten Mom Test interviews confirm the pain (Module 2) | +| `[approach]` | A clickable prototype in front of 5 interviewees (Module 2) | +| `[competition]` + `[differentiation]` | 300 cold strangers convert on your page - or don't (1.4) | | The whole bet: will they pay? | The Stripe price test (1.5) | **Why this works:** when the sentence is vague, people nod politely because there's nothing to disagree with; when it's specific, they push back - and the pushback is what you're after: -- ❌ *"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. +- **Bad:** *"We help small businesses save time with automation."* - Nobody can argue with this. Nobody can validate it either. +- **Good:** *"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 +- **`[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) @@ -91,14 +91,18 @@ Score each lens 1-5. Be honest - this is for you, not an investor deck. > 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. +> 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]`, inside a new Google Drive folder called `Founder OS` - every module adds an artifact to that folder, and by the course's end it is your evidence pack. You'll paste it verbatim into Lessons 1.2, 1.4, and 1.5. Module 2 uses it too - to choose who you interview and what you ask about - but you never read it to an interviewee. --- -**If this fails: 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.2 - you'll fill it after Module 2 interviews. +**If this fails: 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). The fastest way: the copy-paste research prompt in [Lesson 1.2](/course/tech-for-non-technical-founders-2026/smoke-test-build-page/) hands Perplexity your `[customer]` and `[problem]` blanks and returns 5-8 sourced quotes. 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.2 - you'll fill it after Module 2 interviews. -**If this fails: 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. +**If this fails: 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. --- 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 index 1f1123feb..73ab8ab91 100644 --- 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 @@ -2,10 +2,10 @@ One Loom for a small full-stack team versus five Looms for a microservice-detached team
    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 - -``` +One founder 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. + +![The Friday demo weekly loop: Monday 9am the founder posts the 7-question template in #dev Slack, Tuesday through Thursday the team builds and reviews against those questions, and Wednesday end of day the team checks whether anything won't be ready - if yes they replan before Friday, if no they go straight on. Friday 4pm is a 15-minute Loom or live demo of working software only, the founder clicks every staging URL during the call, and that evening forwards the Loom URL to their inbox - then the cycle repeats the next Monday. After 4 Fridays, review the pattern: 4 of 4 demos clickable means the cadence works and continues weekly; 2 of 4 or fewer means something is stalling, so run the Org Chart audit and the red-flags checklist.](friday-loop.svg) + +If the four-week score lands at 2 of 4 or fewer, run the [Org Chart audit](/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/) and the [eight red flags checklist](/blog/dev-shop-red-flags-checklist/) before adding any new process - the demo cadence is the symptom log, those two are the diagnosis. ## What to do tomorrow 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 index acf365f6c..487cf4153 100644 --- 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 @@ -24,9 +24,7 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 related_posts: false --- -📋 Template companion to the Oversight Rhythm sub-section of [The Founder Org Chart](/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/) (Going Further). Send to your team Monday. Run Friday at 4pm. - -# The Friday Demo Template +Template companion to [The Friday Demo Rule](/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/). Send to your team Monday. Run Friday at 4pm. A 15-minute Friday script that catches fake progress before it costs you a sprint. @@ -36,7 +34,7 @@ By Friday of week 4 you will know whether your dev team is shipping or stalling. ## 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. +Jira closing nine tickets in a week tells you cards moved, not that anything works. A feature can sit "behind a feature flag" for three weeks, throw a 500 on every click, and still show up as closed tickets and a confident status update - four months and $54K into a six-week MVP - because no one on the call has to open it in front of you. The seven questions above force that open. Asked in order, they turn a status call into four demos and four staging URLs you click yourself: what shipped, what the user can now do, where it is live for you, and what got cut to make room. ## How to use it @@ -97,7 +95,7 @@ This is the over-engineering check. If your team never cuts anything, they are e > 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." +> Good: "PR #843 - admin search. Priya reviewing since Tuesday, two changes requested, waiting on author. PR #851 - signup rate limiting. No reviewer yet because Priya is on PTO Thu-Fri; will assign Monday." 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. @@ -105,7 +103,7 @@ If the same name keeps appearing as the only reviewer, you have a single point o 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. +3. **Write down one number per demo.** "PR #849", "$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 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 index ade6c1010..bf5080561 100644 --- 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 @@ -1,7 +1,7 @@ --- title: "4.2 · Who Owns Your GitHub, AWS, and Database?" aliases: ["/blog/github-aws-database-ownership-checklist/"] -description: "Before you hire anyone, lock down who owns the code, cloud, and domain. A 45-minute Friday audit surfaces every credential that should be in your name." +description: "Before you hire anyone, lock down who owns the code, cloud, and domain. A 45-minute Friday audit surfaces every credential that should be in your name. Lesson 4.2 of the course." date: 2026-05-13 draft: false course_chapter: true @@ -23,7 +23,7 @@ cover_image: cover.png metatags: image: cover.png og_title: "4.2 · Who Owns Your GitHub, AWS, and Database?" - og_description: "Before you hire anyone, lock down who owns the code, cloud, and domain. A 45-minute Friday audit surfaces every credential that should be in your name." + og_description: "Before you hire anyone, lock down who owns the code, cloud, and domain. A 45-minute Friday audit surfaces every credential that should be in your name. Lesson 4.2 of the course." 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 @@ -31,15 +31,15 @@ related_posts: false > **Module 4 · Lesson 4.2 · [CORE]** · [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) +> **Input:** a build-path decision from [Lesson 4.1](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/) (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) > -> **Progress:** M4 · 2 of 5 · Results so far: build path chosen (4.1) - this page locks ownership before anything gets built +> **Progress:** M4 · 2 of 5 · Results so far: build path chosen (4.1) - this lesson locks ownership before anything gets built > **TL;DR:** Before you hire anyone, run this 12-item audit. It takes 45 minutes. If you skip it, the story below is how it ends: the founder who spent 14 months before discovering the AWS root password was in someone else's Gmail. -> **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: +> **If you signed up for Lovable + Supabase + Stripe yourself (the default Path 2 from Lesson 4.1), here is your 5-minute self-check** - the rest of this lesson 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.) @@ -47,60 +47,21 @@ related_posts: false > 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. 2FA (two-factor authentication) is the 6-digit code your phone shows at login, a second proof on top of your password. > -> 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. +> Pass all 5? You can skim the rest of the lesson 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. It also works as a post-hire check, but the cheaper time to run it is on Day 1, not month 14, when the story below kicks off. - -Here's what happens if you skip it. A founder we saw last year: fourteen months into a build, 1,800 paying clinics, a Stripe account in the founder's name, and the AWS root password sitting in the contractor's personal Gmail. The founder had to send three emails asking the contractor to please change the root account email. 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 switch contractors Tuesday without losing access to your own codebase Wednesday. - -Open the AWS console and click your account name in the top-right corner. Read the email address on the root user. Whose inbox does that land in tonight? - -## The 2026 credential trap looks different - -The contractors who create single points of failure 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 contractor 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 support recovery while your customers see a maintenance page. 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 (the same two-factor login code) 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 ownership 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 (a limited-permission login, not the all-powerful root account) 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 contractor 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 (database administrator - the person who manages your production database)." - -The Marcus answer means you have a single point of failure. 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** +The cheapest day to confirm you own your own infrastructure is Day 1, before you hand a credit card to a contractor. The most expensive day is month 14, when production breaks at 9pm and you cannot push a fix because the database password lives in someone else's inbox. In 2025, one founder learned this the hard way: fourteen months into a build, 1,800 paying clinics, a Stripe account in the founder's name - and the AWS root password sitting in the contractor's personal Gmail. It took three emails and six days to get the root account email changed. -> 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. +After this lesson you will be able to: **run a 12-item audit that confirms every credential - code, cloud, secrets, domain - sits under an email and a card you control, and start a recovery plan for any that don't.** -A domain transfer is the slowest recovery on the list. [ICANN's Transfer Policy](https://www.icann.org/en/contracted-parties/accredited-registrars/resources/domain-name-transfers/policy) gives your current registrar up to five days to hand over the transfer auth code, allows a further five-day window for the losing registrar to release the transfer once you request it, and many registrars add a 60-day lock after registration or a recent transfer during which transfers cannot start at all. If someone else 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. +*Ownership* means you control the GitHub org, the AWS root account, the domain registrar, and the production database. A Day-1 audit is what lets you switch contractors on Tuesday without losing access to your own codebase on Wednesday. Open the AWS console right now and click your account name in the top-right corner. Read the email address on the root user. Whose inbox does that land in tonight? -## The 12 items, in four zones (fill-in-the-blank reference) +## The 12 items, in four zones -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/). +The audit covers 12 credentials grouped into four zones. Each item has one pass criterion: an email on a domain you control, a card you own, MFA on a phone in your pocket, and a password in a vault you can read. The full audit - with the exact recovery steps when an item fails - 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 5-day transfer-approval window and the 60-day post-registration lock). DNS = Domain Name System (the address book that points your domain at your servers; the "A record" is the one line that says which server answers). +> **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. DNS = Domain Name System (the address book that points your domain at your servers; the "A record" is the one line that says which server answers). | Zone | Item | Pass Criterion | |---|---|---| @@ -117,91 +78,43 @@ Those three pairs anchor the pattern; the table below is the fill-in-the-blank v | | 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 a contractor can lock you out in ten minutes. Domain registrar turns into a 14-day practical buffer (approval itself takes about five days; the 60-day post-registration lock is the ICANN rule) if someone else will not release the auth code. The other ten matter; these two end the company if they go wrong. +Two of the twelve are existential. **AWS root email** controls whether a contractor can lock you out in ten minutes. **Domain registrar** turns into a 14-day practical buffer (transfer approval itself takes about five days; the 60-day post-registration lock is the ICANN rule) if someone else 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] +![The Friday ownership audit: four numbered checks in a row - Code (are you GitHub org Owner? pass: your email, not the agency's), Cloud (is the AWS root email yours with MFA? pass: root on your domain, MFA on), Secrets (can you read the prod DB password solo? pass: from your vault, no asking), Domain (does WHOIS show you? pass: your name and your renewal email). Any failure drops into one shared amber fix lane naming the fix - Slack the lead engineer for org transfer, self-serve email change or 3-5 day AWS recovery, Secrets Manager or 1Password vault this sprint, registrar transfer with a 14-day buffer plus ICANN escalation. All four fixes converge on one card: recovery plan started this Friday. That leads to one question - did the contractor cooperate, 7 days for code or 14 days for cloud? Yes routes to a green card: audit clean, quarterly recurring block, email investor or board. No routes to a red card: retain a lawyer, $2K-$5K beats a stalled checkout.](ownership-audit-flow.svg) - Cloud -->|Yes, with MFA| Sec["Secrets: can you read the prod
    DB password without asking?"] - Cloud -->|No| FixCloud[Self-serve email change
    or 3-5 day AWS support
    recovery with corp docs] +Most audit failures are sloppy Day-1 setup, not malice - a contractor moving fast in the kickoff sprint who used whatever email was logged in, and nobody went back to clean it up. The [full ownership reference](/course/tech-for-non-technical-founders-2026/reference/ownership-full/) has the good-vs-bad walkthrough for the three items that fail most, the 2026 AI-contractor credential trap, and the exact three-step recovery sequence with the AWS support script and the registrar auth-code request template. - Sec -->|Yes, from your vault| Dom["Domain: WHOIS shows
    your name + 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 as a practical buffer.
    Escalate to ICANN if blocked] - - FixCode --> Recovery[Recovery plan
    started this Friday] - FixCloud --> Recovery - FixSec --> Recovery - FixDom --> Recovery - - Recovery --> Escalate["Contractor cooperated within
    7 days code / 14 days cloud?"] - 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 contractor 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 contractor 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 (intellectual property - your source code and data, legally distinct from an IP network address) | 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 [ownership checklist template](/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 +> **Audit:** +> +> 1. Block 45 minutes on your calendar titled "Ownership audit." Treat it like an investor meeting - phone on Do Not Disturb. +> 2. Open the AWS console first. Top-right, click the account name, click Account, and read the root user email. If it is not on a domain you control, that is your audit's first failure. +> 3. Work down the 12-item table above (or the [printable checklist](/course/tech-for-non-technical-founders-2026/ownership-checklist/)). Record pass or fail for each item. +> 4. For every failure, note the recovery step and start it this sprint. If three or more fail, consider [the 30-day exit guide](/blog/fire-dev-shop-guide/) for a structured transition. +> 5. **Success check:** all 12 items are marked pass or fail, and every failure has a named recovery action with a date - a one-page summary you could forward to your investor or board. -| 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, consider [the 30-day exit guide](/blog/fire-dev-shop-guide/) for a structured transition. | +--- -## Advanced (optional) +**If this fails: the AWS root email belongs to someone else and they won't cooperate.** +- **Why:** AWS treats whichever email is on the root as the legal account holder, so your incorporation paperwork does not move them until support has run its recovery process. +- **Fix:** start the [AWS root account recovery process](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_change-root.html) immediately (3-5 business days). Do not build another line on an account you don't own - the deeper you build, the more expensive the eventual transfer. -| 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 +Whose inbox did the AWS root email land in tonight? If the honest answer is "I'm not sure," that uncertainty is the whole reason this lesson comes before the build, not after. -- 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/en/contracted-parties/accredited-registrars/resources/domain-name-transfers/policy) - the rules every domain registrar must follow when transferring a domain between accounts, including the 60-day lock and the five-day code-release and transfer-release 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:** All 12 items on the ownership checklist are audited, failures are documented, and a recovery plan exists for each failure. +> **Done:** all 12 items on the ownership checklist are audited, failures are documented, and a recovery plan exists for each failure. > -> **You have now:** a quality-checked one-page brief (3.2) + a build-path decision (4.1) + a passed ownership audit, all saved in your `Founder OS` folder. +> **You have now:** a quality-checked one-page brief (3.2) + a build-path decision (4.1) + a passed ownership audit (4.2), all saved in your `Founder OS` folder. The build itself is the next step. > > **Next:** [4.3 · The Self-Serve MVP Stack: Tools & Setup](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) - it builds on the accounts you now own. > -> **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. +> **If blocked:** see "If this fails" above. +> +> **Deeper reference:** [The good-vs-bad walkthrough, the 2026 credential trap, and the full recovery sequence](/course/tech-for-non-technical-founders-2026/reference/ownership-full/) --- diff --git a/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/ownership-audit-flow.svg b/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/ownership-audit-flow.svg new file mode 100644 index 000000000..b35021af5 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/ownership-audit-flow.svg @@ -0,0 +1,150 @@ + + The Friday ownership audit: four checks - GitHub org owner, AWS root email with MFA, prod DB password access, and WHOIS ownership. Any failure routes to a matching fix, then a recovery plan starts that Friday. If the contractor cooperates within 7 days for code or 14 days for cloud, the audit passes: quarterly recurring block, email the investor or board. If not, retain a lawyer - $2K to $5K beats a stalled checkout. + Four numbered check cards in a row. Card 1, Code: are you GitHub org Owner - pass if your email, not the agency's. Card 2, Cloud: is the AWS root email yours with MFA - pass if root sits on your domain with MFA on. Card 3, Secrets: can you read the prod DB password from your vault without asking - pass if you can pull it yourself, no asking. Card 4, Domain: does WHOIS show your name - pass if it shows your name and your renewal email. Below, one shared amber fix lane: if a check fails, fix it there - Code fix is Slack the lead engineer for org transfer; Cloud fix is self-serve email change or a 3-5 day AWS support recovery; Secrets fix is a Secrets Manager or 1Password vault this sprint; Domain fix is a registrar transfer with a 14-day buffer plus ICANN escalation if blocked. Every fix path converges on one card: recovery plan started that Friday. That leads to one question: did the contractor cooperate, 7 days for code or 14 days for cloud? Yes routes to a green card: audit clean, quarterly recurring block, email the investor or board. No routes to a red card: retain a lawyer, 2 to 5 thousand dollars beats a stalled checkout. + + + + + + + + + The Friday ownership audit + Friday afternoon, alone, credit card in hand - four checks, one fix lane, one recovery clock. + + + + + + 1 + Code + GitHub org Owner? + Your email, not the + agency's + + + + + + 2 + Cloud + AWS root yours + MFA? + Root on your domain, + MFA on + + + + + + 3 + Secrets + Read prod DB pw solo? + From your vault, + no asking + + + + + + 4 + Domain + WHOIS shows you? + Your name + your + renewal email + + + + + + + + + + + + If a check fails, fix it right here + + + + + Slack the lead + engineer for org + transfer + + Self-serve email + change or 3-5 day + AWS recovery + + Secrets Manager or + 1Password vault + this sprint + + Registrar transfer, + 14-day buffer + + ICANN escalation + + + + + + + + + + + + Recovery plan started this Friday + + + + + + + + + Did the contractor cooperate? + 7 days for code · 14 days for cloud + + + + + + Yes + No + + + + + Audit clean + Quarterly recurring block. Email investor / board. + + + + + + Retain a lawyer + $2K-$5K beats a stalled checkout. + + 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 index 4a1186436..c694d62d0 100644 Binary files a/content/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/cover.png 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/hire-track-map.svg b/content/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/hire-track-map.svg new file mode 100644 index 000000000..75e69f711 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/hire-track-map.svg @@ -0,0 +1,72 @@ + + The hire track: four stops from the self-serve ceiling to a well-signed first hire. + A left-to-right strip of four numbered cards. Step 1 find your developers: pick a geography and two platforms. Step 2 the Fractional CTO bridge: five hours a week of senior eyes at four hundred to six hundred dollars a week. Step 3 the interview screen: seven questions, where question seven splits the pool. Step 4 read the SOW: the milestone-acceptance clause is the seventy-eight thousand dollar line. Arrows connect each stop to the next. + + + + + + + + + The hire track + Four stops - the self-serve ceiling to a first hire whose contract cannot quietly bleed you. + + + + + + 1 + Find your + developers + pick a geography + + two platforms + + + + + + + 2 + Fractional CTO + bridge + 5 hrs/wk senior eyes + $400-600 a week + + + + + + + 3 + Interview + screen + 7 questions - + Q7 splits the pool + + + + + + + 4 + Read the + SOW + milestone clause + = the $78K line + + + + + + + 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 index 693142499..8f842acee 100644 --- 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 @@ -38,6 +38,8 @@ related_posts: false 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. +![The hire track as a left-to-right strip of four numbered cards: step 1 find your developers - pick a geography and two platforms; step 2 the Fractional CTO bridge - 5 hours a week of senior eyes at $400-600 a week; step 3 the interview screen - 7 questions where Q7 splits the pool; step 4 read the SOW - the milestone clause is the $78K line.](hire-track-map.svg) + --- ## Where to find developers in 2026 @@ -72,32 +74,15 @@ The 2026 hire decision is not "remote vs in office." It is which of four regions **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 -``` +**Which geography for which build** (rate bands and hire cycles are in the four paragraphs above): + +| If your build is... | Route to | Why | +|---|---|---| +| In a regulated industry (HIPAA / SOC 2 / fintech), or your budget sits in the onshore band above | Onshore (US / EU) | Compliance, data-residency, or a board mandate justifies the highest cost-to-output ratio on the map | +| Backend-heavy, async is fine, and you want the lowest rate band above | Tier-2 India - Jaipur, Kochi, Indore, Coimbatore (not Bangalore) | Senior engineers accept 20-30% below Bangalore; PRs merge overnight against your CLAUDE.md | +| Backend-heavy, async is fine, at the mid rate band above | Nearshore (LATAM) | Same async workflow, shorter hire cycle, closer timezone overlap | +| Anything needing live timezone overlap for daily standups | Nearshore (LATAM) | Full US Pacific-to-Eastern overlap; English fluency for standups and Slack | +| A single point task - logo, landing page, one-off scraper | Upwork | Self-vetting marketplace; non-load-bearing work only | ### Six platforms ranked @@ -120,15 +105,13 @@ You do not need a 50% co-founder. You need 5 hours a week of senior judgment to ### 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. +| Job | Time / week | What it catches | +|---|---|---| +| **Architecture review** | 1 hr (Monday) | The contractor proposing microservices - or a separate React frontend + Node API + Python ML service - for an app with 18 paying users. The verdict lands as one paragraph in a Notion doc. | +| **PR review** | 2 hrs | The API key checked into the repo, the n+1 query, the missing CSRF token, the auth bypass on the admin route - the 45% of LLM-generated code Veracode's GenAI Code Security Report 2025 found ships an exploitable security flaw, caught before prod. | +| **Hiring filter** | 1 hr (during a hiring sprint) | A wrong-fit first hire, which costs two months of runway. The FCTO runs the tech screen, reads the candidate's last three commits, and asks the four technical questions you cannot. | +| **Vendor BS detection** | As needed | Kubernetes for 200 users, GraphQL "because REST is old" - the senior "why?" in a room where you are otherwise the only buyer facing three people pitching. | +| **Founder coaching** | 1 hr (Friday) | Translates "Resque is dropping jobs" into "promise the demo for the 12th, not the 5th" - and tells you which feature is one day of work and which is three weeks. | ### Five criteria for hiring a Fractional CTO @@ -154,24 +137,32 @@ Most "Fractional CTO" listings on LinkedIn are either career CTOs in transition > **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. +**First-month onboarding (Day 0 through the Week-4 checkpoint):** + +| Day | What happens | +|---|---| +| **Day 0** | Sign the MSA. | +| **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.5 ceiling signals flip red (Ch 4.5 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: +**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 Lesson 4.5 ceiling signals flip red (Lesson 4.5 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.6 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.6. 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. | +| **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 Lesson 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 Lesson 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 Lesson 5.6 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 Lesson 5.6. 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.5 5-signal scoreboard together. The standing agenda: +First Monday of every month, 60 minutes, the Fractional CTO and you read the Lesson 4.5 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. @@ -204,7 +195,7 @@ You are not picking the stack alone - your Fractional CTO or hired engineer make ### 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. +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: two decades of products on a Rails monolith run by a famously small team, and Shopify serves millions of merchants on one Rails monolith. 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). @@ -252,10 +243,12 @@ Run it after the resume passes, before any technical take-home. The 30-minute sc 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. +| Question pair | Catches the candidate who... | What faking it costs you | +|---|---|---| +| **Workflow + cost (Q1, Q2)** | Has never set up a `.cursorrules` file (the repo's standing instruction file for AI coding tools) or seen a personal Anthropic invoice | Silently runs your monthly AI bill from $200 to $4,800 in their first sprint | +| **Verification + slopsquatting (Q3, Q4)** | Outsources PR review to the model ([slopsquatting](/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/) = installing a fake package the AI invented) | Their name ends up next to the CSRF hole in your incident postmortem | +| **Accountability + refactor (Q5, Q6)** | 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)** | Accepts the model's first suggestion and cannot show one PR where they disagreed with it | This is the one question that actually splits the population - a candidate who directs the model reads the diff, rejects most of it, and can show you the PR comment where they did it | ### The scoring discipline @@ -267,22 +260,13 @@ Send the polite-no email the same evening, not Friday: "Thank you for the time. ## 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. +*"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." In early 2026, one SaaS founder 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. | +For the full 8-clause table - what each clause should say, the red-flag wording, and the exact redline for each - see the [SOW Reading Guide](/course/tech-for-non-technical-founders-2026/sow-reading-guide/). The milestone-acceptance clause below is the one that costs the most; read it before you read the rest. ### The milestone-acceptance redline 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 index a083635dc..5e5fe6dc4 100644 --- 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 @@ -24,11 +24,11 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 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. +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:** +> **Copy-pasteable pre-interview email - send to candidate 24 hours before the call:** > > Subject: `[Date] interview prep - 7 questions` > @@ -42,8 +42,6 @@ related_posts: false > > [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 @@ -54,7 +52,7 @@ Keep this card open during the call or print it: what to listen for (Pass) sits ## 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. +A standard 60-minute behavioural interview clears the candidate who names the right tools, shows a Cursor seat, and has a tidy GitHub profile - and none of that tells you whether the code holds up. You find out three weeks in, once the hire has merged a few PRs and someone reads them: a `gem 'stripe_connect_v2_helper'` line that does not exist on Rubygems, a hardcoded JWT secret in `config/secrets.yml`, a third PR that is the first one copy-pasted with the variable names changed. Replacing the contractor takes ten days; the onboarding hours and the rollback are already spent. The 7-question version below catches that gap on the first 30-minute call, where Q3, Q4, and Q7 are the questions that surface it. ## How to use this @@ -90,9 +88,9 @@ If a candidate refuses to share their screen for Q3 or Q7, that is a Fail on bot ### 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?" +> "In March 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 +- **Pass:** specific defense (allowlist, Socket / Snyk on every PR, manual verification step) + uses the word "slopsquatting" without prompting + cites the 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 diff --git a/content/course/tech-for-non-technical-founders-2026/hiring-interview-script/scorecard-at-a-glance.svg b/content/course/tech-for-non-technical-founders-2026/hiring-interview-script/scorecard-at-a-glance.svg index d433c84c3..e4f7c4639 100644 --- a/content/course/tech-for-non-technical-founders-2026/hiring-interview-script/scorecard-at-a-glance.svg +++ b/content/course/tech-for-non-technical-founders-2026/hiring-interview-script/scorecard-at-a-glance.svg @@ -2,13 +2,13 @@ The 7 hiring questions on one card: pass signal versus fail signal for each 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 index bbf200915..a1d4b27b6 100644 --- 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 @@ -1,7 +1,7 @@ --- 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." +description: "The complete journey from idea to first paying customer at a glance: 5 modules, 20+ lessons, 6 artifacts, and the AI tools that accelerate each stage." date: 2026-06-04 draft: false course_chapter: true @@ -22,15 +22,15 @@ 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." + og_description: "The complete journey at a glance: 5 modules, 20+ lessons, 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/) +> **Overview** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > -> **What this is:** the map - {{< course-stat modules >}} modules, {{< course-stat chapters >}} chapters, {{< course-stat artifacts >}} artifacts, each module's output feeding the next module's input, from rough idea to signed paid pilot. Read it once before Module 1, come back when you need to see where you are. +> **What this is:** the map - {{< course-stat modules >}} modules, {{< course-stat chapters >}} lessons, {{< course-stat artifacts >}} artifacts, each module's output feeding the next module's input, from rough idea to signed paid pilot. Read it once before Module 1, come back when you need to see where you are. 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. @@ -42,13 +42,13 @@ This course takes a non-technical founder from a rough idea to a signed paid pil ![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) -{{< course-stat modules >}} modules. {{< course-stat chapters >}} chapters. {{< course-stat artifacts >}} artifacts you can hand to an investor or a co-founder. Each module's output is the next module's input. +{{< course-stat modules >}} modules. {{< course-stat chapters >}} lessons. {{< course-stat artifacts >}} 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 +### 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 full-time; 2-3 weeks at an evenings-and-weekends pace. @@ -67,10 +67,10 @@ This course takes a non-technical founder from a rough idea to a signed paid pil --- -### Module 2 - Validate the Problem +### Module 2 - Validate the Problem **You have:** a Founding Hypothesis. **You walk away with:** 10 Mom Test interview transcripts + a validated problem statement + a clickable prototype tested with 5 people. -**Time:** ~3-5 weeks full-time - booking the 10 interviews is the long pole (Ch 2.3 plans 2-4 calendar weeks for that step alone). +**Time:** ~3-5 weeks full-time - booking the 10 interviews is the long pole (Lesson 2.3 plans 2-4 calendar weeks for that step alone). | Step | What You Do | Key Tool | |---|---|---| @@ -86,7 +86,7 @@ This course takes a non-technical founder from a rough idea to a signed paid pil --- -### Module 3 - Design from Evidence +### 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 on the calendar - about one evening of writing plus a lunch-break quality check, with a night's sleep between drafts. @@ -100,7 +100,7 @@ The brief is the handoff document. It goes to Lovable, a hired developer, or a f --- -### Module 4 - Build It Yourself +### Module 4 - Build It Yourself **You have:** a one-page Product Brief. **You walk away with:** a build decision + a live MVP at a real URL, with you owning every account. **Time:** ~2-4 weeks. @@ -117,7 +117,7 @@ The brief is the handoff document. It goes to Lovable, a hired developer, or a f --- -### Module 5 - First Paying Customer +### Module 5 - First Paying Customer **You have:** a live MVP at a real URL. **You walk away with:** one signed paid pilot with a real deposit ($500+ standard; 5.6 covers the low-price exception) + a repeatable outbound channel. **Time:** ~2-4 weeks. @@ -199,7 +199,7 @@ If you fail a gate, the system requires you to go back, not forward. Failing at ## 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. +Read the overview once. Then start at [Module 1, Lesson 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're already building, or paying someone to build for you - see the [Already started building?](/course/tech-for-non-technical-founders-2026/#already-started-building) section on the course landing page. 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 index a1f2774bc..4de0c6bb1 100644 --- 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 @@ -2,12 +2,12 @@ 5-module course pipeline: Hypothesis → Validate → Design → Build → First Paying Customer @@ -60,7 +61,7 @@ 1.4 Smoke test run - 6.5% + 6.5% 300 visits · Promising @@ -70,7 +71,7 @@ 1.5 Price test - 6 buyers + 6 buyers $99 each $594 before product 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 index e43bc4b00..6bf72d653 100644 --- 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 @@ -11,11 +11,11 @@ metatags: og_title: "Module 1 Walkthrough: Mia Builds TutorMatch" course_nav_prev: slug: price-hypothesis-on-smoke-test-page - module: "Chapter 1.5" + module: "Lesson 1.5" title: "1.5 · Price Your Hypothesis on the Smoke-Test Page" course_nav_next: slug: mom-test-ask-about-past-not-future - module: "Chapter 2.1" + module: "Lesson 2.1" title: "2.1 · The Mom Test: Ask About the Past, Not the Future" --- @@ -43,7 +43,7 @@ She closed the doc and opened Reddit. r/Dyslexia. She searched "tutor." The thir > *"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 the post into her notes. The blanks she'd left empty an hour earlier suddenly had specific names. The [customer] wasn't "parents" - it was parents of kids 8-14 with dyslexia or ADHD. The [problem] wasn't "finding tutors" - it was *finding a vetted specialist tutor*. The [competition] wasn't Google the company - it was the exact behavior the Vermont mother had described: Googling and calling dead numbers. By midnight her hypothesis read: +Mia copied the post into her notes. The blanks she'd left empty an hour earlier suddenly had specific names. The `[customer]` wasn't "parents" - it was parents of kids 8-14 with dyslexia or ADHD. The `[problem]` wasn't "finding tutors" - it was *finding a vetted specialist tutor*. The `[competition]` wasn't Google the company - it was the exact behavior the Vermont mother had described: Googling and calling dead numbers. By midnight her 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."* @@ -89,7 +89,7 @@ She had $400 to spend, a Growth lens that scored only 3/5, and a quiet knot in h She installed the Meta Pixel she'd deferred from 1.3. Same dance as Clarity and GA4, two minutes this time - the wrong-field detour had taught her where to click. -Then the ads. Her first instinct was to split the budget - $200 on "dyslexia tutor" search interest, $200 on "ADHD tutor near me" in her city, and let the two angles fight it out. The channel guide's sample-size warning killed that plan: $200 buys roughly 150 visits, and below 300 visits a conversion rate can't tell 2% from 5%. Two half-tests would have bought her two unreadable numbers. She put the full $400 behind one angle - the specialty search, because that was the bet her hypothesis actually named: parents searching by their kid's need, not by zip code. The location question went into her notebook, not her ad account. She hit Launch on a Monday morning. +Then the ads. Her first instinct was to split the budget - $200 on "dyslexia tutor" search interest, $200 on "ADHD tutor near me" in her city, and let the two angles fight it out. The channel guide's sample-size warning killed that plan: $200 buys roughly 150 visits, and below 300 visits a conversion rate can't tell 4% from 5%. Two half-tests would have bought her two unreadable numbers. She put the full $400 behind one angle - the specialty search, because that was the bet her hypothesis actually named: parents searching by their kid's need, not by zip code. The location question went into her notebook, not her ad account. She hit Launch on a Monday morning. Then she made a rule for herself: don't touch the page for seven days - no headline tweaks, no bid adjustments, and none of the anxious dashboard refreshing she knew she'd be tempted by. The point of a smoke test was a clean signal, and a clean signal needed clean traffic. @@ -122,7 +122,7 @@ She added a note to her Module 2 prep: when she interviewed parents, she'd ask w - **Six paying customers at $99 each.** $594 in revenue, before the product existed. - **A Google Drive folder** holding all five Module 1 outputs. Her Founder OS, started. -**Next: [Module 2, where Mia interviews ten parents using the Mom Test](/course/tech-for-non-technical-founders-2026/module-2-walkthrough-mia/).** Her interview script will ask whether parents have ever spent real money on a specialist tutor search (the [problem] blank in her hypothesis), and what they currently pay - so she can replace her Money lens guess with actual numbers from actual receipts. +**Next: [Module 2, where Mia interviews ten parents using the Mom Test](/course/tech-for-non-technical-founders-2026/module-2-walkthrough-mia/).** Her interview script will ask whether parents have ever spent real money on a specialist tutor search (the `[problem]` blank in her hypothesis), and what they currently pay - so she can replace her Money lens guess with actual numbers from actual receipts. --- diff --git a/content/course/tech-for-non-technical-founders-2026/module-2-walkthrough-mia/artifact-trail.svg b/content/course/tech-for-non-technical-founders-2026/module-2-walkthrough-mia/artifact-trail.svg index b4af11c69..22626b3f5 100644 --- a/content/course/tech-for-non-technical-founders-2026/module-2-walkthrough-mia/artifact-trail.svg +++ b/content/course/tech-for-non-technical-founders-2026/module-2-walkthrough-mia/artifact-trail.svg @@ -2,13 +2,13 @@ Mia's Module 2 artifact trail: a Mom-Test script to a 30-name list to 10 scored interviews to a BUILD verdict to a Money answer to prototype feedback diff --git a/content/course/tech-for-non-technical-founders-2026/module-5-walkthrough-mia/index.md b/content/course/tech-for-non-technical-founders-2026/module-5-walkthrough-mia/index.md index 5a67c5998..a3e748655 100644 --- a/content/course/tech-for-non-technical-founders-2026/module-5-walkthrough-mia/index.md +++ b/content/course/tech-for-non-technical-founders-2026/module-5-walkthrough-mia/index.md @@ -11,7 +11,7 @@ metatags: og_title: "Module 5 Walkthrough: Mia Gets Paid" course_nav_prev: slug: paid-pilot-charge-before-ship - module: "Chapter 5.6" + module: "Lesson 5.6" title: "5.6 · Charge Before You Ship: The Paid Pilot Contract" course_nav_next: url: "/course/tech-for-non-technical-founders-2026/#going-further-after-first-paying-customer" 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 index 3705d5b72..764aab3a6 100644 --- 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 @@ -1,7 +1,7 @@ --- 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." +description: "Lesson 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 @@ -23,7 +23,7 @@ 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." + og_description: "Lesson 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 @@ -31,189 +31,87 @@ related_posts: false > **Module 2 · Lesson 2.1 · [CORE]** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > -> **Input:** a Founding Hypothesis sentence (from Ch 1.1) + your `[customer]` blank from that sentence (the role, company size, and situation it names - that description is your ICP, your Ideal Customer Profile) +> **Input:** a Founding Hypothesis sentence (from Lesson 1.1) + your `[customer]` blank from that sentence (the role, company size, and situation it names - that description is your ICP, your Ideal Customer Profile) > -> **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-2.4 recruitment. The scoring rubric becomes your reference card once you have transcripts in hand. +> **Output:** the 5-question Mom Test template + a draft question list (5-8 questions) ready to sharpen in Lesson 2.2 and then run in real interviews after Lesson 2.3-2.4 recruitment. The scoring rubric becomes your reference card once you have transcripts in hand. > > **Progress:** M2 · 1 of 6 · Results so far: all Module 1 artifacts - Module 2 starts here -> **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-2.4 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 ten interviews where the only question is "would you pay for this?" and you'll close the week with a stack of 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. +Run ten interviews where the only question is "would you pay for this?" and you'll close the week with a stack of yeses and an empty launch. The technique below switches every question to the past tense - what did you do last time, what did it cost, show me the spreadsheet - because whoever paid in the past keeps paying, and whoever did nothing will keep doing nothing no matter what they promise you over coffee. After this lesson you will be able to: **write interview questions that ask about past behavior - so the answers tell you what people actually did, not what they would politely promise.** -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-2.4](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/). +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. ![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) +## The 5 questions -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. +Every question a first-time founder writes first feels like it gets to the truth - and each one is built to surface a polite lie. The fix is the same each time: switch to past behavior. Read the rewrites as written; "would you" instead of "did you" flips the answer back into hypothetical polite. | 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?" | +| "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. | "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 (virtual assistant), 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. +| "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?" | -### Q4: "On a scale of **1-10**, how big a problem is this compared to everything else on your plate?" +What a passing answer sounds like, versus a polite one, on the very first question: -- **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?"* +- **Fail (polite):** *"Yeah I usually struggle with reporting."* No date, no mechanic - autopilot polite mode. +- **Pass (real 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. -### Q5: "**Who else** on your team feels this? How do they handle it?" +**The first answer is always thin - excavate.** Ask "tell me about the last time" and most people answer at the surface: *"Oh, last night after dinner."* Help them re-enter the moment and walk it forward - *"Where were you? What happened right before? What did you do next?"* - until the actual sequence comes out. Then stop talking. Leave a few seconds of silence; the pause is uncomfortable enough that people fill it with the detail they were about to skip. (Teresa Torres calls this story excavation.) -- **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. +The [full Mom Test reference](/course/tech-for-non-technical-founders-2026/reference/mom-test-full/) has the pass/fail signal and follow-up for all five questions, plus the interview flow and the score-and-recover routine. -![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) +## Score each call with the 3 emotional flags -## 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. +While the script runs, listen for three patterns. They do more work than the words "yes" and "no." | 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[Emotional flags?] - Listen -->|0-1 flags| Generic[Polite mode -
    ask the follow-up, retry Q1] - Listen -->|2+ flags| Rest[Real felt problem -
    run Q2 - Q5 in order:
    cost, tried, 1-10 priority, who else] - Generic --> Q1 - Rest --> Score[Score the call 1-10] - Score -->|7+ with comparison, 3+ flags| Validated[Strong signal -
    ask for intro + prototype] - Score -->|5-6 or weak flags| Weak[Polite default - score as 5] - Score -->|0-4 or 0 flags| Fail[No felt problem - discount] - Validated --> Next[After 10 calls:
    7+ scores of 7+ = 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,Rest 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. - -Expect your first two or three interviews to feel awkward - you will catch yourself pitching at least once. That's normal, not failure: score the contaminated call honestly (in the [Module 2 walkthrough](/course/tech-for-non-technical-founders-2026/module-2-walkthrough-mia/), Mia breaks her own script in interview one, scores it 3/10, and keeps the other nine clean). The skill is in the recovery, not in being perfect on call one. - -One more failure mode worth naming: an interviewee with no story. If Q1 produces genuine blankness - not evasion, just no last time to walk through - they don't have the problem. End the call politely at the 10-minute mark and count it: a person who was supposed to be your customer and has no story IS data about your [customer] blank. - -## 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. | - -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 **[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 (score them on [Chapter 2.5: Mom Test Synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/), then proceed to 2.6) or 10 transcripts that don't (follow Chapter 2.5's pivot path: sharpen the ICP and run 5 more interviews against the narrower group). +| **Frustration language** | "I hate this." "It drives me crazy." "Every single week." | 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." | The interviewee already spent time or money on a solution that doesn't fully work. That 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 one that happens "sometimes." Time-anchored urgency is the strongest signal in the set. | -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. +**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. This 1-10 score per call is what Lessons 2.4-2.6 count to make the build / pivot / kill decision, so score every call the same way. -> Customer interviews usually fail because the interviewees are polite. The questions do more work than interviewer charisma ever will. -> -> 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 tier) gives you an adversarial dialog: paste your draft question list, and it pushes back the way a skeptical interviewee would. +> **Write:** > -> 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? +> 1. Open a new Google Doc titled `Mom Test draft - [date]` in the same `Founder OS` folder as your Founding Hypothesis. +> 2. Copy the 5 verbatim rewrite questions from the table above. +> 3. 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?"). +> 4. **Success check:** you have a 5-8 question list, every question anchored in a past event, none asking "would you." > -> 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. +> That list is the input Lesson 2.2 sharpens against AI personas. + +--- -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. +**If this fails: your questions still sound hypothetical.** +- **Why:** a question asks the interviewee to predict, rate, or evaluate instead of recount a specific past event. +- **Fix:** rewrite it to start with "Tell me about the last time..." or "Walk me through what you did when...". If you can't anchor it to a past moment, cut it. -## Further reading +--- + +Read your draft list aloud. Which question would let a polite stranger agree without ever having lived the problem? Rewrite that one first - it's the one most likely to hand you a false yes. -- 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) - 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. +--- > **Done:** you understand the 5 Mom Test questions, can spot hypothetical phrasing, and have a draft question list (5-8 questions) anchored in past behavior. > -> **You have now:** all Module 1 artifacts + a draft Mom Test question list (2.1). Sharpening and recruiting come next. +> **You have now:** all Module 1 artifacts + a draft Mom Test question list (2.1). Sharpening and recruiting come next - the problem itself isn't validated until you run the 10 real interviews. +> +> **Next:** [2.2 · Sharpen Your Question List with AI Personas](/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/) - takes the draft list you just wrote and stress-tests each question against a simulated ICP before you spend a real interview slot on it. > -> **Next:** [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:** open the [Mom Test Interview Script](/course/tech-for-non-technical-founders-2026/mom-test-interview-script/) - it has the 5 questions verbatim with follow-ups. > -> **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. +> **Deeper reference:** [Per-question pass/fail signals, the interview flow, and the score-and-recover routine](/course/tech-for-non-technical-founders-2026/reference/mom-test-full/) --- 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 index c8b60637f..cf3a4bde4 100644 --- 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 @@ -24,18 +24,19 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 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 +Template companion to the [Lesson 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. *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? +**The 5 Mom Test questions, in order:** + +| Question | What it surfaces | +|---|---| +| **Q1.** Tell me about the last time [problem] happened. Walk me through what you did. | Anchors in a real episode - story over preference. | +| **Q2.** What did that cost you - in time, money, or sanity? | Quantifies the pain - an unquantified problem won't get paid for. | +| **Q3.** What have you tried already to fix this? | Surfaces existing workarounds - if they never tried anything, it never actually hurt. | +| **Q4.** On a scale of 1-10, how big a problem is this compared to everything else on your plate? | Calibrates urgency against the interviewee's whole problem stack - most "would be great if" problems land at 4. | +| **Q5.** Who else on your team feels this? How do they handle it? | Surfaces the buying committee and workarounds other people on the team already own. | *Prefer paper? Download the PDF - same content, print-ready.* @@ -55,13 +56,13 @@ Time budget: 25 minutes for the questions, 5 minutes for scoring notes. Total 30 *Anchors in a real episode - story over preference.* -> "Tell me about the last time [problem context] happened. Walk me through what you did." +> "Tell me about the last time [problem] 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?" +**Follow-up (excavate):** "Walk me through that specific Tuesday again. What did you do first?" The first answer is always thin, so keep going: "Where were you? What happened right before? What did you do next?" Then stop and let the silence sit - people fill it with the detail they were about to skip. ### Q2 - The cost question @@ -91,7 +92,7 @@ Time budget: 25 minutes for the questions, 5 minutes for scoring notes. Total 30 *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?" +> "On a scale of 1-10, how big a problem is this 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. @@ -148,7 +149,7 @@ The bad closing pulls them back into hypothetical preference and gives you a use - **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 7 or more of your 10 interviews scored 7+:** the problem is validated - BUILD. Move to the [Mom Test Synthesis page](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) and the Validated Problem Statement template. - **If 4 to 6 scored 7+:** PIVOT - re-evaluate the ICP, the problem framing, or the question wording, then book 5 sharper interviews with the narrower group. Sometimes Q1 is wrong (the problem context is too narrow) - retry with broader phrasing first. -- **If fewer than 4 scored 7+:** KILL - the problem is too weak for this customer. Return to Ch 1.1 with a different [customer] or [problem] blank. +- **If fewer than 4 scored 7+:** KILL - the problem is too weak for this customer. Return to Lesson 1.1 with a different [customer] or [problem] blank. - **Forward the transcripts to your founder friend one step ahead, or a peer from any founder community** 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. diff --git a/content/course/tech-for-non-technical-founders-2026/mom-test-interview-script/mom-test-interview-script.pdf b/content/course/tech-for-non-technical-founders-2026/mom-test-interview-script/mom-test-interview-script.pdf index 31b8212d9..353f0a0e4 100644 Binary files a/content/course/tech-for-non-technical-founders-2026/mom-test-interview-script/mom-test-interview-script.pdf and b/content/course/tech-for-non-technical-founders-2026/mom-test-interview-script/mom-test-interview-script.pdf 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 index d20b7f89e..7b525e671 100644 --- 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 @@ -31,7 +31,7 @@ related_posts: false > **Module 2 · Lesson 2.5 · [CORE] - run after your 2.4 interviews** · [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-2.4](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/)) +> **Input:** 10 scored Mom Test transcripts (from [Lesson 2.1](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/)) + completed interviews (from [Lesson 2.3-2.4](/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 > @@ -39,39 +39,35 @@ related_posts: false > **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-2.4 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-2.4](/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. +> **You should be here AFTER your Lesson 2.3-2.4 interviews are done.** No 10 scored transcripts in hand? Return to [Lesson 2.1](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) for the technique, then [Lesson 2.3-2.4](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) for recruitment. This 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. +After 10 interviews you have scored transcripts in a folder and a number. Synthesis is the 90-minute step that turns them into the one-page validated problem statement you carry into Module 3. Skip it and go straight to Lovable, and you have a folder and a hypothesis - not a validated problem. ## 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. +Ninety 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. +**Step 1 - Score each interview 1-10.** Combine your handwritten Q4 score and your emotional-flag count from the [Lesson 2.1 script](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) into one number. A **7+** means a Q4 of 7 or higher backed by a comparison (a polite-default 7 with no comparison rounds down to 5), plus at least 3 emotional-language flags across the five answers. A **4-6** is partial signal - a real story but a weak workaround. **Below 4** is polite-yes mode: vague answers, "nothing yet" on past attempts, a hedged Q4 under 7. Write the number on each transcript within 5 minutes of hanging up - it's more honest than the one you'd write after a week of wanting it higher. -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.** List the 10 scores in a column and circle every 7 or higher. That circled count routes your decision. The pattern beats the average: eight 7+ and two 3s is a shared problem; three 9s and seven 4s is the dangerous one - you talked to your three best friends and seven strangers told you the truth. -**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. +**Step 3 - Write the one page.** Open the [Validated Problem Statement Template](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/) and fill five sections in 30 minutes: who has the problem, what it costs them, what they've tried, why now, and how big the pain is. One side of paper. Spill onto a second page and the persona is too broad. The template carries the field-by-field walkthrough and the good/bad worked examples. ## 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'}}}%% +%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, Comic Sans MS, 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
    Test the shape in Ch 2.6
    then write the Ch 3.1 brief] + S4 -->|7 or more| Build[BUILD
    Test the shape in Lesson 2.6
    then write the Lesson 3.1 brief] S4 -->|4 to 6| Pivot[PIVOT
    Run 5 more interviews
    Refine the ICP first] - S4 -->|Fewer than 4| Kill[KILL
    Rewrite the hypothesis in Ch 1.1
    then re-run Ch 2.3] + S4 -->|Fewer than 4| Kill[KILL
    Rewrite the hypothesis in Lesson 1.1
    then re-run Lesson 2.3] Build --> Sign[Show to 2 advisors.
    Get 2 signatures before building.] Pivot --> Sign Kill --> Sign @@ -93,36 +89,37 @@ flowchart TD 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 travels with you into [2.6 · Build a Clickable Prototype](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/) to test the shape, and from there into [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 your 5 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 the 5 say yes, you have validation with money attached - the strongest signal there is. If 0 of the 5 say yes, the 7+ scores were politer than you thought. +**7+ strong signals: build.** 70%+ of a stranger sample confirmed the problem with felt urgency. Before you write code, run the 3 pre-orders test: ask your 5 strongest-signal interviewees for a pre-order, a paid letter of intent, or a deposit. 3 of 5 yes is validation with money attached; 0 of 5 means the scores were politer than you thought. The statement then travels into [2.6 · Build a Clickable Prototype](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/) to test the shape. -**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. +**4-6 strong signals: pivot.** Partial signal - usually an ICP problem, not a problem problem. Sharpen the ICP definition and run 5 more interviews against the narrower group. Those 5 interviews cost a week; a built MVP against a fuzzy ICP costs 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. Return to [1.1 · Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/), rewrite the weakest blank using what the dead transcripts taught you, then rebuild your list in [2.3 · Find 10 People: Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/). +**Below 4 strong signals: kill.** Strangers were polite. Note what you learned about the wrong ICP, framing, or trigger, then return to [1.1 · Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/), rewrite the weakest blank from your dead transcripts, and rebuild your list in [2.3 · Find 10 People: Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/). ## 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. +> **Bad** - 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. +> **Good** - 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 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 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 good statement has a named industry, a 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 yours 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. +The [Validated Problem Statement Template](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/) is the artifact for this lesson. 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. +> **If this fails:** the numbers won't settle - a call feels like both a 7 and a 5. **Why:** you're scoring the Q4 number alone, without the comparison test and the flag count. **Fix:** re-read [Lesson 2.1's scoring rubric](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) - a 7 needs a comparison behind it plus 3+ emotional flags, or it rounds to 5. --- > **Done:** you have a build / pivot / kill decision backed by your strong-signal count, and a one-page validated problem statement. > -> **You have now:** question list (2.1-2.2) + 30-name list (2.3) + 10 scored interviews (2.4) + the build/pivot/kill decision. The orientation pages state this gate as "7 of 10 interviewees have spent time or money on the problem" - the two are the same bar, because a transcript cannot score 7+ without real past spend surfacing in Q2/Q3. +> **You have now:** question list (2.1-2.2) + 30-name list (2.3) + 10 scored interviews (2.4) + the build/pivot/kill decision. The orientation pages state this gate as "7 of 10 interviewees have spent time or money on the problem" - the same bar, because a transcript cannot score 7+ without real past spend surfacing in Q2/Q3. +> +> **Next:** If build - [2.6 · 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 - sharpen the `[customer]` blank, then rebuild your list in [2.3 · Find 10 People: Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/). 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/), rewrite the weakest blank, then re-run 2.3. +> +> **If blocked:** see "If this fails" above. > -> **Next:** If build - [2.6 · 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 - sharpen the [customer] blank of your hypothesis, then return to [2.3 · Find 10 People: Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) to rebuild your list around that narrower group. 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.3. -> **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. +> **Deeper reference:** [Validated Problem Statement Template](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/) - the field-by-field synthesis walkthrough, good/bad worked examples for every section, and the advisor sign-off sheet. --- 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 index d05d2a6db..8d0d6c362 100644 --- 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 @@ -31,7 +31,7 @@ related_posts: false > **Module 5 · Lesson 5.1 · [CORE]** · [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.4 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.4 outreach](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) for 10 more before re-attempting this survey. +> **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.4 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 [Lesson 2.4 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 > @@ -39,56 +39,23 @@ related_posts: false > **TL;DR:** Before you buy traffic, 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. -Here is the failure mode this lesson exists to prevent. A founder's Lovable MVP goes live. Forty people from a beta list poke at it. The dashboard says 0.4% conversion on $4,200 of Meta ads, and instinct says "scale the top of funnel." +--- -The dashboard tells that founder what five phone calls would have said for free: most users never opened the app twice. You are two weeks and zero ad dollars away from that fork - this lesson is how you take the other path. +A founder's MVP goes live, 40 beta users poke at it, and the dashboard shows 0.4% conversion on $4,200 of Meta ads. That dashboard just told the founder what five phone calls would have said for free: most users never opened the app twice, and no ad budget turns that group into customers. -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. +After this lesson you will be able to: **run the 5-question Sean Ellis survey against your earliest users and name the one segment worth selling 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" → that segment is not must-have; do not scale it. Run more interviews before re-attempting. -> - 3-4 "very disappointed" out of 6 → directional MAYBE. Almost certainly a sample-size problem, not a product problem; book 5-10 more users. -> - 5+ "very disappointed" out of 6 → directional STRONG YES. Advance to M5.3 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 ([transcript and replay here](https://www.lennysnewsletter.com/p/the-original-growth-hacker-sean-ellis)). - -![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, cleared the bar, and then spent on ads. - -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 +Sean Ellis ran growth at Dropbox, LogMeIn, and Eventbrite, and kept seeing the same dividing line between products that ignited and products that needed life support. He surveyed each product's existing users with one 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% said "very disappointed," the product could almost always grow on outbound and word of mouth alone. Under 40%, growth stalled until the product changed. Ellis explained the cutoff and wording on [Lenny Rachitsky's podcast](https://www.lennysnewsletter.com/p/the-original-growth-hacker-sean-ellis). -The KISS path is a free Typeform or Tally form and a CSV export. No Rails webhook, no Postgres table, no engineer. +![Semicircular gauge of the share of users answering very disappointed: amber below the 40% line means product problem, green at 40% or more means a must-have user](sean-ellis-gauge.svg) -### 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. Treat anything under ten responses as directional only. 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 +Use a free [Typeform](https://www.typeform.com) or [Tally](https://tally.so) form and a CSV export - no engineer needed. Survey people who used the product recently. Strip out anyone who signed up and never logged in twice (they can't answer), and the friends and family you onboarded as moral support (they'll all say very disappointed and tell you nothing). +## The 5 questions, verbatim Open Typeform or Tally. Five questions, in this order. Wording matters - changing a word changes the answer. @@ -105,117 +72,48 @@ Open Typeform or Tally. Five questions, in this order. Wording matters - changin > *(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 +> *(Two short text fields. Drives the segment slice.)* -Email subject line that works in 2026: *"Quick 90-second question about [product]"*. Body, three lines: +Do not add a sixth question. Do not soften Q1 to "How disappointed would you be" - the original wording forces the user to pick a side. -> 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: +## Score it -```text -must_have_pct = ("Very disappointed" count) / (total responses excluding "No longer use it") -``` +Export the CSV. Compute the "very disappointed" share, excluding "no longer use it" answers (they are churned users, not should-be-paying users). Pull three numbers: **overall must-have %**, **per-segment must-have %** (slice by job title and company size - one segment is almost always higher than the average, and that is your must-have segment), and **three verbatim Q2-Q3 quotes** from that segment. Those quotes are your persona, your ad copy, and your cold-email opener for Lesson 5.3. -The "no longer use it" answers come out of the denominator. They are churned users, not should-be-paying users. +Lay this segment beside the persona in your [Lesson 2.5 validated problem statement](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/). If real usage points at a different segment than the interviews did, that is a real correction - write the delta down; don't keep two personas. -Pull three numbers: +## Read the result -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. +The Sean Ellis test is directional at **≥ 10 respondents**, useful at **20+**, and segment-sliceable at **30+**. Under 10, read your count as a hypothesis, not a verdict, and use it to prioritize the next outreach batch. Then: -![Segment isolation Venn - what an average hides and what one slice reveals](segment-isolation.svg) +- **Under 25% overall:** product problem. Talk to 5 "very disappointed" users and find what you missed. +- **25-40%:** check whether any single segment clears 40%. If one does, target it and rebuild the persona on its quotes. +- **Over 40% in any segment:** you have a must-have user. [Lesson 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) outreach starts here. -### 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.3 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 - with 6 "very disappointed" out of 10 the threshold says PASS, but the confidence band is wide enough that real demand could be 20% or 80%. Under 10, segment-slice math does not work and the 25-40% bands do not apply. Read the count directionally instead: -> -> - **0-2 "very disappointed"**: 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.3 but caveat your outreach decisions - the segment language is hypothesis, not verified. +> **Do this now:** > -> Use an under-10 reading to prioritize the next outreach batch, not to advance into Module 5.3 with confidence. +> 1. Export your users CSV. Strip the friends-and-family and the never-returned users. Annotate each row with job title and company size. +> 2. Open Typeform or Tally. Type the five questions above verbatim. +> 3. Send the email. Subject: *"Quick 90-second question about [product]"*. Re-send a few days later to non-openers. +> 4. Export the responses. Compute overall must-have % and per-segment must-have %. +> 5. Paste three Q2-Q3 verbatims from your top segment into a Google Doc. +> 6. **Success check:** you have a headline %, a top-segment %, and 3 verbatim quotes - and you know whether any segment cleared 40%. -## 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.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) 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.5](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) 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.4 outreach](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) (with the list-building method from [2.3](/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.3 or decision on pivot | -| **5** | If above 40% in any segment, move to [Chapter 5.3 personal-network outreach](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/). 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 | +**If this fails: under 10 users responded.** +- **Why:** your sample is too small to read, and segment-slice math does not work. +- **Fix:** book 5-10 more user sessions with the [Lesson 2.3](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/)-[2.4](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) outreach playbook and re-run the survey. Treat looping back for more sessions as the default first-pass move, not a setback. -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. +Treat the answer as a stop sign, not a market-research instrument. Under 40% means the next thing on your calendar is five user calls, not a Meta Ads brief. -## Further reading +The full survey template (Typeform-import 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/). -- Lenny Rachitsky, [The original growth hacker, Sean Ellis, on the 40% test](https://www.lennysnewsletter.com/p/the-original-growth-hacker-sean-ellis) - 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/2009/08/31/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. +> **Deeper reference:** [The full must-have survey walkthrough](/course/tech-for-non-technical-founders-2026/reference/must-have-survey-full/) - who to survey and who to strip, the send email, the per-segment scoring math, the decision tree, the under-40% diagnostic table, and the read-by-count guide. > **Done:** 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. > @@ -223,7 +121,7 @@ Treat the answer as a stop sign rather than a market-research instrument. Under > > **Next:** the core path continues at [5.3 · Build Your 50-Name Network List](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) - it turns the named segment into the first 50 people you will message. If you are not sure where your buyers actually spend their time, read the optional [5.2 · channel selection](/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/) first. > -> **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-2.4 outreach playbook and re-run the survey. +> **If blocked:** if under 10 users responded, your sample is too small to read. Book 5-10 more user sessions using the Lesson 2.3-2.4 outreach playbook and re-run the survey. --- 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 index 71f04d532..b48f6d741 100644 --- 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 @@ -1,59 +1,64 @@ - - The Sean Ellis 40% threshold: where founder paid-ads instinct fails and where it does not + + The Sean Ellis 40% gauge: the share of your first users who would be "very disappointed" without the product, with 40% as the pass line. + A semicircular meter reading 0 to 100 percent of "very disappointed" survey answers. A bold red line marks the 40 percent threshold. The arc left of the line is amber (under 40 percent, a product problem); the arc right of the line is green (must-have segment, go sell). A needle points into the green zone. - - - - "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%. + + "How would you feel if you could no longer use it?" + Gauge = % of your first 10-30 users who answer "very disappointed" + + + + + + + + 40% + THE LINE + + + 0% + 100% + + + + + + + + UNDER 40% + Product problem, + not a marketing one. + More ads won't fix it - + talk to the "very disappointed". + + + + 40% OR MORE + You have a must-have user. + Outreach beats paid ads - + go find more of them + and start selling. + + + Run the survey before you buy any ads - 5 questions, free on Typeform or Tally. 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 deleted file mode 100644 index 79678cab5..000000000 --- a/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/segment-isolation.svg +++ /dev/null @@ -1,45 +0,0 @@ - - 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/index.md b/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/index.md index 7ce465f61..c03d78a12 100644 --- 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 @@ -1,7 +1,7 @@ --- 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." +description: "The five sections your Lovable prompt or hired junior actually needs. Free Lesson 3.1 of the From Idea to First Paying Customer course." date: 2026-05-18 draft: false course_chapter: true @@ -23,7 +23,7 @@ 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." + og_description: "The five sections your Lovable prompt or hired junior actually needs. Free Lesson 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 @@ -31,166 +31,71 @@ related_posts: false > **Module 3 · Lesson 3.1 · [CORE]** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > -> **Input:** a one-page validated problem statement (from [Ch 2.5 · Mom Test Synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/), after running interviews in Ch 2.3 + 2.4) + verbatim "describe in one sentence" vocabulary (from your [Ch 2.6 prototype sessions](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/)) +> **Input:** a one-page validated problem statement (from [Lesson 2.5 · Mom Test Synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/), after running interviews in Lesson 2.3 + 2.4) + verbatim "describe in one sentence" vocabulary (from your [Lesson 2.6 prototype sessions](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/)) > > **Output:** a one-page Product Brief (Vibe PRD) you can hand to [Lovable](https://lovable.dev) (an AI app builder that turns a plain-English prompt into a working web app) or a hired team > > **Progress:** M3 · 1 of 2 · Results so far: a validated problem statement (2.5) + a prototype pass/fail with user vocabulary (2.6) - this page turns them into the one page Module 4 builds from -> **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 - 12 had no backend code and 2 crashed on toggle. The Vibe PRD she wrote next listed the 5 settings she actually needed, and 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. - -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 paid multi-week Maven cohort; 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) +Hand an AI agent or a junior a vague brief and they fill every blank from training data - the busiest big-company version of whatever you half-described. One page, five sections, written in one focused sitting, is how you forbid that before the build starts. -## Who reads it: an AI agent or a hired junior, not a 6-person team +After this lesson you will be able to: **write a one-page Product Brief that names the user, the one problem, the one workflow, the one metric, and everything you are NOT building - so an AI agent or a hired junior builds only what you asked for.** -| 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 | +The Product Brief - some founders call it a **Vibe PRD** (PRD stands for Product Requirements Document) - is one side of paper. It names the user, the problem, the one workflow you are building, the one metric you will measure, and what you are explicitly NOT building. -[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. +![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) ## 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 your Chapter 2.5 synthesis) - -What goes in it: one paragraph copied directly from your [validated problem statement](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/). Named persona, named industry, dated 10-call sample, one verbatim quote, one quantified cost, and the one-line why-now from your problem statement. - -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 full of 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 (a plain spreadsheet-style file exported from Stripe) 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 (they type their email and click a one-time sign-in link - no password to build or store). 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.* +Five sections, in this order: *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. -Common mistake: listing three metrics (signups, retention, a satisfaction score) 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) (an AI coding tool developers run on their own machines), 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(["Brief written"]) - Start --> Q1{Who builds
    from it?} - Q1 -->|AI agent| Vibe1[Vibe PRD
    hand as-is] - Q1 -->|Hired junior| Vibe2[Vibe PRD
    + kickoff call] - Q1 -->|Senior engineer| Trad1[Traditional PRD
    3-5 pages] - Q1 -->|Committee / board| Trad2[Traditional PRD
    5-10 pages] - Vibe1 --> Ship1[Short build loop] - Vibe2 --> Ship1 - Trad1 --> Ship2[Long build loop] - 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 classic trap 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 a paid cohort course is worth it - -Drew Falkman runs "Vibe Coding Data-Enabled AI Apps" on Maven, a multi-week live cohort (paid - check the course page for current pricing and format). 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. - -| Scenario | Maven cohort is worth it | This template is enough to start | +| # | Section | What goes in it | |---|---|---| -| 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 much of its time on exactly this. | No. You'll need the stack tutorials anyway; the template is concept-only. | -| You can sit alone for 90 minutes 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. | +| **1** | The problem | One paragraph copied **word-for-word** from your [Lesson 2.5 validated problem statement](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/). Named persona, dated 10-call sample, one verbatim quote, one quantified cost. | +| **2** | The user and their context | Who the user is *while* using your product - the 60 seconds before they reach for it and the 60 seconds after. Not their life story. | +| **3** | What you're building | One plain-English paragraph, verb-led. Names the input the user gives and the output they get back. No feature list. | +| **4** | Success metric | One number, one unit, one timeframe. Measurable inside the app, not from your gut. | +| **5** | What you're NOT building | 5 to 8 lines naming what a competent agent or junior might add unprompted that you do not want in v1. The longer this list, the cheaper your build. | -**Rule of thumb:** If you can sit alone for 90 minutes and finish the brief, start here. The cohort buys structure, deadline, and stack depth. If you can't sit alone, the cohort fee buys the accountability that gets the brief out of you. +Each of the five sections is 2-4 sentences in plain English. Section 5 (the no-go list) is 5-8 bullet lines. Total brief ≤ 250 words on one side of paper. If you spill past 250 words, the persona is too broad or the pain is too vague - revise the section that ran longest first. -## What to do tomorrow +**Section 1 is inherited, not rewritten.** The brief copies your validated problem statement word-for-word. If you find yourself softening the language for "a different document," you are about to brief a build for a problem you haven't actually validated. Here is what a good Section 1 looks like, lifted straight from a problem statement: -| 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. | +> *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."* -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. +The [Vibe PRD Template](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) is the fillable form - print it and write into the blanks. The [full doctrine reference](/course/tech-for-non-technical-founders-2026/reference/product-brief-full/) has a worked example and common mistake for all five sections, the choice between a Vibe PRD and a traditional PRD, and when a paid cohort is worth it. -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. +## Do this now -## What comes next (Chapter 3.2, then Chapter 4.1) +1. Block a focused sitting. Open your [Validated Problem Statement](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/) (Lesson 2.5) and the [Vibe PRD Template](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) side by side. +2. Copy Section 1 into the brief word-for-word from your problem statement. Do not paraphrase. +3. Fill Sections 2-5 from scratch: 2-4 sentences each, Section 5 as 5-8 no-go bullets. +4. Read the brief aloud to one peer. Ask: "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 - add it to Section 5. +5. Paste the finished brief into Lovable, [Cursor](https://cursor.com) (an AI coding tool developers run on their own machine), or your contractor's kickoff doc. Do NOT edit it for the audience - the same one page goes to everyone. -You now have two validated artifacts: a one-page problem statement (from your Chapter 2.5 synthesis) and a one-page Vibe PRD (from this chapter). Two more steps before Lovable touches your brief: +**Success check:** one page, five sections, Section 1 identical to your validated problem statement, and a no-go list of at least five lines. -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.3 · Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) + [4.4 · 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. +**If this fails: you can't fit Section 3 in one paragraph.** +- **Why:** your scope is too big - the brief is trying to be three products at once. +- **Fix:** pick the single smallest workflow one persona can complete end-to-end, and cut everything else to the no-go list in Section 5. -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 +Skipping the brief and going straight into prompting is the most common way a non-technical founder ends up deep in 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. -- Drew Falkman, "Vibe Coding Data-Enabled AI Apps" on Maven - the paid live cohort that teaches the Vibe PRD with instructor 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:** 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. > -> **You have now:** a validated problem statement (2.5) + prototype vocabulary (2.6) + the one-page Product Brief (Vibe PRD). Save it as `Product Brief - [date]` in your `Founder OS` folder - Chapter 4.1 reads it to decide your build path, and Chapter 4.3 reads it to prompt Lovable. +> **You have now:** a validated problem statement (2.5) + prototype vocabulary (2.6) + the one-page Product Brief (3.1). Save it as `Product Brief - [date]` in your `Founder OS` folder. Section 3 isn't stress-tested yet - Lesson 3.2 does that before Lovable touches it. +> +> **Next:** [3.2 · Quality-check your brief: features to outcomes](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/) - stress-tests Section 3 of the brief you just wrote. +> +> **If blocked:** see "If this fails" above. > -> **Next:** [3.2 · Quality-check your brief: features to outcomes](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/) - the quality gate on the brief you just wrote. -> **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. +> **Deeper reference:** [Full per-section examples, the Vibe-vs-traditional PRD decision, and when a paid cohort is worth it](/course/tech-for-non-technical-founders-2026/reference/product-brief-full/) · the fillable [Vibe PRD Template](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) --- 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 index dd66abf25..4b1337393 100644 --- 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 @@ -1,17 +1,18 @@ - + 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. @@ -27,14 +28,14 @@ - Vibe PRD - One-Page Product Brief + Vibe PRD - One-Page Product Brief One 90-minute sitting. Hand to Lovable, Cursor, or a hired junior. - 1. - The problem (copy from Chapter 2.5) + 1. + The problem (copy from Lesson 2.5) Persona + industry + dated sample + verbatim quote + cost. _______________________________________________________ _______________________________________________________ @@ -43,8 +44,8 @@ - 2. - The user and their context + 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: _________________________ @@ -53,8 +54,8 @@ - 3. - What you're building (one paragraph) + 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): ____________ @@ -63,8 +64,8 @@ - 4. - Success metric (one number) + 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 in 30 days. Event: conversion_completed." @@ -72,8 +73,8 @@ - 5. - What you're NOT building (the no-go list) + 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/index.md b/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/index.md index e47601242..bb86f5ce2 100644 --- 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 @@ -31,7 +31,7 @@ related_posts: false > **Module 5 · Lesson 5.7 · [OPTIONAL] - the systematic path when warm intros run out** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > -> **Input:** network exhausted, ~10 customers in from [Chapter 5.5](/course/tech-for-non-technical-founders-2026/first-ten-customers-send-track/) and [Chapter 5.6](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) +> **Input:** network exhausted, ~10 customers in from [Lesson 5.5](/course/tech-for-non-technical-founders-2026/first-ten-customers-send-track/) and [Lesson 5.6](/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 > @@ -39,260 +39,85 @@ related_posts: false > **TL;DR:** Once your network is exhausted, 30 filtered cold messages with a specific personalization per name put roughly one paid pilot in reach per batch - more as batches compound. 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.5](/course/tech-for-non-technical-founders-2026/first-ten-customers-send-track/). -> -> If you still have warm names in your network who fit your ICP (ideal customer profile - the specific buyer you're targeting), 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. - -This chapter is sales outbound asking buyers for money, which is a different motion from the interview-recruitment outreach in [Chapter 2.4](/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 ([OpenHunts launch statistics](https://openhunts.com/blog/tech-product-launch-statistics-insights)). 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 reportedly came from cold DMs to influential designers; Retool reportedly filtered Crunchbase by funding recency. Your Rails MVP customer 11-20 cohort will come from LinkedIn Sales Navigator (LinkedIn's paid search tool for filtering buyers by job title, company size, and industry) or Apollo, or both, feeding the four-line script below. +Four paid pilots close from your personal network over six weeks, then the warm names run out at customer five. The default move is to book a launch coach or sign an ad-agency contract - six weeks and a few thousand dollars, neither designed for your B2B vertical. The four-line cold message below is what customer five answers in week three for under $40 of tooling. -## Why Product Hunt is the wrong lever for a B2B SaaS product +After this lesson you will be able to: **send 30 filtered cold messages and book 1-2 paid pilots after the warm-network pass.** -> **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." +> **Stop here if you have not exhausted your personal network.** This lesson covers cold outbound to strangers - it assumes you have already converted the people who know you through [Lesson 5.5](/course/tech-for-non-technical-founders-2026/first-ten-customers-send-track/). +> +> If you still have warm names in your network who fit your ICP (ideal customer profile - the specific buyer you're targeting), close them first. Cold outbound is harder, slower, and lower-converting than warm outreach. Reading this lesson 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 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. +Customers 11-20 come from filtered cold outbound, not from launch events. Product Hunt converts at 3.1% per launch (387 launches, OpenHunts 2024) and 89% of its founders said they would not launch again; a sustained cold motion is what puts B2B buyers on the calendar. The full Product Hunt vs Indie Hackers data is in the [full reference](/course/tech-for-non-technical-founders-2026/reference/outbound-full/). -The tooling is a volume choice, and both versions ship the same 30-message batch. The $0 stack - Apollo's free tier (Apollo is a B2B contact database that finds prospects' names and work emails; its free tier is credit-based - check the current allowance), a Google Sheet, a Gmail mail-merge add-on (sends the same email to many recipients at once, free), Loom, and Calendly - covers every stage; you enrich the list by hand in the sheet, which costs your time. The paid version swaps the manual enrichment for automation through Smartlead or Apollo's paid tiers, which costs money and pays off once you're sending 100+ messages a week and the hand-enrichment is the bottleneck. At this chapter's 30-message volume, either works - pick by whether your scarcer resource is hours or dollars. +![Two stat cards, separate metrics: Product Hunt 3.1% per launch event (one-day spike, 89% would not launch again) vs Indie Hackers 23.1% per engaged post (sustained motion) - OpenHunts 2024](ph-vs-ih.svg) -The cold-outbound pipeline in one glance: +Run the whole pipeline in six stages with off-the-shelf tools - no engineer, no $1,200/month sales stack. Ship it for under $100/month on Apollo's free tier: 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.4](/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/). No re-record per prospect. +3. **Loom** - Same product Loom from [Lesson 5.4](/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/). 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.6](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/). Money on the table before you start work. +6. **Stripe** - DPA + deposit from [Lesson 5.6](/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: +The message is four lines: a specific reference earns the open, one sentence on what you built, one specific ask with friction removed, one currency anchor. Anything longer reduces the reply rate. The B2B SaaS variant: -| Tool | Role | Price | -|---|---|---| -| LinkedIn Sales Navigator | Filter buyers by title, company size, funding signal, role tenure | Paid single-user plans - check LinkedIn pricing | -| Apollo.io (Starter / free tier) | Cheaper alternative to Sales Nav for B2B email + filters | Free tier available; paid plans for scale | -| Loom | 90s product walkthrough + you on camera | Free tier available | -| 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 | +```text +Subject: shipped MVP last month - your post on [topic] -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 Smartlead from the tooling choice above) 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. +Hi [first name], -### Volume targets and what to expect +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 10 interviews with people who flagged the exact issue you described. I built [a tool that does X for Y]. -Running outbound long enough to read the funnel, 100-200 outreach contacts produces 5-10 paying customers. The funnel at each stage: +Worth 15 minutes to walk through? Paid design partner spots, [$ deposit] credited toward year one. Calendly: [link] -| 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.3 · 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 (a small monthly allowance of email and export credits). The "pull 100-150 raw rows" instruction usually exceeds one month of free credits, so either spread it over time 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 a paid Apollo tier 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', 'fontSize':'20px', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%% -flowchart LR - W1[Stage 1
    Send 30 messages
    1-4 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; +[Your name] ``` -Expect 3-8% replies on a realistic first batch - 1-2 replies per 30 messages - and treat 10-15% as what a tightly filtered, heavily personalized batch can reach: 3-4 replies, of which 1-2 agree to a 15-minute demo, of which one becomes a paid-pilot conversation. Of the pilots, the [Chapter 5.6](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) deposit-to-year-one conversion math holds. - -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. +The B2B services and B2C app variants, the full tooling stack, domain warmup, and the filter/personalization detail all live in the [full reference](/course/tech-for-non-technical-founders-2026/reference/outbound-full/). -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. - -3-8% replies is the realistic first-batch band; 10-15% is the ceiling a well-filtered, well-personalized batch can reach. +**Read the reply rate as a signal:** expect 3-8% on a realistic first batch (1-2 replies per 30 messages); 10-15% is the ceiling a tightly filtered, heavily personalized batch reaches. > **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.** +> **Do this now:** > -> 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-2.4 - 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. 1-4 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/). +> 1. Open the `Module 5 cold seed` tab - the same filter you saved as the Module 5 cold seed tab in your Lesson 2.3-2.4 outreach spreadsheet. Top up to 30-50 high-fit names using the same filter. Drop the bottom 20 into a "later batch" tab. +> 2. Personalize the top 30. One specific reference per name (recent post, hire milestone, role change) - 60-90 seconds each, ~45 minutes total. +> 3. Send via LinkedIn DM or a cold-email tool ([Smartlead](https://smartlead.ai), [Instantly](https://instantly.ai)). Same four-line body, one custom opener each. +> 4. Track replies in your Sheet. Book demos. Follow up with non-responders once only. +> 5. **Success check:** 30 messages sent, 1-4 replies logged, 2-3 demo calls booked from the batch. -## Advanced (optional sidebar) - -Once you have closed 5-10 paid pilots from cold outbound and want to layer on sales-system rigor, read First Round Review's [sales article collection](https://review.firstround.com/articles/sales/), Sahil Bloom's [Curiosity Chronicle newsletter](https://www.sahilbloom.com/newsletter), and the [Y Combinator library on founder-led sales](https://www.ycombinator.com/library/Mo-the-sales-playbook-for-founders). 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 (account executive - a dedicated salesperson), 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. +**If this fails: the batch returns 0-1 replies.** +- **Why:** for a new founder on a new sending domain, the cause is usually mechanical, not the product - the messages did not deliver, the domain has no warmup history, or the "specific reference" read generic. +- **Fix:** check bounce rate (above 10% = dirty list, re-warm the domain), re-read three profiles from your sent list to confirm the filter, and check that your reference sentence names something verifiable (a date, a post title). Fix the root cause before batch 2. A 0-1 reply rate on batch 1 is the median first-batch outcome, not a failure signal. -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 +The 30-message batch is not a one-time event. Run fresh batches until you have 20 customers - the second and third outperform the first by 30-50%, because you learn which reference patterns earn replies. -- OpenHunts, [Product Launch Statistics: Success Rates & Data](https://openhunts.com/blog/tech-product-launch-statistics-insights) - the primary source for the Product Hunt 3.1% vs Indie Hackers 23.1% per-engaged-post conversion data (387-launch 2024 study, 156 founders surveyed). -- 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. -- Lenny Rachitsky, [How the biggest consumer apps got their first 1,000 users](https://www.lennysnewsletter.com/p/how-the-biggest-consumer-apps-got) - first-users tactics from Airbnb, Tinder, Etsy, Reddit and more. -- 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, [The Sales Playbook for Founders](https://www.ycombinator.com/library/Mo-the-sales-playbook-for-founders) - YC's playbook on founder-led sales, from first pilots to closed recurring revenue. -- Sahil Bloom, [The Curiosity Chronicle](https://www.sahilbloom.com/newsletter) - his newsletter on early traction and the relationship-to-cold transition that closes the personal-network gap. +--- > **Done:** 30 cold messages are sent, replies are tracked in your spreadsheet, and 1-2 paid pilots are booked from the replies. > -> **You have now:** the full arc in hand - a validated hypothesis, a signed problem statement, a one-page brief, a live MVP, and at least one paying customer, plus a repeatable cold-outbound motion for customers 11-20. That is the whole course: idea → validated problem → brief → live MVP → paying customer. Keep the [First-Paying-Customer Operating Kit](/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/) open to keep the build honest as you ship past customer 10. +> **You have now:** the full arc in hand - a validated hypothesis, a signed problem statement, a one-page brief, a live MVP, and at least one paying customer, plus a repeatable cold-outbound motion for customers 11-20. That is the whole course: idea → validated problem → brief → live MVP → paying customer. +> +> **Next:** [Course landing page](/course/tech-for-non-technical-founders-2026/) - the core course is complete. When a problem shows up, the [Going further chapters](/course/tech-for-non-technical-founders-2026/#going-further-after-first-paying-customer) cover churn triage, pivot decisions, and hiring. Keep the [First-Paying-Customer Operating Kit](/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/) open to keep the build honest as you ship past customer 10. > -> **Next:** [Course landing page](/course/tech-for-non-technical-founders-2026/) - the core course is complete. When a problem shows up, the continuation chapters cover [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:** see "If this fails" above. If reply rate stays under 5% after a clean batch 1, the fix is upstream of the script - filter or domain, not the message. > -> **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. +> **Deeper reference:** [Product Hunt data, the full tooling stack, domain warmup, the funnel math, all three script variants, the stage cadence, and the no-reply diagnostic](/course/tech-for-non-technical-founders-2026/reference/outbound-full/) --- 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 index 9cca64cfe..6027b780c 100644 --- 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 @@ -1,46 +1,72 @@ - - Product Hunt 3.1% vs Indie Hackers 23.1% - the OpenHunts 2024 conversion data + + Product Hunt 3.1% per launch event vs Indie Hackers 23.1% per engaged post - two separate metrics, not one axis. + Two separate stat cards. Left, Product Hunt: 3.1% per launch event, 387 launches studied, 89% of founders would not launch again, shown as a single one-day spike. Right, Indie Hackers: 23.1% per engaged post, shown as sustained repeated engagement. Bottom note: Product Hunt is not bad - it is a one-day event in a job that needs sustained motion over a quarter. - Launch-day platforms - what actually converts in 2024 - OpenHunts study of 387 product launches and 156 founders surveyed - - - - 0% - 10% - 20% - 30% - 40% - - - Product Hunt - - 3.1% - per launch event - 89% of PH founders surveyed - said they would not launch again - - - Indie Hackers - - 23.1% - 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. + + + Two channels. Two different jobs. + OpenHunts 2024 - 387 launches, 156 founders surveyed. Separate metrics, shown separately. + + + + + + PRODUCT HUNT + + 3.1% + per launch event + + 387 launches studied + 89% said they would not launch again + + + + + + one-day spike + + + + + + + INDIE HACKERS + + 23.1% + per engaged post + + Written as engagement, + not a launch announcement + + + + + + + + + + + sustained motion + + + + + Product Hunt is not bad - it is a one-day event in a job that needs sustained motion over a quarter. 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 index 48363fd23..0168e252b 100644 --- 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 @@ -1,7 +1,7 @@ --- title: "Outreach Sequence Template: Book 10 Customer Interviews" aliases: ["/blog/outreach-sequence-template/"] -description: "The verbatim outreach sequence from Chapter 2.4: three message templates, both Day-3 bump variants, LinkedIn DM opener, the Reddit research comment, and NeetoCal booking-page copy. Copy, personalize, send." +description: "The verbatim outreach sequence from Lesson 2.4: three message templates, both Day-3 bump variants, LinkedIn DM opener, the Reddit research comment, and NeetoCal booking-page copy. Copy, personalize, send." date: 2026-05-18 draft: false course_chapter: true @@ -22,25 +22,25 @@ cover_image: cover.png metatags: image: cover.png og_title: "Outreach Sequence Template: Book 10 Customer Interviews" - og_description: "The verbatim outreach sequence from Chapter 2.4 - message templates, bump variants, DM opener, Reddit comment, booking-page copy." + og_description: "The verbatim outreach sequence from Lesson 2.4 - message templates, bump variants, DM opener, Reddit comment, booking-page copy." cover_image_alt: "JetThoughts template cover for the customer-interview outreach sequence" canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/outreach-sequence-template/" related_posts: false --- -> **Template companion to [Chapter 2.4 - Find 10 People: What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/)** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) +> **Template companion to [Lesson 2.4 - Find 10 People: What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/)** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > -> **Input:** your 30-name list from [Chapter 2.3](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) - each row has a name, where they posted, the post URL, and one quoted line +> **Input:** your 30-name list from [Lesson 2.3](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) - each row has a name, where they posted, the post URL, and one quoted line > > **Output:** 10 interview calls booked, using nothing more than Gmail, a [NeetoCal](https://www.neeto.com/neetocal) booking link, and a handful of messages a day -Everything below is copy-pasteable. Replace the `[BRACKETS]`, keep the shape. The rules that make these messages work - and what to do when they don't - live in [Chapter 2.4](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/); this page is the reference card. +Everything below is copy-pasteable. Replace the `[BRACKETS]`, keep the shape. The rules that make these messages work - and what to do when they don't - live in [Lesson 2.4](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/); this page is the reference card. ## The Day-0 message (email or DM) -> Subject: your post about [THEIR EXACT WORDS] +> Subject: your post about [their exact words] > -> Hi [NAME] - you wrote that [ONE SPECIFIC LINE FROM THEIR POST, PARAPHRASED]. I'm researching exactly that problem and would trade 20 minutes for everything you learned the hard way. No pitch, nothing to sell - I don't even have a product yet. Would [DAY] or [DAY] work? Booking link if that's easier: [NEETOCAL LINK] +> Hi [name] - you wrote that [ONE SPECIFIC LINE FROM THEIR POST, PARAPHRASED]. I'm researching exactly that problem and would trade 20 minutes for everything you learned the hard way. No pitch, nothing to sell - I don't even have a product yet. Would [DAY] or [DAY] work? Booking link if that's easier: [NEETOCAL LINK] The whole message rests on the first line naming something they actually wrote. Send a handful a day, by hand, per the 2.4 cadence - a stagger beats a burst. @@ -62,7 +62,7 @@ Never claim conversations you have not had. The first-round variant works fine o ## LinkedIn DM opener (when there's no email) -> [NAME] - your comment on [POST/THREAD] about [TOPIC] is why I'm writing. I'm researching that exact problem (not selling anything - there's no product yet). 20 minutes this week for everything you'd warn someone about? +> [name] - your comment on [POST/THREAD] about [TOPIC] is why I'm writing. I'm researching that exact problem (not selling anything - there's no product yet). 20 minutes this week for everything you'd warn someone about? ## The Reddit research comment (public thread, DMs closed) @@ -70,7 +70,7 @@ Never claim conversations you have not had. The first-round variant works fine o ## The waitlist-signup opener (for your Module 1 smoke-test signups) -> Hi [NAME] - you joined the [PRODUCT] waitlist a while back. Before anything gets built, I'm talking to the people who signed up. 20 minutes on what made you click? You'll shape what gets built first. +> Hi [name] - you joined the [PRODUCT] waitlist a while back. Before anything gets built, I'm talking to the people who signed up. 20 minutes on what made you click? You'll shape what gets built first. People who already raised a hand reply at the highest rate of any group you will message - start with them if you have them. @@ -88,7 +88,7 @@ One spreadsheet row per name (your 2.3 list already has the first four columns): > > **Next:** run the calls with the [Mom Test Interview Script](/course/tech-for-non-technical-founders-2026/mom-test-interview-script/), then score the transcripts on the [Synthesis page](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/). > -> **If blocked:** replies not coming? [Chapter 2.4's reply-rate calibration steps](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) cover the failure modes - it is almost always a first line that could have been sent to anyone. +> **If blocked:** replies not coming? [Lesson 2.4's reply-rate calibration steps](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) cover the failure modes - it is almost always a first line that could have been sent to anyone. --- 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 index aa0150375..eeb4de9c1 100644 --- 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 @@ -24,7 +24,7 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 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. +Template companion to [Lesson 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 [Lesson 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):** > @@ -35,13 +35,11 @@ related_posts: false *Prefer paper? Download the PDF - same content, print-ready.* -# The GitHub / AWS / Database Ownership Checklist - A 45-minute audit that tells you whether you own your company's code, cloud, and domain - or someone else does. 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:** +> **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? | > |---|-------|-------|---------------------------|------------------| @@ -62,7 +60,7 @@ By the end of one Friday (or the 5 minutes if you're self-serve) you will know w ## Why this exists -A founder we saw last year handed a contractor her company credit card on Day 1. The contractor opened the accounts fast and shipped the MVP inside six weeks. Nobody moved the accounts to her email afterwards. A year later the contractor left the industry, and she discovered the GitHub org, the AWS root, and the domain were all registered to an inbox nobody checked. Recovery is slow and expensive when the accounts are not in your name. The audit below catches all of this on Day 1 in 45 minutes. +The account that locks you out is the one set up under someone else's email on Day 1 and never moved - and you find it a year later, once the person who opened it is gone. That is how it played out for a founder we saw last year: she handed a contractor her company credit card on Day 1, and he opened the accounts fast and shipped the MVP inside six weeks. Nobody moved the accounts to her email afterwards. A year later the contractor left the industry, and she discovered the GitHub org, the AWS root, and the domain were all registered to an inbox nobody checked. Recovery is slow and expensive when the accounts are not in your name. The audit below catches all of this on Day 1 in 45 minutes. Most contractors are not trying to lock you out. They set the accounts up under their own email on Day 1 because it was the fastest way to start, and nobody ever moved them. The damage is the same either way. @@ -129,7 +127,7 @@ The root account owns everything underneath it. If the contractor controls the r **#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). +The fail looks like one sentence: *"Marcos 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 single point of failure. @@ -137,7 +135,7 @@ If only one person can rotate the prod DB password, you do not have a database. > Bad: Renewals come to a contractor's email. 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 contractor will not release it, your customers cannot reach your site for two weeks. +Plan a 14-day buffer for a domain transfer: ICANN's release window is five days, and many registrars add a 60-day lock after registration or a recent transfer. If the contractor will not release the auth code, your customers cannot reach your site for two weeks. ## What to do if the audit fails diff --git a/content/course/tech-for-non-technical-founders-2026/ownership-checklist/ownership-checklist.pdf b/content/course/tech-for-non-technical-founders-2026/ownership-checklist/ownership-checklist.pdf index 245bbc75d..b5d6ad635 100644 Binary files a/content/course/tech-for-non-technical-founders-2026/ownership-checklist/ownership-checklist.pdf and b/content/course/tech-for-non-technical-founders-2026/ownership-checklist/ownership-checklist.pdf 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 index 43b4ea483..c18b1e77a 100644 --- 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 @@ -2,21 +2,21 @@ 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. + Illustrative from 4 founders we worked with who ran both motions in 2026. Your numbers will vary. 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 index 10bb1b484..f421bd835 100644 --- 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 @@ -31,7 +31,7 @@ related_posts: false > **Module 5 · Lesson 5.6 · [CORE]** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > -> **Input:** 3-5 warm leads from [Chapter 5.5](/course/tech-for-non-technical-founders-2026/first-ten-customers-send-track/) +> **Input:** 3-5 warm leads from [Lesson 5.5](/course/tech-for-non-technical-founders-2026/first-ten-customers-send-track/) > > **Output:** 1 signed paid pilot before any new code ships > @@ -39,64 +39,40 @@ related_posts: false > **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," a wall of 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 +A free pilot feels collaborative: the customer says yes, you build for six weeks, and every Friday demo gets "this is great." Then Week 8 lands, you send the year-one contract, and the customer says "let me circle back to my CFO" - a CFO who never heard of you and never approved the pilot. A refundable Stripe deposit signed before kickoff is what turns that dead end into a formality. -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." +After this lesson you will be able to: **sign a Design Partner Agreement with a refundable Stripe deposit before writing new code.** -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. +Same product, same buyer, one difference - when the money lands: -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. +| Variant | Setup | Result at Week 8 | +|---|---|---| +| **Free pilot** | Six weeks of free build, customer "loves it," a wall of 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. | -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. +Real money on the table before kickoff forces the internal budget conversation while nothing is riding on it yet. You are not asking for money - you are asking the customer to defend the spend internally. That 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 +> **Course terminology: "first paying customer" = signed DPA + cleared deposit.** 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. Converting the pilot into a year-one contract is a separate event 6-10 weeks later, after the success criteria are met. -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. +The DPA is a one-page letter of intent 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, plain English, and v1 needs no lawyer. 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. | +| 3 | **Pilot fee + deposit** (load-bearing) | 10-30% of year-one ACV. 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.5 replies](/course/tech-for-non-technical-founders-2026/first-ten-customers-send-track/). - -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. +The clause-by-clause detail - what each section is really doing, and what happens each Friday after the deposit clears - is in the [full reference](/course/tech-for-non-technical-founders-2026/reference/paid-pilot-full/). ### Copy-paste DPA template {#dpa-template} @@ -157,169 +133,45 @@ _________________________ 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.5 smoke-test price to year-one ACV.** Take the monthly price you tested in [Chapter 1.5](/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 (the formal purchasing-approval process at bigger companies), 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 your 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 (capped under the procurement line) | 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 (capped under the procurement line) | Service deposit is normal in the sector. Customer expects to pay. | - -### 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 (a direct bank transfer), 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.5](/course/tech-for-non-technical-founders-2026/first-ten-customers-send-track/) 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. - -**"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 (paying 30 days after the invoice instead of upfront). - -*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 (proof of concept - a small paid trial) with a smaller scope I can deliver before invoicing for the full pilot." - -**"My legal team needs to review any contract."** +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/) - a free reference for the same template with sector-specific fills. -*Means:* Standard B2B response; the one-page DPA is usually under their threshold. +**The deposit number:** take the monthly price you tested in [Lesson 1.5](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/) and multiply by 12 for year-one ACV. A $97/month hypothesis → $1,164 ACV. Your deposit is 10-30% of that, with a **$500 floor** - below $500 it stops working as a commitment device. When 10% of ACV is under $300, charge the first month's revenue upfront instead. The full band table by sector, the $10K procurement ceiling, and the Stripe Checkout flow are in the [full reference](/course/tech-for-non-technical-founders-2026/reference/paid-pilot-full/). -*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.5 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-network-list/). The DPA is the wrong sprint for an empty pipeline. +> **Do this now:** +> +> 1. Copy the [DPA template above](#dpa-template) into a Google Doc. Fill the 6 bracketed sections. +> 2. Take your [Lesson 1.5](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/) price × 12 for ACV. Set the deposit at 10-30%, never below $500. +> 3. In [Stripe](https://dashboard.stripe.com/login): Products → create "[Product] - Design Partner Pilot" → add a one-time price for the deposit → hit "Payment link". Stripe generates a hosted checkout URL. No webhook, no code. +> 4. Send the DPA + Stripe link to 1-2 warm leads from Lesson 5.5 who booked demos recently. +> 5. **Success check:** one lead replies "send the one-pager" or signs, and your first deposit clears in your Stripe account. That is the first paying customer. -## 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 widely used by YC companies), [SaaStr's "Should we charge for pilots"](https://www.saastr.com/we-are-a-b2b-saas-startup-and-want-to-develop-our-product-in-pilots-with-customers-should-we-charge-for-the-pilots-and-how-much/) (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" (master service agreement - a long formal contract) in pilot conversations. +**If this fails: the customer says "can we start free and convert later?"** +- **Why:** the deposit scares them, but they're still interested - this is hedging, not a no. +- **Fix:** reframe the deposit as *year-one ACV prepaid*, not added cost. The $500 sits in this month's accounting and gains a CFO check now; free pilots lose that approval in Week 8. -A 20% deposit at kickoff puts the CFO question on Week 0. Conversion in Week 7 becomes paperwork, not negotiation. +**If this fails: the customer says "we do not do paid pilots."** +- **Why:** they're not in your must-have segment - wrong buyer profile. +- **Fix:** thank them and move to the next warm lead. They're not disqualified, just not your customer yet. --- -## Further reading +Send the DPA to your warmest lead first. Asking someone you know for a refundable deposit is the stall point - but the deposit is a test of whether the problem is real, not of whether you deserve to be paid. The second one is easier. -- Common Paper, [Design Partner Agreement template](https://commonpaper.com/standards/design-partner-agreement/) - a vetted, modern LOI widely used by YC companies. The companion to your one-pager when conversations move toward MSAs. -- SaaStr, [Should you charge for a pilot?](https://www.saastr.com/we-are-a-b2b-saas-startup-and-want-to-develop-our-product-in-pilots-with-customers-should-we-charge-for-the-pilots-and-how-much/) - 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 investor Ash Rust. -- Steve Blank, [The Four Steps to the Epiphany](https://steveblank.com/four-steps-35/) - 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:** one DPA is signed and the Stripe deposit has cleared in your account. > -> **You have now:** a signed Design Partner Agreement + a cleared deposit - real money from someone who didn't know you before you asked. Save the executed PDF + Stripe receipt in your `Founder OS` folder next to the earlier artifacts (validated problem statement, Product Brief, live MVP). That completes the folder - the artifact investors fund, the one you point to and say "someone who doesn't know me paid real money for this." Converting this pilot into a year-one contract is the next test, 6-8 weeks out. +> **You have now:** a signed Design Partner Agreement + a cleared deposit (5.6), sitting alongside your validated problem statement, Product Brief, and live MVP in the `Founder OS` folder. That completes the folder - the artifact investors fund. Converting this pilot into a year-one contract is the next test, 6-8 weeks out. > -> **Next:** that is the core course complete - from a one-sentence hypothesis to a stranger's money in your account. Two ways to keep going: the optional [5.7 · Going Outbound Without a Sales Team](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/) when your warm list runs dry, and the [Going further chapters](/course/tech-for-non-technical-founders-2026/#going-further-after-first-paying-customer) once your pilot converts. The [First-Paying-Customer Operating Kit](/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/) keeps the build honest through the pilot. +> **Next:** that is the core course complete - from a one-sentence hypothesis to a stranger's money in your account. Keep going with the optional [5.7 · Going Outbound Without a Sales Team](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/) when your warm list runs dry, or the [Going further chapters](/course/tech-for-non-technical-founders-2026/#going-further-after-first-paying-customer) once your pilot converts. The [First-Paying-Customer Operating Kit](/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/) keeps the build honest through the pilot. > -> **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 here?** Asking for money from someone you know is the stall point, 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. +> **If blocked:** see "If this fails" above. If you do not have warm demos yet, your work is still in [Lesson 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) - the DPA is the wrong sprint for an empty pipeline. +> +> **Deeper reference:** [The six DPA clauses in detail, the full pricing bands, the Stripe flow, and the conversation script with objection handling](/course/tech-for-non-technical-founders-2026/reference/paid-pilot-full/) --- 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 index e8bc84984..4298bfc4a 100644 --- 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 @@ -39,15 +39,17 @@ related_posts: false > **Going further · Continuation chapter** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > -> **Input:** a decision from the [churn-triage chapter](/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/) OR a Sean Ellis 40% test result ([Chapter 5.1](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/)) +> **Input:** a decision from the [churn-triage chapter](/course/tech-for-non-technical-founders-2026/customers-leaving-churn-triage-not-acquisition/) OR a Sean Ellis 40% test result ([Lesson 5.1](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/)) > > **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 the cold-outbound stage (Chapter 5.7) with a 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. +A fintech founder I worked with last quarter - call him D. - hit the cold-outbound stage (Lesson 5.7) with a 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. +*Illustrative composite based on patterns from real founder builds, not a single client story.* + +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 - product-led growth, where users find and buy the product self-serve). 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. @@ -73,7 +75,7 @@ Eric Ries catalogued ten pivot types in *The Lean Startup*; Steve Blank built on ### 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. +*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 (monthly active users) 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 @@ -81,7 +83,7 @@ Eric Ries catalogued ten pivot types in *The Lean Startup*; Steve Blank built on ### 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%. +*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 (average revenue per user) dropped 20% per customer; net revenue retention (the revenue you keep plus expansion from existing customers) 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. 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 index 51632f5a1..abfd33fd5 100644 --- 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 @@ -2,12 +2,12 @@ The pivot ledger: 4-column table tracking what survives the pivot and what does not 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 index 307053a2a..574abe00e 100644 --- a/content/course/tech-for-non-technical-founders-2026/quickstart/index.md +++ b/content/course/tech-for-non-technical-founders-2026/quickstart/index.md @@ -29,6 +29,8 @@ related_posts: false You have an idea and no time, so this page lists only the core lessons - the smallest amount of reading that still produces a real result. +![The minimal path: five numbered core-lesson stops, one per module in its module colour - Hypothesis and Smoke Test (landing page and price signal), Validate the Problem (10 interviews and a prototype), Design from Evidence (a one-page Product Brief), Build It Yourself (a live MVP at a real URL), and First Paying Customer (a signed paid pilot).](minimal-path.svg) + ## The Problem (in your language) You want to validate whether your idea has real demand before you spend $30K+ on a dev shop - but you can't read code, your available time is evenings and weekends (maybe 2-4 hours a week), and hiring anyone is premature. This route works within all three constraints. @@ -90,7 +92,7 @@ Skip the lessons marked "optional" on the [course landing page](/course/tech-for --- -> **Start here:** [Chapter 1.1 - Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) +> **Start here:** [Lesson 1.1 - Form Your Founding Hypothesis](/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/) --- diff --git a/content/course/tech-for-non-technical-founders-2026/quickstart/minimal-path.svg b/content/course/tech-for-non-technical-founders-2026/quickstart/minimal-path.svg new file mode 100644 index 000000000..08e1d2a6a --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/quickstart/minimal-path.svg @@ -0,0 +1,88 @@ + + The minimal path: five numbered core-lesson stops from idea to first paying customer. + A left-to-right strip of five numbered step cards, one per module, each in its module colour. Step 1 Hypothesis and Smoke Test produces a landing page and a price signal. Step 2 Validate the Problem produces 10 interviews and a prototype. Step 3 Design from Evidence produces a one-page Product Brief. Step 4 Build It Yourself produces a live MVP at a real URL. Step 5 First Paying Customer produces a signed paid pilot. Arrows connect each step to the next. + + + + + + + + + The Minimal Path + Core lessons only - the shortest route from idea to first paying customer. + + + + + + 1 + Hypothesis & + Smoke Test + landing page + + price signal + + + + + + + 2 + Validate the + Problem + 10 interviews + + prototype + + + + + + + 3 + Design from + Evidence + one-page + Product Brief + + + + + + + 4 + Build It + Yourself + live MVP at + a real URL + + + + + + + 5 + First Paying + Customer + signed + paid pilot + + + + + + + + diff --git a/content/course/tech-for-non-technical-founders-2026/reference/ceiling-signals-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/ceiling-signals-full/index.md new file mode 100644 index 000000000..598cf12ef --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/ceiling-signals-full/index.md @@ -0,0 +1,121 @@ +--- +title: "Full Reference: The 5 Vibe-Coding Ceiling Signals" +description: "The complete guide behind Lesson 4.5 - each of the 5 architectural ceiling signals with its symptom, root cause, cost of waiting, and cost of fixing now, plus the shed-house-skyscraper map and the enterprise pre-SOC2 reply template." +date: 2026-05-13 +draft: false +slug: ceiling-signals-full +--- + +> **Reference companion to [Lesson 4.5 · Vibe Coding Done Right: 5 Ceiling Signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/)** - the deep version of each signal, the shed-house-skyscraper map, and the enterprise-buyer email template. Read the micro-lesson first for the monthly check and the decision rule; return here when a specific signal starts firing and you want the full picture before you route it. + +--- + +Each signal below 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, and the cost of addressing it now. Score each one green / yellow / red. Two reds firing for 4+ weeks means you graduate. Signals are ordered by when they typically become detectable - run Signal 1 from Week 2, Signal 5 at Week 8+. + +## 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**: runtime inference cost scales with usage, not revenue. Every new active user adds per-request LLM calls; if each user's monthly inference cost sits above their share of the plan price, growth makes the hole deeper, not shallower. A founder who never modeled per-user inference can spend months of runway on a cost line they could have capped in an afternoon. + +**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**: + +*Illustrative composite based on patterns from real founder builds, not a single client story.* A fitness-coaching SaaS reaches 11,000 lines of Lovable-generated code with no foreign keys, every model named in the singular, and three customer accounts holding corrupted data because a webhook retried a Stripe charge update four times. The founder ships six features in month four and zero in months five and six, because every change surfaces something else that broke. + +**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 (roughly $160-$240 - two hours at the $80-$120/hour fractional band). 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 users open the same client record. One adds a note. The other adds a note. Whoever saves second wins - the first note is gone. Your support channel fills with "the app is acting weird again," and each patch changes 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 within a few months. Any customers who collaborate - coaches sharing clients, teams sharing accounts - lose work on a recurring basis, and each lost note erodes the trust that brought the user in. By the time real-time becomes a deal-breaker for a large customer, the rebuild estimate is the same one you would have gotten earlier; you have just spent the intervening months patching. + +**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. Months later, the workaround becomes the breach incident. The [vibe-coded auth shape](/blog/vibe-coding-disposable-by-design/) - 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 at the $80-$120/hour fractional band), 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 [Lesson 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. Some 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 [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. + +## 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/collection/soc-2/soc-2-compliance-checklist) - the audit-surface checklist a founder usually meets for the first time when an 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. + +--- + +*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/vibe-coding-ceiling-signals/shed-house-skyscraper.svg b/content/course/tech-for-non-technical-founders-2026/reference/ceiling-signals-full/shed-house-skyscraper.svg similarity index 94% rename from content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/shed-house-skyscraper.svg rename to content/course/tech-for-non-technical-founders-2026/reference/ceiling-signals-full/shed-house-skyscraper.svg index 8f0715abd..2becc463c 100644 --- 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/reference/ceiling-signals-full/shed-house-skyscraper.svg @@ -1,5 +1,5 @@ - + @@ -26,7 +26,7 @@ The shed Lovable + Supabase + Stripe - 1 founder - ~$87 / mo - 4 weeks + 1 founder - ~$87 / mo - 4 weeks @@ -39,7 +39,7 @@ The house Fractional CTO + 1-2 engineers - Rails / Django / Laravel - ~$10-25K / mo + Rails / Django / Laravel - ~$10-25K / mo @@ -60,7 +60,7 @@ The skyscraper Hired engineering team - SOC2 / HIPAA - audit-ready - ~$50K+ / mo + SOC2 / HIPAA - audit-ready - ~$50K+ / mo diff --git a/content/course/tech-for-non-technical-founders-2026/reference/channel-selection-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/channel-selection-full/index.md new file mode 100644 index 000000000..1edaab54c --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/channel-selection-full/index.md @@ -0,0 +1,169 @@ +--- +title: "Full Reference: Channel Selection and Scoring Worksheet" +description: "The complete channel-selection reference - the commitment-rule phase table, how to read channel signals from interview transcripts, the 4-dimension channel-fit scoring, the 4-channel comparison, the Engineering-as-Marketing side door, and the full fill-in worksheet. Companion to Lesson 5.2." +date: 2026-05-13 +draft: false +slug: channel-selection-full +--- + +> **Reference companion to [Lesson 5.2 · Choose Your Channel Before You Send One Message](/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/)** - the commitment-rule phase table, how to read channel signals from your interview transcripts, the 4-dimension channel-fit scoring, the 4-channel comparison, the Engineering-as-Marketing side door, and the full fill-in worksheet. Read the micro-lesson first for the commitment rule and the ≥9/12 score; return here when you want the full worksheet and the four-channel comparison. + +--- + +## The commitment rule, phase by phase + +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, in full + +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 [Lesson 1.5](/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 free tier); 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) (free tier available) | Open rate (share of recipients who open your email) <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 | + +Pick the one that matches your buyer type, your price point, and your honest time budget - then commit. + +> **A fifth play: Engineering as Marketing - a slower-burn, zero-CAC (Customer Acquisition Cost - what you spend to land one customer) option, not one of the four channels you score above.** 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. + +## Channel Selection Worksheet + +Fill this out before you send message one. It prevents the wasted-effort cycle of channel-hopping. + +> **Fast-path exit: skip the worksheet if your interviews already named a channel.** If your Lesson 2.3-2.4 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 below. Write your commitment statement and move to Lesson 5.3. The full worksheet is for founders still deciding between channels. Use it to decide between channels; skipping it does not block anything. + +### Part 1: Interview Evidence + +
    +

    Go through each interview transcript. For each one, note any channel signal the interviewee gave - directly or indirectly.

    + + + + + + + + + + + + + + + + +
    #Interviewee roleChannel signal (quote or paraphrase)Channel type implied
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    +

    Tally by channel type

    +
    LinkedInEmail / newsletter
    +
    Community / Slack / DiscordSocial (X, Reddit, TikTok)
    +
    Search / GoogleWord of mouth / referral
    +
    Strongest signal (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 someone whose work life happens outside LinkedIn (your 5.1 interviewees will have told you where they actually hang out).

    +
    Price fitBuyer typeTime budgetInterview signal
    +
    Total / 12
    +
    + +
    +

    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 fitBuyer typeTime budgetInterview signal
    +
    Total / 12
    +
    + +
    +

    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 fitBuyer typeTime budgetInterview signal
    +
    Total / 12
    +
    + +
    +

    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 fitBuyer typeTime budgetInterview signal
    +
    Total / 12
    +
    + +
    +
    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. + +
    +
    My chosen channel
    +

    Why this channel - note the evidence beside each:

    +
      +
    • Interview evidence: which interviewees, and what they said
      • +
    • Buyer type match: why this channel reaches my buyer
      • +
    • Price point math: estimated cost per lead vs my price point
      • +
    • Time budget: time per batch I will actually spend
      • +
    +
    + At the evaluation point I check + Reply rate (target: over 5%) + Demo-to-conversation rate (target: over 20%) + Any paid conversations started (target: 1 or more) +
    +
    Commitment - I will not switch channels until I have run a full send/reply/follow-up arc. If all three targets are missed, I 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. + +## 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. +- Lenny Rachitsky, [How the biggest consumer apps got their first 1,000 users](https://www.lennysnewsletter.com/p/how-the-biggest-consumer-apps-got) - 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. + +--- + +*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/find-10-people-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/find-10-people-full/index.md new file mode 100644 index 000000000..74353e381 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/find-10-people-full/index.md @@ -0,0 +1,174 @@ +--- +title: "Full Reference: Find 10 People - Research, Channels, and Outreach Detail" +description: "Complete channel-by-channel research walk, search-string galleries, list filters, the bad-first-draft teardown, research-panel fallback, and slow-path variants for finding and recruiting 10 customer interviews." +date: 2026-05-18 +draft: false +slug: find-10-people-full +--- + +> **Reference companion to Lessons [2.3 · Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) and [2.4 · What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/)** - this page carries the detail both micro-lessons point to: the full channel-by-channel research walk, search-string galleries, list filters, the bad-first-draft teardown, the message psychology, the research-panel fallback, and the slow-path variants. Read the micro-lessons first; return here when you need depth on one step. + +--- + +## Where to Search: The Full Channel Walk + +The AI ICP map (from Lesson 2.3) names your specific communities. Here is how to work each channel type once you have the list. Read before you write a single message - you are collecting the exact words people use when their problem flares up, because those words become your subject lines in Lesson 2.4. + +- **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. [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](https://www.g2.com/) and [Capterra](https://www.capterra.com/) reviews (the two big business-software review sites)** - 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 almost always show - the mutual contact is on the line for it. + +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. + +--- + +## The Simplest Search, Step by Step + +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 - that bank is your raw material when you write the cold messages. + +If your hypothesis is consumer-facing, swap "Slack/Discord" for TikTok hashtags, Instagram comments, YouTube comment threads, and product subreddits. + +--- + +## Search Strings and Keyword Variation + +When one keyword stops surfacing new people, the fix is a related word, not a paid tool. The second-degree search finds people with the same problem but different vocabulary: + +- "boarding costs" instead of "pet sitter" +- "claim denial appeal" instead of "medical billing" +- The workaround they use, the related complaint, the tool name they'd mention while frustrated + +Thirty minutes of keyword variation turns 3 names into 12. Ask the AI ICP map for "5 second-degree adjacent search terms I might miss" and run each one back through your top channel. + +--- + +## Filter the List: Six Dimensions + +Once you have named posters in a spreadsheet, filter the final list on six dimensions so the calls are bookable and the signal is clean: + +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. + +If you run out of named posters before you hit 30, [Apollo](https://apollo.io)'s free tier (credit-based, no credit card - a small monthly allowance of email and export credits) lets you filter on role + industry + company size and export the rest. The monthly export allowance is small, so this fills the gap over several weeks, not one sitting. Treat it as backfill, not the source - the hand-picked names always perform better. + +**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. + +--- + +## Optional Upgrades to the Research Step + +These are skip-by-default. The main flow works without any of them. + +**Upgrade the AI ICP map prompt with a deep-research tool.** The Claude/ChatGPT version is fast and free; the trade-off is the AI synthesizes text without source links. For a verifiable evidence trail, swap in Perplexity Pro or Gemini Deep Research (both paid tiers) 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. + +**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. [UserInterviews](https://www.userinterviews.com/) and [Respondent](https://www.respondent.io/) have screened participants across these verticals; pricing is per completed 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) (no signup) surfaces the high-frequency keywords inside any subreddit. [F5Bot](https://f5bot.com) sends email alerts when your keywords appear on Reddit, Hacker News, or Lobste.rs. [Reddinbox](https://reddinbox.com) watches Reddit for your keywords and collects the matching conversations in one inbox. These tools surface the threads faster - you still read them yourself. + +--- + +## The Message a First-Time Founder Writes First + +Before the working sequence in Lesson 2.4, look at the version a founder typically sends on attempt one. This is composed from real first-draft messages we've seen across projects: + +```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! +``` + +That message gets almost no replies - nothing in it tells the reader why them. 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 same 3-message pattern works as LinkedIn DMs. The subject becomes the connection-request note. Skip the Day-7 close on LinkedIn - it's too aggressive in a DM context. + +--- + +## When Cold Outreach Can't Reach Them: 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. + +Everything up to here costs $0 - Gmail and the 30-name list you built in Lesson 2.3. A research panel is the paid shortcut: you pay the service to book interviewees for you, which usually runs a few hundred dollars total for a round of calls. That is why it is not the default - use it only when the cold-outreach path can't reach your ICP and replies run thin. When it does work, run it 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 [Lesson 1.4](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) (built in [1.2](/course/tech-for-non-technical-founders-2026/smoke-test-build-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?" + +That opener out-performs every cold variant - the person already raised a hand. + +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. + +--- + +## Slow-Path Variant for the Part-Time Founder + +Working evenings only, with day-job constraints? The staggered cadence in Lesson 2.4 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's multi-send](https://support.google.com/mail/) or [Streak](https://www.streak.com/). Expect a noticeably lower reply rate because the messages land in a burst instead of a stagger - compensate by booking the first 2-3 interviews from your fastest responders quickly. + +--- + +## What Happens After the 10 Calls Are Booked + +Lesson 2.4's output is 10 booked interviewees. Running them, scoring them, and turning them into the validated problem statement Module 3 needs is a linear sequence: + +1. **Run each interview using the Lesson 2.1 5-question Mom Test technique.** Open the [Mom Test Interview Script](/course/tech-for-non-technical-founders-2026/mom-test-interview-script/) on a second monitor; read the 5 questions verbatim. Plan 20-30 minutes per call. +2. **Score each call 1-10 within 5 minutes of hanging up** per the Lesson 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 Lesson 2.6 prototype sessions. +5. **Two artifacts now flow into Module 3 + later modules:** + - The Validated Problem Statement (Section 1 of the Lesson 3.1 one-page brief, lifted verbatim) + - The 5 strongest-signal interviewees (Lesson 2.6 input - and later, your Module 5 onramp invitees in Lesson 4.3-4.4, plus your warm-list seed in Lesson 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. + +--- + +## 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 list books. +- Y Combinator, [Talking to Users (Startup Library)](https://www.ycombinator.com/library) - the canonical YC essay on why this conversation has to happen. +- Teresa Torres, [Customer Interviews (Product Talk)](https://www.producttalk.org/customer-interviews/) - why strangers say yes or no to an interview ask. +- [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. + +--- + +*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/should-you-hire-2026-decision-tree/airbnb-test.svg b/content/course/tech-for-non-technical-founders-2026/reference/hire-decision-full/airbnb-test.svg similarity index 98% rename from content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/airbnb-test.svg rename to content/course/tech-for-non-technical-founders-2026/reference/hire-decision-full/airbnb-test.svg index 7ea10c0ef..74df196f9 100644 --- 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/reference/hire-decision-full/airbnb-test.svg @@ -1,5 +1,5 @@ - + diff --git a/content/course/tech-for-non-technical-founders-2026/reference/hire-decision-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/hire-decision-full/index.md new file mode 100644 index 000000000..3ec6ef26e --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/hire-decision-full/index.md @@ -0,0 +1,83 @@ +--- +title: "Full Reference: The Build-vs-Hire Decision" +description: "The complete build-path reference - the Airbnb validate-without-code test, all four build paths in depth, the shed-vs-house framing, the Series-A off-ramp, and the full further-reading set. Companion to Lesson 4.1." +date: 2026-05-13 +draft: false +slug: hire-decision-full +--- + +> **Reference companion to [Lesson 4.1 · Should You Hire?](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/)** - the full Airbnb test walkthrough, each of the four build paths in depth, the shed-vs-house framing, and the Series-A off-ramp. Read the micro-lesson first for the five routing questions and the four paths; return here when you want the Airbnb test and the Series-A off-ramp in full. + +--- + +## 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. + +All three of your validation signals so far - the smoke test, the Mom Test interviews, the clickable prototype - are research, not builds. They prove the problem is real and the shape is right. They do not prove anyone will pay. That is what the Airbnb test settles before you commit a single month of build time. + +## 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 simple hand-built 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 the 30 people from your [Lesson 2.3 30-name list](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/). + +![A 3-step illustration of the Airbnb test: Carrd page with Stripe checkout (Step 1), send link to 30 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 30 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 30 cold outreach hits is enough to flip the build switch. + +One B2B SaaS founder 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 30 prospects is brutal in the other direction. The problem might be real (you validated it in [Lesson 2.5](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/)) 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 + +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. [Lesson 4.5 · Vibe Coding Ceiling Signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) is the full shed → house → skyscraper diagnostic - read it after you pick your path to know when to revisit the hire decision. + +## The four paths in depth + +### 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 30 ICP prospects (ICP = Ideal Customer Profile - the specific kind of person your hypothesis names as the buyer) from your [Lesson 2.3 30-name list](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/). 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 + +Pick this path when the problem is validated (10+ Mom Test interviews with strong signal in at least 7 per the [Lesson 2.5](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) synthesis rubric, plus a [Lesson 1.4](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) smoke test that cleared the 6%+ "Promising" band - pre-orders and paid pilots come 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/one-page-product-brief-vibe-prd/) into [Lovable](https://lovable.dev) (free trial available), ship the smallest end-to-end thing it generates, and connect [Supabase](https://supabase.com) (free tier) + Stripe + Resend (the service that sends your app's emails) on top. Watch one failure mode: hitting the architectural ceiling when the app crosses ~5,000 users or your second integration. [Lesson 4.5](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) tells you when to move up. The setup is [Lesson 4.3](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/); the build is [Lesson 4.4](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/). + +### 3. 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 ($80-$120/hour market band, around $400-$600/week for 5 hours) 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. The [hire-track supplementary reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge) has the sourcing script. + +### 4. Hire a team + +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 (statement of work - the document listing exactly what the dev shop will build) [clause by clause](/course/tech-for-non-technical-founders-2026/sow-reading-guide/) and confirm that GitHub org, AWS root, domain registrar, and database all sit under your company email before kickoff (that is [Lesson 4.2](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/)). 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. For who to hire and how to interview them, see the [hire-track supplementary reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#where-to-find-developers-in-2026). + +## The Series-A off-ramp: when the model itself changes + +> All four paths above 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. + +## 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 lesson. Heavy on hiring, light on the validate-without-code path that comes first. +- Drew Falkman, *Vibe Coding Data-Enabled AI Apps* on Maven - the paid live 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. + +--- + +*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/hypothesis-sprint-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/hypothesis-sprint-full/index.md index 982d05f0d..022b26dd2 100644 --- 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 @@ -8,6 +8,8 @@ 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 6-step founding-hypothesis sprint as a numbered snake: 1 The Basics (five candidates per column), 2 Differentiator (faster, easier, or cheaper), 3 Three Approaches (one sentence each), 4 Magic Lenses (score 1-5 on four lenses), 5 Write It Down (the one Mad Libs sentence), 6 Design the Test (smoke test plus interviews) - one notebook, about 90 minutes, run alone](sprint-timeline.svg) + --- ## The Full 6-Step Sprint @@ -31,7 +33,7 @@ Beside the customer you circled, write three ideal-customer-profile (ICP) charac ### 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. +Draw three columns: *faster*, *easier*, *cheaper*. 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." @@ -73,14 +75,16 @@ The full test is two parts: (1) a smoke-test landing page for demand signal, and ## AI Deep-Research Prompts -### For the [customer] and [problem] blanks +### 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. +Find the 5 most-named pain points among [customer] (your candidate version of the blank) 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. ``` +Keep the quotes AND their thread URLs - Lessons 1.2 and 2.3 reuse them. + **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) diff --git a/content/course/tech-for-non-technical-founders-2026/reference/hypothesis-sprint-full/sprint-timeline.svg b/content/course/tech-for-non-technical-founders-2026/reference/hypothesis-sprint-full/sprint-timeline.svg new file mode 100644 index 000000000..16084d334 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/hypothesis-sprint-full/sprint-timeline.svg @@ -0,0 +1,78 @@ + + The six-step founding-hypothesis sprint, run alone in about 90 minutes + Six numbered step cards laid out as a snake - three across the top left to right, three across the bottom right to left - joined by arrows. Step 1 The Basics: five candidates per column. Step 2 Differentiator: faster, easier, or cheaper. Step 3 Three Approaches: one sentence each. Step 4 Magic Lenses: score 1 to 5 on four lenses. Step 5 Write It Down: the one Mad Libs sentence. Step 6 Design the Test: smoke test plus interviews. + + + + + + + + The 6-step founding-hypothesis sprint + One notebook, a kitchen timer, about 90 minutes - run it alone. + + + + + + 1 + The Basics + five candidates per column + + + + + 2 + Differentiator + faster, easier, or cheaper + + + + + 3 + Three Approaches + one sentence each + + + + + + + 4 + Magic Lenses + score 1-5 on four lenses + + + + + 5 + Write It Down + the one Mad Libs sentence + + + + + 6 + Design the Test + smoke test + interviews + + + + + + + + + + + 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/reference/mom-test-full/good-vs-bad-answers.svg similarity index 100% rename from content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/good-vs-bad-answers.svg rename to content/course/tech-for-non-technical-founders-2026/reference/mom-test-full/good-vs-bad-answers.svg diff --git a/content/course/tech-for-non-technical-founders-2026/reference/mom-test-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/mom-test-full/index.md new file mode 100644 index 000000000..5fb9258f6 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/mom-test-full/index.md @@ -0,0 +1,137 @@ +--- +title: "Full Reference: The Mom Test Technique" +description: "The complete Mom Test reference - the five past-behavior questions with pass/fail signals and follow-ups per question, the interview flow, the score-and-recover routine, and the full further-reading set. Companion to Lesson 2.1." +date: 2026-05-13 +draft: false +slug: mom-test-full +--- + +> **Reference companion to [Lesson 2.1 · The Mom Test](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/)** - the full pass/fail walkthrough for each of the five questions, the interview flow, the score-and-recover routine, and the complete further-reading set. Read the micro-lesson first for the minimum effective path; return here when you want the deep reference. + +--- + +![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 5 questions in full + +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 (virtual assistant), 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. + +## The interview flow + +```mermaid +%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, Comic Sans MS, 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[Emotional flags?] + Listen -->|0-1 flags| Generic[Polite mode -
    ask the follow-up, retry Q1] + Listen -->|2+ flags| Rest[Real felt problem -
    run Q2 - Q5 in order:
    cost, tried, 1-10 priority, who else] + Generic --> Q1 + Rest --> Score[Score the call 1-10] + Score -->|7+ with comparison, 3+ flags| Validated[Strong signal -
    ask for intro + prototype] + Score -->|5-6 or weak flags| Weak[Polite default - score as 5] + Score -->|0-4 or 0 flags| Fail[No felt problem - discount] + Validated --> Next[After 10 calls:
    7+ scores of 7+ = 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,Rest 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. + +Expect your first two or three interviews to feel awkward - you will catch yourself pitching at least once. That's normal, not failure: score the contaminated call honestly (in the [Module 2 walkthrough](/course/tech-for-non-technical-founders-2026/module-2-walkthrough-mia/), Mia breaks her own script in interview one, scores it 3/10, and keeps the other nine clean). The skill is in the recovery, not in being perfect on call one. + +One more failure mode worth naming: an interviewee with no story. If Q1 produces genuine blankness - not evasion, just no last time to walk through - they don't have the problem. End the call politely at the 10-minute mark and count it: a person who was supposed to be your customer and has no story IS data about your `[customer]` blank. + +## What to do tomorrow + +Three actions. In order. + +| Action | Why it matters | Gotcha to avoid | +|---|---|---| +| **Print [the Mom Test interview script](/course/tech-for-non-technical-founders-2026/mom-test-interview-script/) 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. | + +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 **[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. + +**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 Lesson 2.1 is the explanation of why it works. + +After 10 calls, you have either 10 scored transcripts that converge on a real problem (score them on [Lesson 2.5: Mom Test Synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/), then proceed to 2.6) or 10 transcripts that don't (follow Lesson 2.5's pivot path: sharpen the ICP and run 5 more interviews against the narrower group). + +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. + +> Customer interviews usually fail because the interviewees are polite. The questions do more work than interviewer charisma ever will. +> +> 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 tier) 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 Lesson 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. + +## 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) - 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. +- Teresa Torres, [Customer Interviews (Product Talk)](https://www.producttalk.org/customer-interviews/) - the story-based method behind Q1: collect specific past stories and excavate them, because people overestimate what they typically do. +- Teresa Torres, [Learning to Interview Continuously (Product Talk)](https://www.producttalk.org/learning-to-interview-continuously/) - how interviewers actually get good: anchor to specific moments, redirect general claims to concrete activities, and leave space for silence. + +--- + +*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/must-have-survey-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/must-have-survey-full/index.md new file mode 100644 index 000000000..f509f7204 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/must-have-survey-full/index.md @@ -0,0 +1,128 @@ +--- +title: "Full Reference: The Sean Ellis 40% Must-Have Survey" +description: "The complete must-have-survey reference - who to survey and who to strip, the send email, the per-segment scoring math, the decision tree, the under-40% diagnostic table, the read-by-count guide, and the full further-reading set. Companion to Lesson 5.1." +date: 2026-05-13 +draft: false +slug: must-have-survey-full +--- + +> **Reference companion to [Lesson 5.1 · Your First Customer Is Not a Marketing Problem](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/)** - who to survey and who to strip, the send email, the per-segment scoring math, the decision tree, the under-40% diagnostic table, the read-by-count guide, and the complete further-reading set. Read the micro-lesson first for the five questions and the score-it steps; return here when your result lands under 40% and you need the diagnostic table. + +--- + +## Who you survey, in full + +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. Treat anything under ten responses as directional only. 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. + +## 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. + +## Score it, in full + +Export the CSV. Pivot on Q1 by segment from Q5. You are computing one number per segment: + +```text +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 lesson. + +![Three segment cards showing what the blended 28% average hides: B2B Marketers at 64% must-have clear the 40% line, Solo Founders at 14% and Agencies at 0% do not](segment-isolation.svg) + +## The decision tree + +```mermaid +%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, Comic Sans MS, 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.
    Lesson 5.3 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. + +## Reading a small sample honestly + +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 - with 6 "very disappointed" out of 10 the threshold says PASS, but the confidence band is wide enough that real demand could be 20% or 80%. Under 10, segment-slice math does not work and the 25-40% bands do not apply. Read your first-pass count directionally instead, out of your 4-6 onramp users: + +- **0-2 "very disappointed"**: 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"**: directional STRONG YES. Advance to Lesson 5.3 but caveat your outreach decisions - the segment language is hypothesis, not verified. + +Use an under-10 reading to prioritize the next outreach batch, not to advance into Lesson 5.3 with confidence. + +## 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. | [Lesson 5.3](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) 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. | [Lesson 2.5](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) 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 [Lesson 2.4 outreach](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) (with the list-building method from [2.3](/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 in the lesson is enough for the Module 5 decision; +> the advanced version becomes relevant after your first 10 customers ship. + +## Further reading + +- Lenny Rachitsky, [The original growth hacker, Sean Ellis, on the 40% test](https://www.lennysnewsletter.com/p/the-original-growth-hacker-sean-ellis) - 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/2009/08/31/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. + +--- + +*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/must-have-survey-full/segment-isolation.svg b/content/course/tech-for-non-technical-founders-2026/reference/must-have-survey-full/segment-isolation.svg new file mode 100644 index 000000000..a6d31d138 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/must-have-survey-full/segment-isolation.svg @@ -0,0 +1,70 @@ + + Segment isolation without a Venn: three cohort cards side by side. The blended average of 28% hides one segment scoring 64%, which passes the 40% line and is the one to sell to first. + Three cohort cards. B2B Marketers score 64% must-have (9 of 14) and pass the 40% line, highlighted green and tagged sell here first. Solo Founders 14% (1 of 7) and Agencies 0% (0 of 7) fall below the line, shown neutral. A red dashed 40% line crosses each mini fill-bar; only the marketers' bar clears it. + + + + + + One blended average hides three different products. + Same 28 responses. The overall 28% looks like failure - until you slice by who the user is. + + + + B2B Marketers + 64% + must-have + + + + + 40% line + 9 of 14 said "very disappointed" + Use it daily. Dropped another tool. + + → SELL HERE FIRST + + + + Solo Founders + 14% + must-have + + + + 40% line + 1 of 7 said "very disappointed" + Tried it once. Forgot it existed. + Below the line - not now + + + + Agencies + 0% + must-have + + + 40% line + 0 of 7 said "very disappointed" + Already have an internal tool. + Never your buyer + diff --git a/content/course/tech-for-non-technical-founders-2026/reference/mvp-build-phases-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/mvp-build-phases-full/index.md new file mode 100644 index 000000000..ad0481410 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/mvp-build-phases-full/index.md @@ -0,0 +1,139 @@ +--- +title: "Full Reference: The Self-Serve MVP Build, Phase by Phase" +description: "The complete build guide behind Lesson 4.4 - the Lovable prompts, the first Supabase table and RLS self-test, the Stripe test flow, the 5 green lights in full, the shed envelope, cost tiers, and the pre-Module-5 invite wave." +date: 2026-05-18 +draft: false +slug: mvp-build-phases-full +--- + +> **Reference companion to [Lesson 4.4 · The Self-Serve MVP Stack: Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/)** - the step-by-step version of the four build phases, plus the onramp that hands you off to Module 5. Read the micro-lesson first for the minimum effective path; return here when you want the full mechanics for the phase you are on. + +--- + +This guide assumes you already ran Modules 1-3 (hypothesis, smoke test, 10 interviews, one-page brief) and read [Lesson 4.3: Tools & Setup](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/). Lesson 4.3 covers what each tool does, the 3 pre-flight rules, and the AI critic block; the $0 budget path, the full 12 build rules, the Module 2 prototype vs the Module 4 MVP distinction, and communities live in the [stack-and-tools reference](/course/tech-for-non-technical-founders-2026/reference/stack-tools-full/). The phases below reference those concepts without re-explaining them. Skip straight here without validation and the build ships into the silence Modules 1-3 were designed to prevent. + +> **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 the 10-week version, not the 4-week version. + +## 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. + +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).** +> +> Same audit as the Lesson 4.3 pre-flight rule - now run it against your real tables. +> +> *No-code path (the default for a non-technical founder - this is copy-paste verification, not programming: the AI writes the fix, you paste it and read the answer).* 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 Lesson 2.3-2.4 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 [Lesson 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 [Lesson 1.5 smoke test](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/) validated). Use [Stripe Checkout](https://docs.stripe.com/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 (roughly $10/year for a .com on [Porkbun](https://porkbun.com/) 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 five green lights.** The MVP is "done" only when all five gates are green: Stripe in LIVE mode with a real card cleared, a custom domain wired, at least 1 fresh ICP user (not from your Lesson 2.3-2.4 interviews) reaching the paywall, zero red errors in the browser Console on the sign-up + checkout flow, and a final-week demo recording. [Lesson 4.4 · Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/#the-five-green-lights) lists each light with its exact check. Advance to Module 5 only when all five are green; if any are red, the MVP is NOT ready for the 10-30 users Module 5 needs - fix the red light first, then re-check. + +> **Pre-flight before M5.1: book up to 10 user sessions.** The onramp phase's 4-6 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 Lesson 2.3-2.4 interviewee list, your community connections, or a fresh micro-batch of cold DMs. Aim for 10-30 active users by the time M5.1's survey ships - 5.1 treats 10 as directional-only and 20+ as a useful read. 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 Lesson 2.3-2.4 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 Lesson 2.3-2.4 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 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 [Lesson 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 Lesson 5.1's survey, the recruitment playbook in [Lesson 2.3-2.4](/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 + +[Lesson 4.1 · Should You Hire?](/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. + +## 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 + Supabase entry paid tiers + a .com domain (~$10/yr) + Resend entry tier + Stripe per-transaction fees | +| Post-launch | Scale-tier monthly fees | Lovable scale tier + Supabase paid tier + Resend/Sentry/monitoring paid tiers - check vendor pricing pages | + +The architectural ceiling tends to land at the post-launch tier - at roughly 5,000 users, route to [Lesson 4.5 · Ceiling Signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) 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. + +## When this path ends + +Self-serve has a ceiling. [Lesson 4.5 · Ceiling Signals](/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 across two consecutive monthly checks (the 4-week rule from Lesson 4.5), switch to the [hire-track supplementary reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/). Architecture does not collapse overnight; the warning shows up in the metrics before the customer sees it. + +The [Self-Serve Stack Walkthrough](/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/) artifact is the day-by-day version of these phases. 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. + +## Further reading + +- [Lesson 4.3: Tools & Setup](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) - why these three tools, what each one does, the 3 pre-flight rules, and the AI critic block +- [Stack & Tools reference](/course/tech-for-non-technical-founders-2026/reference/stack-tools-full/) - each tool in depth, the M2-vs-M4 contrast, all 12 build rules, and the founder communities +- [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/checkout/quickstart) and [Pricing page](https://stripe.com/pricing) +- Drew Falkman, "Vibe Coding Data-Enabled AI Apps" on Maven + +--- + +*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/outbound-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/outbound-full/index.md new file mode 100644 index 000000000..7403f7b5d --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/outbound-full/index.md @@ -0,0 +1,192 @@ +--- +title: "Full Reference: Cold Outbound Without a Sales Team" +description: "The complete cold-outbound reference - Product Hunt vs Indie Hackers data, the full tooling stack and pricing, domain warmup, the volume-and-funnel math, filter and personalization detail, all three cold-email script variants, the stage cadence, the no-reply diagnostic, and compounding past customer 20. Companion to Lesson 5.7." +date: 2026-05-13 +draft: false +slug: outbound-full +--- + +> **Reference companion to [Lesson 5.7 · Going Outbound Without a Sales Team](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/)** - the Product Hunt data, the full tooling stack, domain warmup, the funnel math, filter and personalization detail, all three script variants, the stage cadence, and the no-reply diagnostic. Read the micro-lesson first for the six-stage pipeline and the four-line script; return here when your batch returns no replies and you need the diagnostic. + +--- + +## 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." + +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 ([OpenHunts launch statistics](https://openhunts.com/blog/tech-product-launch-statistics-insights)). Product Hunt is not bad; it is a one-day event in a job that needs sustained motion over a quarter. + +Figma's first customer 11-20 cohort reportedly came from cold DMs to influential designers; Retool reportedly filtered Crunchbase by funding recency. Your Rails MVP customer 11-20 cohort will come from LinkedIn Sales Navigator (LinkedIn's paid search tool for filtering buyers by job title, company size, and industry) or Apollo, or both, feeding the four-line script. + +## The tooling stack + +You run the whole pipeline in six stages with off-the-shelf tools - no engineer, no $1,200/month sales stack, no Salesforce. + +The tooling is a volume choice, and both versions ship the same 30-message batch. The $0 stack - Apollo's free tier (Apollo is a B2B contact database that finds prospects' names and work emails; its free tier is credit-based - check the current allowance), a Google Sheet, a Gmail mail-merge add-on (sends the same email to many recipients at once, free), Loom, and Calendly - covers every stage; you enrich the list by hand in the sheet, which costs your time. The paid version swaps the manual enrichment for automation through Smartlead or Apollo's paid tiers, which costs money and pays off once you're sending 100+ messages a week and the hand-enrichment is the bottleneck. At this 30-message volume, either works - pick by whether your scarcer resource is hours or dollars. + +The five tools and their 2026 pricing: + +| Tool | Role | Price | +|---|---|---| +| LinkedIn Sales Navigator | Filter buyers by title, company size, funding signal, role tenure | Paid single-user plans - check LinkedIn pricing | +| Apollo.io (Starter / free tier) | Cheaper alternative to Sales Nav for B2B email + filters | Free tier available; paid plans for scale | +| Loom | 90s product walkthrough + you on camera | Free tier available | +| Calendly | 15-min demo booking, auto-confirm | Free tier supports one event type | +| Stripe Invoice | Pilot deposit, no monthly fee | Per-transaction card fee, no monthly cost - [Stripe pricing](https://stripe.com/pricing) | + +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 Smartlead from the tooling choice above) 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. 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 [Lesson 2.3 · 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 Lesson 2.3-2.4 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 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 (a small monthly allowance of email and export credits). The "pull 100-150 raw rows" instruction usually exceeds one month of free credits, so either spread it over time 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 a paid Apollo tier 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 (all 3 variants) + +The lesson carries the B2B SaaS variant. Here are all three - each follows the same shape: a specific reference earns the open, one sentence on what you built, one specific ask with friction removed, one currency anchor. Total length: 4-6 lines including subject. + +### Variant 1: B2B SaaS, shipped-MVP context + +```text +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 10 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 + +```text +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 + +```text +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] +``` + +## Stage-by-stage cadence + +![Six-stage outbound cadence: Stage 1 send 30 messages with 1-4 replies expected, Stage 2 run 3-5 demos with 2-3 DPAs sent, Stage 3 1-2 deposits cleared with pilot kickoffs scheduled, Stage 4 send next 20 and hold for reply tail, Stage 5 first Friday demos plus earlier prospects mature, Stage 6 year-one conversions plus next 20 cold names](stage-cadence.svg) + +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. + +## 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. + +## Advanced (optional sidebar) + +Once you have closed 5-10 paid pilots from cold outbound and want to layer on sales-system rigor, read First Round Review's [sales article collection](https://review.firstround.com/articles/sales/), Sahil Bloom's [Curiosity Chronicle newsletter](https://www.sahilbloom.com/newsletter), and the [Y Combinator library on founder-led sales](https://www.ycombinator.com/library/Mo-the-sales-playbook-for-founders). 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 (account executive - a dedicated salesperson), Mike Weinberg's *New Sales. Simplified.* for the manager handbook. The main path gets you from customer 11 to customer 20. The advanced versions matter after that. + +## 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 | + +## Further reading + +- OpenHunts, [Product Launch Statistics: Success Rates & Data](https://openhunts.com/blog/tech-product-launch-statistics-insights) - the primary source for the Product Hunt 3.1% vs Indie Hackers 23.1% per-engaged-post conversion data (387-launch 2024 study, 156 founders surveyed). +- 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. +- Lenny Rachitsky, [How the biggest consumer apps got their first 1,000 users](https://www.lennysnewsletter.com/p/how-the-biggest-consumer-apps-got) - first-users tactics from Airbnb, Tinder, Etsy, Reddit and more. +- 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, [The Sales Playbook for Founders](https://www.ycombinator.com/library/Mo-the-sales-playbook-for-founders) - YC's playbook on founder-led sales, from first pilots to closed recurring revenue. +- Sahil Bloom, [The Curiosity Chronicle](https://www.sahilbloom.com/newsletter) - his newsletter on early traction and the relationship-to-cold transition that closes the personal-network gap. + +--- + +*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/outbound-full/stage-cadence.svg b/content/course/tech-for-non-technical-founders-2026/reference/outbound-full/stage-cadence.svg new file mode 100644 index 000000000..27e8ea765 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/outbound-full/stage-cadence.svg @@ -0,0 +1,96 @@ + + The six-stage outbound cadence + A snake-path diagram of six weekly stages. Row one, left to right: Stage 1, send 30 messages, 1-4 replies expected, tinted cold red. Stage 2, run 3-5 demos, 2-3 DPAs sent, tinted warm purple. Stage 3, 1-2 deposits cleared, pilot kickoffs scheduled, tinted conversion amber. The path drops down under Stage 3, then row two continues right to left: Stage 4, send next 20, hold for reply tail, tinted cold red. Stage 5, first Friday demos plus earlier prospects mature, tinted warm purple. Stage 6, year-one conversions plus next 20 cold names, tinted conversion amber. A legend below explains the three tints: cold outreach, warm pipeline, conversion. + + + + + + + + + The six-stage outbound cadence + Cold sends and warm follow-ups, running the same week. + + + + + + 1 + Send 30 messages + 1-4 replies expected + + + + + + 2 + Run 3-5 demos + 2-3 DPAs sent + + + + + + 3 + 1-2 deposits cleared + Pilot kickoffs scheduled + + + + + + + + + + + + + + 4 + Send next 20 + Hold for reply tail + + + + + + 5 + First Friday demos + + earlier prospects mature + + + + + + 6 + Year-one conversions + + next 20 cold names + + + + + + + + + Cold outreach + + Warm pipeline + + Money lands + 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/reference/outcomes-not-features-full/feature-vs-outcome.svg similarity index 100% rename from content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/feature-vs-outcome.svg rename to content/course/tech-for-non-technical-founders-2026/reference/outcomes-not-features-full/feature-vs-outcome.svg diff --git a/content/course/tech-for-non-technical-founders-2026/reference/outcomes-not-features-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/outcomes-not-features-full/index.md new file mode 100644 index 000000000..c3be894c3 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/outcomes-not-features-full/index.md @@ -0,0 +1,84 @@ +--- +title: "Full Reference: Features to Outcomes" +description: "The complete outcomes-not-features reference - two fully worked feature-vs-outcome pairs, the priced-out comparison, the full AI-reviewer test protocol, and stack-ranking outcomes with real users. Companion to Lesson 3.2." +date: 2026-05-18 +draft: false +slug: outcomes-not-features-full +--- + +> **Reference companion to [Lesson 3.2 · Quality-check your brief: features to outcomes](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/)** - the two fully worked feature-vs-outcome pairs, the priced-out comparison, the complete AI-reviewer test protocol, and the optional stack-ranking step. Read the micro-lesson first for the three-part rewrite and the pass/fail rubric; return here when a Section 3 line still reads feature-shaped and you want a worked pair. + +--- + +## 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 bristling with 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 (monthly recurring revenue - what subscribers pay you each month), 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."* (A CRM - customer relationship management tool - is the contact list and deal tracker a sales team works out of.) + +**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 same request, priced out + +| | Feature brief | Outcome brief | +|---|---|---| +| **What you write** | "Build a CRM module" | "Match new signups to 3 similar customers" | +| **What the team builds** | Companies + contacts, deals + pipelines, email + calendar integration, custom fields + Kanban | A nightly scoring script + a Slack message each morning | +| **What it costs** | 3 months. $40K. | 2 days. $600. | +| **What you actually use** | Contacts + notes | The onboarding playbook, ready Monday | + +The lineage of the *When / I want / So I can* shape has a name in product-management literature - "Job Stories." See *Further reading* below if you want to chase it. + +## Test your brief with an AI reviewer + +**No peer available? Use [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) as the peer.** Paste your full Section 3 + Section 5 (no-go list), 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 the AI 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. + +**No peer and no AI account?** The manual pass works too: read each Section 3 line and ask, "is this a thing the user does, or a thing the software has?" A line that names software parts (a dashboard, user roles, a settings page) is feature-shaped - rewrite it in the *When / I want / So I can* shape until it names a moment and a result instead. + +**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 is a clean peer QA (human or AI) where the answer stays inside your scope AND no-go list. + +## 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 [Lesson 2.3-2.4](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) 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. + +## Further reading + +- Alan Klement, [*When Coffee and Kale Compete*](https://web.archive.org/web/20230319130354/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://web.archive.org/web/20240819160036/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. + +--- + +*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/github-aws-database-ownership-checklist/bad-vs-good-email.svg b/content/course/tech-for-non-technical-founders-2026/reference/ownership-full/bad-vs-good-email.svg similarity index 100% rename from content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/bad-vs-good-email.svg rename to content/course/tech-for-non-technical-founders-2026/reference/ownership-full/bad-vs-good-email.svg diff --git a/content/course/tech-for-non-technical-founders-2026/reference/ownership-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/ownership-full/index.md new file mode 100644 index 000000000..3d0d44dcc --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/ownership-full/index.md @@ -0,0 +1,84 @@ +--- +title: "Full Reference: Infrastructure Ownership" +description: "The complete ownership reference - the 2026 AI-contractor credential trap, the good-vs-bad walkthrough for the three items that fail most, the three-step recovery sequence, the advanced hardening notes, and the full further-reading set. Companion to Lesson 4.2." +date: 2026-05-13 +draft: false +slug: ownership-full +--- + +> **Reference companion to [Lesson 4.2 · Who Owns Your GitHub, AWS, and Database?](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/)** - the 2026 credential trap, the good-vs-bad walkthrough for the three items that fail most, the full recovery sequence, and the advanced hardening notes. Read the micro-lesson first for the 12-item audit and the Friday routine; return here when an item fails and you need the deep recovery detail. + +--- + +![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) + +## The 2026 credential trap looks different + +The contractors who create single points of failure 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 contractor 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 support recovery while your customers see a maintenance page. None of that hits the budget line that says "engineering." + +## 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 (the same two-factor login code) 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 Marcos" as the answer to "who can rotate this?" + +Three pairs that come up most often in ownership 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 (a limited-permission login, not the all-powerful root account) 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 contractor 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: "Marcos 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 (database administrator - the person who manages your production database)." + +The Marcos answer means you have a single point of failure. It does not matter whether Marcos is honest, kind, or available - one person holding the prod DB password is one person away from a production outage you cannot fix. Firing Marcos does not fix it. Putting the credential in a store you administer, with Marcos 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/en/contracted-parties/accredited-registrars/resources/domain-name-transfers/policy) gives your current registrar up to five days to hand over the transfer auth code, allows a further five-day window for the losing registrar to release the transfer once you request it, and many registrars add a 60-day lock after registration or a recent transfer during which transfers cannot start at all. If someone else 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. + +## When the audit fails: a recovery plan that takes weeks, not months + +Most audit failures are sloppy Day-1 setup, not malice. The contractor 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 contractor 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 (intellectual property - your source code and data, legally distinct from an IP network address) | 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 [ownership checklist template](/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. + +## 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 Marcos 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/en/contracted-parties/accredited-registrars/resources/domain-name-transfers/policy) - the rules every domain registrar must follow when transferring a domain between accounts, including the 60-day lock and the five-day code-release and transfer-release 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. + +--- + +*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/github-aws-database-ownership-checklist/ownership-zones.svg b/content/course/tech-for-non-technical-founders-2026/reference/ownership-full/ownership-zones.svg similarity index 83% rename from content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/ownership-zones.svg rename to content/course/tech-for-non-technical-founders-2026/reference/ownership-full/ownership-zones.svg index 8fe5109fd..409821304 100644 --- 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/reference/ownership-full/ownership-zones.svg @@ -2,12 +2,12 @@ The four ownership zones a non-technical founder must control: code, cloud, secrets, and domain - Vibe PRD - Bad vs Good + Vibe PRD - Bad vs Good - BAD + BAD - "Build a CRM" + "Build a CRM" - 1. The problem + 1. The problem (blank) - 2. The user + context + 2. The user + context "Founders need a better way to manage customer relationships." - 3. What you're building + 3. What you're building "A modern CRM with great UX, integrations, and AI features." - 4. Success metric + 4. Success metric "Lots of happy users." - 5. What you're NOT building + 5. What you're NOT building (blank) Result: Lovable builds a settings @@ -57,31 +58,31 @@ - GOOD + GOOD - Stripe - QuickBooks reconciler + Stripe - QuickBooks reconciler - 1. The problem + 1. The problem Pre-seed SaaS founders, 6 hrs/week on Stripe - QB reconciliation. 8/10 confirmed, May 2026 sample. - 2. The user + context + 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 + 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 + 4. Success metric 10 of first 20 signups convert 1+ file in 30 days. Event: conversion_completed. - 5. What you're NOT building + 5. What you're NOT building Multi-currency - multi-Stripe - auto-sync - settings page - roles - mobile beyond 1024px - marketing diff --git a/content/course/tech-for-non-technical-founders-2026/reference/product-brief-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/product-brief-full/index.md new file mode 100644 index 000000000..52ebfdabd --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/product-brief-full/index.md @@ -0,0 +1,130 @@ +--- +title: "Full Reference: The One-Page Product Brief (Vibe PRD)" +description: "The complete Product Brief reference - a worked example and common mistake for all five sections, the choice between a Vibe PRD and a traditional PRD, and when a paid cohort is worth it. Companion to Lesson 3.1." +date: 2026-05-18 +draft: false +slug: product-brief-full +--- + +> **Reference companion to [Lesson 3.1 · The One-Page Product Brief (Vibe PRD)](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/)** - a worked example and common mistake for each of the five sections, the decision between a Vibe PRD and a traditional PRD, and when a paid cohort is worth it. Read the micro-lesson first for the five-section template and the do-this-now sitting; return here when you want the worked example for a section you are stuck on. The fillable form lives on the [Vibe PRD Template](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) page. + +--- + +![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 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. + +## 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 sections in full + +### Section 1 - The problem (lifted from your Lesson 2.5 synthesis) + +What goes in it: one paragraph copied directly from your [validated problem statement](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/). Named persona, named industry, dated 10-call sample, one verbatim quote, one quantified cost, and the one-line why-now from your problem statement. + +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 full of 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 (a plain spreadsheet-style file exported from Stripe) 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 (they type their email and click a one-time sign-in link - no password to build or store). 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, a satisfaction score) 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) (an AI coding tool developers run on their own machines), and a hired junior all fill blanks with reasonable defaults, and reasonable defaults stack into a settings page nobody asked for. The same shape is how a founder ends up with 17 settings toggles in version one - 12 wired to nothing, 2 that crash on toggle. + +## 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, Comic Sans MS, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%% +flowchart TD + Start(["Brief written"]) + Start --> Q1{Who builds
    from it?} + Q1 -->|AI agent| Vibe1[Vibe PRD
    hand as-is] + Q1 -->|Hired junior| Vibe2[Vibe PRD
    + kickoff call] + Q1 -->|Senior engineer| Trad1[Traditional PRD
    3-5 pages] + Q1 -->|Committee / board| Trad2[Traditional PRD
    5-10 pages] + Vibe1 --> Ship1[Short build loop] + Vibe2 --> Ship1 + Trad1 --> Ship2[Long build loop] + 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 classic trap 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 a paid cohort course is worth it + +Drew Falkman runs "Vibe Coding Data-Enabled AI Apps" on Maven, a multi-week live cohort (paid - check the course page for current pricing and format). 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. + +| 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 much of its time on exactly this. | No. You'll need the stack tutorials anyway; the template is concept-only. | +| You can sit alone for 90 minutes 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 90 minutes and finish the brief, start here. The cohort buys structure, deadline, and stack depth. If you can't sit alone, the cohort fee buys the accountability that gets the brief out of you. + +## Further reading + +- Drew Falkman, "Vibe Coding Data-Enabled AI Apps" on Maven - the paid live cohort that teaches the Vibe PRD with instructor 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. + +--- + +*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/prototype-build-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/prototype-build-full/index.md new file mode 100644 index 000000000..704aea61f --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/prototype-build-full/index.md @@ -0,0 +1,204 @@ +--- +title: "Full Reference: The Clickable Prototype - Build, Sessions, and Scoring Detail" +description: "The complete clickable-prototype reference - why interviews miss shape signal, the screen-by-screen Lovable build, the filled worked example, the full silent-observation script, the combined Module 2 decision matrix, and the artifacts map. Companion to Lesson 2.6." +date: 2026-05-18 +draft: false +slug: prototype-build-full +--- + +> **Reference companion to [Lesson 2.6 · Build a Clickable Prototype](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/)** - the extended theory, the screen-by-screen build, a filled worked example, the full verbatim session script, the combined Module 2 decision matrix, and the artifacts map. Read the micro-lesson first for the minimum effective path; return here for the deep walkthrough. + +![Wireframe of a passing 3-screen prototype: Screen 1 entry point with a fake file list and a Match transactions button, Screen 2 core action showing a Stripe-vs-QuickBooks match table where testers stall, and Screen 3 result with a summary card and Download report - the screen a passing tester reaches without coaching](wireframe-strip.svg) + +--- + +## 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. + +The prototype session is the third validation pillar. 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](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) shows whether the problem you found is one your interviewees actually feel. Neither answers 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, Comic Sans MS, 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 +``` + +### The build that skipped this step + +A founder we advised 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 [Lesson 4.3](/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. + +## 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 + +Three screens is the constraint - not five, not ten - because each extra screen multiplies the build effort without sharpening the validation signal. + +### 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. + +### 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 lift the cap - check Lovable's pricing page.** They only become worth it if you later need higher message volume - not required for this prototype. + +If you hit the daily message cap mid-build: 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 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. + +### Filled-in worked example + +Below is the build 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 [Lesson 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. + +## Run a Silent-Observation Session with 5 Interviewees + +### 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 for 30 minutes 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. + +> **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 a handful of testers - check current limits) 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. Recordings surface less than live sessions do (you miss the "what were you about to click" follow-ups), and still far more 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. + +**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 [Lesson 1.5](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/) - if you haven't run that test yet, the $49-$299 band from the [full price-test reference](/course/tech-for-non-technical-founders-2026/reference/stripe-price-test-full/) 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. + +### 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 Combined Module 2 Decision Matrix + +Each signal has its own iteration guidance (Lesson 2.5's build/pivot/kill call on the scored interviews, and the Lesson 2.6 pass count). The COMBINED decision uses both signals together: + +| Interview signal (Lesson 2.5 synthesis) | Lesson 2.6 prototype signal | Decision | +|---|---|---| +| 7+ of 10 scored ≥7 | 4-5 of 5 passed | **PROCEED** - write the Lesson 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) | +| 4-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) | +| 4-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 Lesson 1.1) | +| Under 4 of 10 scored ≥7 | (any) | **KILL** - the problem is too weak for this ICP. Return to Lesson 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 Lesson 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. + +## Artifacts You Carry Out of Module 2 + +After finishing Lesson 2.1-2.6, you have five artifacts. Each one feeds a specific downstream destination - this table is the map: + +| Artifact | Where it goes next | +|---|---| +| **Validated Problem Statement** (Lesson 2.5 synthesis applied to your Lesson 2.3-2.4 transcripts) | Lesson 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 matrix above routes you to a revision or restart. | +| **Verbatim "describe in one sentence" vocabulary** (closing answers from this chapter) | Lesson 3.1 Section 3 ("what you're building") + Lesson 4.3-4.4 Lovable prompts. The user's words beat your marketing copy. | +| **10 raw transcripts** (Lesson 2.3-2.4 interview recordings + notes) | Archive. Reference if you ever pivot - they hold the language for a re-targeted ICP. | +| **30 raw verbatim sentences** (Lesson 2.3-2.4 step 2, Reddit/forum complaints) | Reference for Lesson 3.1 Section 1 supplementary evidence + the bank for Lesson 2.3-2.4 cold-message subject lines in any future round 2. | + +## 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. +- Y Combinator, [How to Talk to Users (Startup Library)](https://www.ycombinator.com/library) - 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. + +--- + +*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/) curriculum.* diff --git a/content/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/wireframe-strip.svg b/content/course/tech-for-non-technical-founders-2026/reference/prototype-build-full/wireframe-strip.svg similarity index 79% rename from content/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/wireframe-strip.svg rename to content/course/tech-for-non-technical-founders-2026/reference/prototype-build-full/wireframe-strip.svg index fda7a0ab2..b2f39812b 100644 --- a/content/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/wireframe-strip.svg +++ b/content/course/tech-for-non-technical-founders-2026/reference/prototype-build-full/wireframe-strip.svg @@ -2,14 +2,14 @@ A passing 3-screen prototype: Screen 1 entry point (fake file list + a Match transactions button) leads to Screen 2 core action (a Stripe-vs-QuickBooks match table where testers stall) leads to Screen 3 result (a summary card and Download report), which is where a passing tester lands without coaching. + + + 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. + Split 60% Reels / 40% feed. + $0.70 - $1.90 per click + Best targeting for broad consumer reach. + + + + + + B2B, sold by job title + LinkedIn or Google Search + LinkedIn: unaware audience. + Google: already searching for a fix. + $3 - $22 per click + Job-title + company-size targeting. + + + + + + Developer tools / technical + Reddit Ads + r/programming, r/webdev, + r/SaaS - where devs already are. + $1.25 - $3 per click + Skip if procurement is non-technical. + + + + + + Niche vertical + (real estate, dentists, contractors) + Google Search + Long-tail keywords with + clear purchase intent. + $1 - $5 per click + + + + + Twitter / X: skip for first-time validation in 2026 - targeting signal too noisy. + 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 index 0051a844f..9ed3e9420 100644 --- 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 @@ -42,7 +42,7 @@ Picking the channel takes minutes; getting the ad account approved and ready to ## B2B on a Small Budget -If your ideal customer profile (ICP) says LinkedIn but $1,800+ is out of reach, three viable substitutes at ~10% of the cost: +If your ideal customer profile (ICP) says LinkedIn but $1,800+ is out of reach, three viable substitutes - two free, one at a fraction of the cost: | Alternative | How | Cost | |---|---|---| @@ -56,25 +56,27 @@ Use one of these, run it the same way until the numbers stabilize, read the resu ## Channel by ICP (Full Breakdown) +![Channel-by-ICP matrix: Meta for B2C consumer at $0.70-$1.90 per click, LinkedIn or Google Search for B2B at $3-$22, Reddit Ads for developer tools at $1.25-$3, Google Search for niche verticals at $1-$5, and skip Twitter/X for first-time validation in 2026](channel-icp-matrix.svg) + ### B2C Consumer -**Channel:** Meta ($0.70-$1.90 CPC). Split 60/40 Reels/feed. -**When to pick:** Product is visual, audience is broad. -**Skip when:** Customer 55+ OR enterprise. +- **Channel:** Meta ($0.70-$1.90 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.70-$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. +- **Channel:** LinkedIn ($5.70-$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.25-$3 CPC). -**When to pick:** Audience in r/programming, r/webdev, r/SaaS. -**Skip when:** Non-technical procurement role. +- **Channel:** Reddit Ads ($1.25-$3 CPC). +- **When to pick:** Audience in r/programming, r/webdev, r/SaaS. +- **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. +- **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. @@ -99,11 +101,37 @@ You picked your channel above and created your ad account. Here are the settings **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. +### Write the Ad With AI (Copy + Image) + +You do not have to invent ad copy from a blank page. You already have everything the ad needs: your Founding Hypothesis, your landing page words, and your customer's own pains and goals. Paste this prompt into any AI chat tool (ChatGPT, Claude, Gemini) - fill the brackets with what you have, set `[channel]` to Meta, Google, LinkedIn, or Reddit, and it writes the ad for you: + +```text +You are a direct-response copywriter writing a first test ad for a product that has not launched yet. The goal is a simple demand test: get the right people to click through to a landing page and hand over an email. No hype, no fake urgency - just clear words in the customer's own language. + +Here is everything I have: +- Founding Hypothesis: [paste your one-sentence hypothesis from Lesson 1.1] +- Landing page headline: [paste your headline] +- Landing page value props: [paste your 2-4 value prop lines] +- Customer pains, in their own words: [paste the exact phrases your customers use - from interviews, Reddit, reviews] +- Customer gains / goals: [what they are trying to achieve - the win they want] +- Channel this ad runs on: [channel] + +Write me: +1. Two to three PRIMARY TEXT variants (the main ad body). Use the customer's own vocabulary from the pains above - not marketing language. Match the tone of [channel] (Reddit = casual and honest, LinkedIn = professional, Meta = friendly and visual, Google = short and intent-driven). +2. Two HEADLINE variants (short, under 40 characters where the channel needs it). +3. One IMAGE CONCEPT: describe a single image I can either generate with an AI image tool or fake with a simple product screenshot. Tell me exactly what should be in the frame and why it fits the message. +4. A plain-English note telling me WHICH variant to run first and why - written so a non-marketer understands the reasoning. + +Keep every variant honest to the hypothesis. Do not promise features the product may not have. +``` + +Run the ad it gives you first. If the click-through rate is low, come back to this prompt and ask it for a second round using a different pain from your list. + ### 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. +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.2, 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.4, step 1). In Ads Manager, under the ad set, verify the pixel is selected. If it says "No pixel," go back to that step and install it. @@ -113,7 +141,7 @@ You picked your channel above and created your ad account. Here are the settings 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." +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.3). 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. @@ -122,7 +150,7 @@ You picked your channel above and created your ad account. Here are the settings 1. **Campaign objective:** Website visits. 2. **Budget:** $50-80/day minimum (LinkedIn CPC is $5.70-$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). +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.4, step 1). In Campaign Manager, the tag should auto-detect if it's on your page. @@ -132,7 +160,7 @@ You picked your channel above and created your ad account. Here are the settings 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. +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.4, step 1). In Ads Manager, the pixel status should show "Active." diff --git a/content/course/tech-for-non-technical-founders-2026/reference/stack-tools-full/index.md b/content/course/tech-for-non-technical-founders-2026/reference/stack-tools-full/index.md new file mode 100644 index 000000000..8bf9d564f --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/stack-tools-full/index.md @@ -0,0 +1,140 @@ +--- +title: "Full Reference: The Self-Serve MVP Stack" +description: "The complete self-serve stack reference - each tool in plain English, the M2-prototype-vs-M4-MVP contrast, the two build-time AI audits, all 12 build rules, the founder communities, and the full further-reading set. Companion to Lesson 4.3." +date: 2026-05-18 +draft: false +slug: stack-tools-full +--- + +> **Reference companion to [Lesson 4.3 · The Self-Serve MVP Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/)** - each tool in plain English, the throwaway-prototype-vs-production-MVP contrast, the two build-time AI audits, all 12 build rules, and the founder communities. Read the micro-lesson first for the tool boundaries and the 3 pre-flight rules; return here when you want the depth on any one tool or rule. + +--- + +## 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. + +How much demand evidence you already have decides the path. With enough of it, you open Lovable and build. Without it, a $0 Concierge MVP - a no-code "Wizard of Oz" where you fake the automation by hand behind the curtain - gets you more evidence before you commit to Lovable code. Wire up 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, and you process it by hand. To the customer it looks automated, so you validate willingness-to-pay before writing code. The trade-off is that you run it by hand, which makes it a stepping stone, not a replacement. Either way, the Lovable + Supabase + Stripe stack is what ships in [Lesson 4.4](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/). + +## M2 prototype vs M4 MVP - different artifacts, different rigor + +The [Module 2 clickable prototype](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/) (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. + +| | 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) + +It is tempting to ask "which framework" before you 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](https://lovable.dev/pricing) runs from a capped free tier through paid tiers sized by build velocity - check the pricing page for current numbers. Expect to move to a mid or scale tier after the first month once build velocity picks up. + +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 (a widely used database) + auth (the login and signup system) + file storage + row-level security (rules that keep each user's rows private to them) 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 comfortably covers early-stage usage - [check Supabase's pricing page](https://supabase.com/pricing) for current limits. Early-stage usage rarely outgrows the first paid tier before you hit the architectural ceiling. + +Supabase auto-generates a REST API (a standard way for one program to request data from another) 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. The auth product replaces most 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 [per-transaction card processing rate](https://stripe.com/pricing) for cards in the US (a small percentage plus a flat per-charge amount); 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 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 (short for repository - the online folder that stores your code) 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 a founder cannot retrieve the source six months later. + +## Have AI review the build + +The [Lesson 4.3 pre-flight leakage check](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) runs against your brief before you build. These two audits run against the actual build once it exists - during the Phase 1-4 build in [Lesson 4.4](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/). + +**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 + [Lesson 4.5](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) ceiling signals can) + +**The real gate:** 5 green lights (Phase 4 exit criteria in [Lesson 4.4](/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 MVP done right + +3 rules need to be true BEFORE you open Lovable (rules 1, 2, and 6 - the pre-flight rules taught in Lesson 4.3). The rest fire inline during the Phase 1-4 build. 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. + +1. **Start from a one-page brief that passed the Lesson 3.2 quality-gate.** If Section 3 is feature-shaped, fix it before you open Lovable. Feature-shaped briefs produce sprawling 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 Lesson 2.6 throwaway prototype.** Start the 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 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 [Lesson 4.5](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) 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 the production hardening section of the [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 a paid tier 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 Lesson 4.5 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 two ceiling signals firing for 4+ weeks.** 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 reference, the [self-serve stack walkthrough](/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/), [Lesson 4.5 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/). + +## 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 | Best for | Cost | +|---|---|---| +| **[Lovable Discord](https://lovable.dev/community)** | Real-time UI troubleshooting; Lovable team answers in channels; monthly hackathons | Free | +| **[Indie Hackers](https://www.indiehackers.com/)** | Honest revenue posts + shipping logs; Friday-demo accountability rhythm | Free + paid tier | +| **[No Code Founders (NCF Slack)](https://www.nocodefounders.com/)** | If Lovable is wrong for your UI shape; worth membership even if you stay on Lovable | Free membership | +| **r/nocode + r/vibecoding (Reddit)** | Lower signal-to-noise than Slack; search before post | Free | +| **[Buildspace + Maven cohorts](https://maven.com/)** | Peer cohort + office hours; best when a deadline is what makes you ship | Paid - check the course page | + +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 + +- [Lesson 4.4: Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/) - the companion lesson: 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/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/) + +--- + +*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 index 8fa6bff67..ef9fd8c78 100644 --- 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 @@ -8,6 +8,8 @@ slug: stripe-price-test-full > **Reference companion to [Lesson 1.5 · 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 Stripe price-test flow: 1 create the Payment Link (one-time product at your price), 2 wire it to the page button in live mode, 3 read the visit-to-Stripe-click rate - then act on the band: under 5% iterate on price, 5-10% advance to interviews, over 10% verify with a second cold channel](price-test-flow.svg) + --- ## The Maya Story (Full Version) @@ -94,9 +96,9 @@ 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 hypothesis: [paste your one-sentence Founding Hypothesis from Lesson 1.1] My test price: [e.g., $97 one-time founding member access] -My target customer: [e.g., freelance bookkeepers who reconcile client accounts manually] +My target customer (the [customer] blank from the hypothesis above): [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: @@ -115,9 +117,11 @@ SUB-COPY: [one sentence under the button] 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. +What do [customer] 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. ``` +Reuse the quotes you already pulled in Lesson 1.2's research prompt - this search is for PRICES, not pains. + **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. diff --git a/content/course/tech-for-non-technical-founders-2026/reference/stripe-price-test-full/price-test-flow.svg b/content/course/tech-for-non-technical-founders-2026/reference/stripe-price-test-full/price-test-flow.svg new file mode 100644 index 000000000..6772ab835 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/reference/stripe-price-test-full/price-test-flow.svg @@ -0,0 +1,97 @@ + + The Stripe price-test flow: build the Payment Link, wire it to the page, read the click rate, then act on the band it lands in. + Three numbered step cards in a row: create the Stripe Payment Link with a one-time product at your hypothesis price, wire it to the landing-page button in live mode, and read the visit-to-Stripe-click rate. The rate forks into three outcome bands. Under 5 percent, amber: iterate - cut the price by half, add founding-member framing; below 2 percent means the audience or hypothesis is wrong, not the price. Five to ten percent, green: advance - the price is validated, move to Module 2 interviews and email everyone who clicked but did not buy. Over 10 percent, purple: verify - run a second cold channel; if both hold the signal is real, if one spikes the targeting was hot, not the pricing. + + + + + + + + The Stripe price test, step by step + An email costs nothing; a card entry costs intent. Measure the one that counts. + + + + + + + + 1 + Create the Payment Link + one-time product, your price + + + + + + + 2 + Wire it to the button + live mode, not test mode + + + + + + 3 + Read the click rate + page visits → Stripe clicks + + + + + + + + + + + + + + + + Under 5% - iterate + Cut the price 50%, add a + "founding member" framing. + Below 2% after that = the + audience is wrong, not the price. + + + + + 5 - 10% - advance + Price-validated. Move to + Module 2 customer interviews. + Email everyone who clicked + but didn't buy - your best group. + + + + + Over 10% - verify + Run a second cold channel. + Both hold → the signal is real. + One spikes → hot targeting, + not your pricing. + + 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 index 9123b2041..ae0e724f7 100644 --- 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 @@ -24,9 +24,7 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 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 +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. A 30-minute decision that ends two weeks of analysis paralysis and gives you a defensible verdict by Friday night. @@ -34,7 +32,9 @@ By Sunday morning you will know whether to KEEP your codebase, FREEZE it for 60 ## 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. +A founder I worked with 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. + +*Illustrative composite based on patterns from real founder builds, not a single client story.* 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. @@ -65,9 +65,9 @@ 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. | +| **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. diff --git a/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/build-phases-strip.svg b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/build-phases-strip.svg new file mode 100644 index 000000000..22dd28aae --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/build-phases-strip.svg @@ -0,0 +1,81 @@ + + Four build phases, then the five-green-lights gate. Phase 1 Lovable UI: screens click, nothing saved. Phase 2 Supabase and auth: a real signup persists. Phase 3 Stripe checkout: a one-dollar test charge clears. Phase 4 go live: five ICP users click. All five lights green - Stripe in live mode, custom domain wired, one fresh ICP user hit the paywall, zero JS errors on signup and checkout, a weekly demo recording exists - advances you to Module 5. + Four numbered phase cards in a row - Phase 1 Lovable UI, Phase 2 Supabase and auth, Phase 3 Stripe checkout, Phase 4 go live - each with its demo line, joined by arrows. An arrow drops into a wide green gate card below listing the five exit lights: Stripe live, custom domain wired, one fresh ICP user hit the paywall, zero JS errors, weekly demo recording exists. All five green advances to Module 5. + + + + + + + + Four phases, then the five green lights + One demo per phase - the demo is the data, not the screens. + + + + + + 1 + Lovable UI + Screens click, + nothing saved yet + + + + + 2 + Supabase + auth + A real signup + persists on refresh + + + + + 3 + Stripe checkout + A $1 test charge + flips the row to paid + + + + + 4 + Go live + 5 ICP users click + the live URL + + + + + + + + + + + + + + All 5 lights green → advance to Module 5 + ✓ Stripe in LIVE mode - a real card clears + ✓ Custom domain wired (not .lovable.app) + ✓ 1 fresh ICP user hit the paywall + ✓ Zero JS errors on signup + checkout + ✓ A weekly demo recording exists + Any light red = fix it first, then re-check. + + 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 index 748db0c9a..230bd0ced 100644 Binary files a/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/cover.png 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 index 123461868..22f60fcdf 100644 --- 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 @@ -1,6 +1,6 @@ --- title: "4.4 · 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. Companion build guide to Chapter 4.3 (Tools & Setup)." +description: "The build plan: 4 phases from Lovable UI to live Stripe checkout, one demo each, and the 5 green lights that mean the MVP is done. Companion build guide to Lesson 4.3 (Tools & Setup)." date: 2026-05-18 draft: false course_chapter: true @@ -23,193 +23,92 @@ metatags: image: cover.png og_title: "4.4 · 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 Weeks 4-10 for the build-phase plan." +cover_image_alt: "JetThoughts cover titled Self-Serve Build Phases, showing four connected phase cards - Phase 1 UI, Phase 2 Data, Phase 3 Pay, Phase 4 Deploy - with chips reading Weeks 4-12, Phases 4, Team Solo." canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/" related_posts: false --- > **Module 4 · Lesson 4.4 · [CORE]** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > -> **Companion pair: read [Chapter 4.3 · Tools & Setup](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) first** - it covers why these three tools, what each one does, the 12 rules, communities, and the AI critic block. +> **Companion pair: read [Lesson 4.3 · Tools & Setup](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) first** - it covers why these three tools, what each one does, the 3 pre-flight rules, and the AI critic block; the full 12 build rules and founder communities are in the [stack-and-tools reference](/course/tech-for-non-technical-founders-2026/reference/stack-tools-full/). The phases below reference those concepts without re-explaining them. > -> **Input:** the self-serve stack set up plus the pre-flight rules from [Chapter 4.3](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) + your one-page brief from Module 3 +> **Input:** the self-serve stack set up plus the pre-flight rules from [Lesson 4.3](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) + your one-page brief from Module 3 > > **Output:** a live MVP at a real URL that real users can click > -> **Progress:** M4 · 4 of 5 · Results so far: stack set up + pre-flight rules locked (4.3) - this page walks the 4 build phases to a live MVP +> **Progress:** M4 · 4 of 5 · Results so far: stack set up + pre-flight rules locked (4.3) - this lesson walks the 4 build phases to a live MVP > **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 pace is a full-time-founder pace only. - -> **This chapter assumes you read Chapter 4.3 first.** It 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 [Chapter 4.3: 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 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-2.4 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-2.4 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.6 vocabulary (the most useful paste in the course).** Before you describe a button label, a column header, or a screen title, open your Ch 2.6 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 (the default for a non-technical founder - this is copy-paste verification, not programming: the AI writes the fix, you paste it and read the answer).* 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-2.4 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/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 (roughly $10/year for a .com on [Porkbun](https://porkbun.com/) 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-2.4 interviews** has clicked through to the paywall on the live URL. -> 4. **Zero errors in the browser Console** on the sign-up + checkout flow. Not a coding step: press F12, click through sign-up and checkout like a user, and check that the Console tab shows no red lines. -> 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.** The onramp phase's 4-6 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-2.4 interviewee list, your community connections, or a fresh micro-batch of cold DMs. Aim for 10-30 active users by the time M5.1's survey ships - 5.1 treats 10 as directional-only and 20+ as a useful read. 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 +You validated the problem in Modules 1-3 and set up the stack in Lesson 4.3. What you do not have yet is a URL a stranger can pay on. This lesson is the build plan that gets you there - four phases, each ending in one working demo to one human who has not seen the build. -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-2.4 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. +After this lesson you will be able to: **run the four build phases in order, each ending in one demo to one person, until you have a live MVP at a real URL that real users can click.** -Open your Ch 2.3-2.4 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. +![Four build phases, then the five-green-lights gate. Phase 1 Lovable UI - screens click, nothing saved. Phase 2 Supabase and auth - a real signup persists. Phase 3 Stripe checkout - a $1 test charge flips the row to paid. Phase 4 go live - 5 ICP users click the live URL. All five exit lights green advances you to Module 5.](build-phases-strip.svg) -Send it as a [Loom](https://www.loom.com) (Loom is a 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. +## The ship plan -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. +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 - someone who has not seen the build). The build ends with five real ICP users on the staging URL; the onramp brings the rest of your Lesson 2.3-2.4 interview pool onto the product. -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. +1. **Phase 1 - Lovable, the UI.** No backend yet. *Demo:* screens click, no data persists. +2. **Phase 2 - Supabase + auth.** Real signup works. Enable [Row-Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security) (RLS - the database rule that walls one customer's data off from another's) from the first table. *Demo:* your spouse signs up, a row appears in Supabase in real time. +3. **Phase 3 - Stripe + checkout.** Build one product (your monthly plan) at one price - the price your [Lesson 1.5 smoke test](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/) validated, not a guess. Run $1 test transactions until the webhook (the automatic message Stripe sends your app when a payment lands) flips your row to paid. +4. **Phase 4 - staging URL + 5 ICP users.** Custom domain, Stripe live. Log 5 click sessions, then iterate from real signal. +5. **Onramp phase - Module 5 handoff.** Invite the 10 Lesson 2.3-2.4 interviewees by name. Hand off to Module 5 with a populated users table, not an empty one. -If you need more than 10 users on the MVP before running Ch 5.1's survey, the recruitment playbook in [Ch 2.3-2.4](/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." +The [full build guide](/course/tech-for-non-technical-founders-2026/reference/mvp-build-phases-full/) walks each phase step-by-step - the Lovable prompts, the first Supabase table, the RLS self-test, the Stripe test cards, and the domain switch. -## What "ship the shed" means in practice +> **Bridge from Lesson 2.6 vocabulary (the most useful paste in the course).** Before you describe a button label, a column header, or a screen title, open your Lesson 2.6 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. -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. +## The five green lights -| **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 | +The MVP is "done" only when ALL five lights are green. Without them, you either polish forever in Lovable or hand Module 5 an MVP real users cannot touch. -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. +1. **Stripe in LIVE mode** and a real card clears the paywall at least once. +2. **Custom domain wired** (not a `.lovable.app` subdomain) - the URL you send must be yours. +3. **At least 1 ICP user who was NOT in your Lesson 2.3-2.4 interviews** reached the paywall on the live URL. +4. **Zero red errors in the browser Console** on the sign-up + checkout flow (press F12, click through like a user, check the Console tab). +5. **A weekly demo recording exists** for the last week of build (a Loom or screen-record proving the cadence held to the end). -## The architectural ceiling - what's coming in Chapter 4.5 +Advance to Module 5 only when all five are green. If any are red, fix the red light first before you move on - a red gate hands Module 5 an MVP real users cannot touch. -The stack holds until it doesn't. Five specific signals tell you the ceiling is close. The next chapter ([Chapter 4.5 - Proactive Ceiling Signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/)) walks through each one with the threshold to watch. +## Ship the shed, not the skyscraper -Quick preview: scale beyond roughly 5,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.5 names the metrics. +Lovable + Supabase + Stripe is the shed: one workflow, one persona, one happy path, three integrations. It cannot host every business - but 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 [full build guide](/course/tech-for-non-technical-founders-2026/reference/mvp-build-phases-full/) has the in-the-envelope / out-of-the-envelope table and what the stack costs at each tier. -What the stack actually costs, per published vendor pricing: +## Module 5 handoff: invite your interviewees by name -| Phase | Cost shape | Line items | -|------|-------|-----------| -| Start | Free tiers | Free tiers across Lovable, Supabase, Stripe, GitHub | -| First ship | Per-tool monthly fees | Lovable + Supabase entry paid tiers + a .com domain (~$10/yr) + Resend entry tier + Stripe per-transaction fees | -| Post-launch | Scale-tier monthly fees | Lovable scale tier + Supabase paid tier + Resend/Sentry/monitoring paid tiers - check vendor pricing pages | +The 5 cold prospects from Phase 4 are the demand-signal check. The 10 people you ran through Lesson 2.3-2.4 are the warm pool that becomes your first real users - the ones who told you the problem was real, in their own words. They are not on your MVP yet, and they will not show up unless you invite them by name. -The architectural ceiling tends to land at the post-launch tier - at ~5K users, route to Chapter 4.5 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. +Open your Lesson 2.3-2.4 interview list. For each of the 10, write a 3-line personal note: the workaround they described, the staging URL of the workflow that now replaces it, and one question they answered that the MVP now responds to. Send it as a [Loom](https://www.loom.com) or a personal LinkedIn DM, not a generic email blast. Expect 4-6 to create accounts and 1-2 to become candidates for the [Lesson 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. This is the step that turns a working URL into a users table with rows in it. -## What to do tomorrow +## Do this now 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. +1. **Sign up for the Lovable + Supabase free tiers** on [lovable.dev](https://lovable.dev) and [supabase.com](https://supabase.com), then connect GitHub sync inside Lovable so your code survives a cancelled subscription. +2. **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 it as: "build a [screen] for [persona] to [outcome]." +3. **Generate the UI in Lovable and demo it.** Iterate by chatting: rename, resize, reposition. Then show one human who has not read the brief and watch them try it without a tour. -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. +> **Success check:** a clickable UI on a public staging URL, and one person navigated the core screen without you explaining it. Nothing needs to persist yet - that is Phase 2. -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. +**If this fails: the person you demoed to needed a tour to understand the screen.** +- **Why:** the design is carrying meaning that should be on the screen, so the prompt described a layout instead of a job. +- **Fix:** rewrite the Lovable prompt around the one job the screen does ("log this week's check-in"), regenerate, and demo again. If two testers stall on the first screen, the workflow shape is wrong - revisit [Lesson 3.2 outcomes](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/) before adding Stripe. -## When this path ends +Look at the one feature you picked. Could you cut it in half again and still solve the validated problem? The smaller the first ship, the more likely it actually ships. -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 ~$10 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 - -- [Chapter 4.3: 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/checkout/quickstart) and [Pricing page](https://stripe.com/pricing) -- Drew Falkman, "Vibe Coding Data-Enabled AI Apps" on Maven - -> **Done:** 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. +> **Done:** a live MVP at a real URL with all five green lights lit - Stripe in live mode, custom domain wired, 1 fresh ICP user tested the paywall, zero red Console errors on signup + checkout, and a weekly demo recording exists. +> +> **You have now:** the self-serve stack set up (4.3) + a live MVP at a real URL. Save the URL, the admin login, and the latest weekly demo recording in a `Live MVP` doc in your `Founder OS` folder, with every account in your own name (per [Lesson 4.2's Day-1 ownership audit](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/)). Module 5 invites your Module 2 interviewees and your [Lesson 1.4 smoke-test email list](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) to this URL as the warm seed for your first 10-30 users. Paying customers are the next test. > -> **You have now:** the self-serve stack set up (4.3) + a live MVP at a real URL. Save the URL, the admin login, and the latest weekly demo recording in a `Live MVP` doc in your `Founder OS` folder, with every account in your own name (per [Chapter 4.2's Day-1 ownership audit](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/)). Module 5 invites your Module 2 interviewees and your [Chapter 1.4 smoke-test email list](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) to this URL as the warm seed for your first 10-30 users. Paying customers are the next test. +> **Next:** [5.1 · Your First Customer Is Not a Marketing Problem](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/) - it runs the Sean Ellis 40% test on the users this MVP collects. Bookmark [4.5 · Ceiling Signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) as the optional monthly check to run once the stack starts to strain. > -> **Next:** [5.1 · Your First Customer Is Not a Marketing Problem](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/) - it runs the Sean Ellis 40% test on the users this MVP collects. Bookmark [4.5 · Ceiling Signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) as the optional monthly check to run when the stack starts to strain. +> **If blocked:** see "If this fails" above, or open the [full build guide](/course/tech-for-non-technical-founders-2026/reference/mvp-build-phases-full/) - it has the per-phase recovery steps and the free help channels from Lesson 4.3. > -> **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 test mode first. The communities section in Chapter 4.3 lists free help channels. +> **Deeper reference:** [The full 4-phase build guide - Lovable prompts, first Supabase table + RLS self-test, Stripe test flow, the 5-lights detail, the shed envelope, cost tiers, and the pre-Module-5 invite wave](/course/tech-for-non-technical-founders-2026/reference/mvp-build-phases-full/) --- 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 index ac28a9929..8f6cd0bb0 100644 --- 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 @@ -1,7 +1,7 @@ --- title: "4.3 · 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. Chapter 4.3 of the course; Chapter 4.4 walks the build." +description: "Why Lovable + Supabase + Stripe is the dominant self-serve path. Plain-English roles, the 3 pre-flight rules, and the AI leakage check. Lesson 4.3 of the course; Lesson 4.4 walks the build." date: 2026-05-18 draft: false course_chapter: true @@ -24,7 +24,7 @@ cover_image: cover.png metatags: image: cover.png og_title: "4.3 · 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. Chapter 4.3 of the course; Chapter 4.4 walks the build." + og_description: "Why Lovable + Supabase + Stripe is the dominant self-serve path. Plain-English roles, the 3 pre-flight rules, and the AI leakage check. Lesson 4.3 of the course; Lesson 4.4 walks the build." 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 Weeks 4-10 for the build-phase plan." canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/" related_posts: false @@ -32,178 +32,83 @@ related_posts: false > **Module 4 · Lesson 4.3 · [CORE]** · [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 quality-checked one-page brief (from [Ch 3.2](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/)) + a Day-1 ownership audit passed (from [Ch 4.2](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/)) +> **Input:** a "self-serve" build-path decision (from [Lesson 4.1](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/)) + a quality-checked one-page brief (from [Lesson 3.2](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/)) + a passed Day-1 ownership audit (from [Lesson 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 [Chapter 4.4 · Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/) +> **Output:** the 3 pre-flight rules locked in and tool boundaries clear, ready to start the build in [Lesson 4.4 · Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/) > -> **Progress:** M4 · 3 of 5 · Results so far: build path = self-serve (4.1) + ownership locked (4.2) - this page sets up the stack and the pre-flight rules +> **Progress:** M4 · 3 of 5 · Results so far: build path = self-serve (4.1) + ownership locked (4.2) - this lesson sets up the stack and the pre-flight rules -> **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. +> **TL;DR:** Lovable renders the screens, Supabase stores the data, Stripe charges the card. Three tools, three jobs. Lock 3 pre-flight rules before you open Lovable. All three tools have free tiers. -> **Jump to:** [What each tool does](#what-each-tool-does-in-plain-english) · [12 rules checklist](#12-rules-for-a-self-built-mvp-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) - -If you completed Modules 1-3, 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. | Free tier + paid tiers | -| Data | Supabase | Store the user, the row, the file. Listen for Stripe events. | Free tier + paid tiers | -| Money | Stripe | Charge the card. Tell Supabase the customer is paid. | Per-transaction card fee (see Stripe pricing) | - -The buyer opens the staging URL (the live web address where your work-in-progress app is visible) → Lovable shows the screens → Supabase stores the data → Stripe charges the card → a Stripe webhook (an automatic status message Stripe sends your app) 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. - -How much demand evidence you already have decides the path. With enough of it, you open Lovable and build. Without it, a $0 Concierge MVP - a no-code "Wizard of Oz" where you fake the automation by hand behind the curtain - gets you more evidence before you commit to Lovable code. Wire up 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, and you process it by hand. To the customer it looks automated, so you validate willingness-to-pay before writing code. The trade-off is that you run it by hand, which makes it a stepping stone, not a replacement. Either way, the Lovable + Supabase + Stripe stack is what ships in Chapter 4.4. +--- -## M2 prototype vs M4 MVP - different artifacts, different rigor +Three tools do the whole self-serve build, and each one has exactly one job. The trap is opening Lovable before you know where its job ends and Supabase's begins - that is how a founder ends up with auth hand-rolled in the UI layer and payment state scattered across three places. Get the boundaries and three pre-flight rules right first, and the build in Lesson 4.4 stays inside the shed. -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. +After this lesson you will be able to: **name what each of the three tools does, lock the 3 pre-flight rules, and run the AI leakage check that catches scope creep before you write a line of the build.** -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. +If you completed Modules 1-3, your default Module 4 path is to build it yourself with Lovable (an AI app builder that turns a plain-English prompt into a working web app) + Supabase (managed database + login system) + Stripe (the service that charges the card). 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. -Side-by-side: the Module 2 throwaway prototype vs the Module 4 production MVP. +## Three tools, three jobs -| | M2 prototype | M4 MVP | +| Tool | Job | Cost | |---|---|---| -| 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) - -It is tempting to ask "which framework" before you ask "which job." Three tools, three jobs. The boundaries between them are the only architecture you need to know on day one. +| **Lovable** (UI) | Render the screens. Send form data down. | Free tier + paid tiers | +| **Supabase** (data + auth) | Store the user, the row, the file. Hold the login. Listen for Stripe events. | Free tier + paid tiers | +| **Stripe** (money) | Charge the card. Tell Supabase the customer is paid. | Per-transaction card fee | -### 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](https://lovable.dev/pricing) runs from a capped free tier through paid tiers sized by build velocity - check the pricing page for current numbers. Expect to move to a mid or scale tier after the first month once build velocity picks up. - -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. +The buyer opens the staging URL (the live web address where your work-in-progress app is visible) → Lovable shows the screens → Supabase stores the data → Stripe charges the card → a Stripe webhook (an automatic status message Stripe sends your app) tells Supabase the row is now paid. -### Supabase - the data layer +![Three tools, three boundaries. Lovable owns the UI - it renders the screens and sends the form data down. Supabase owns the data and auth - it stores the users, rows, and files and holds the login. Stripe owns the money - it charges the card and confirms who paid. Data flows left to right from Lovable to Supabase to Stripe, and a Stripe webhook loops back to Supabase to tell it the customer is paid.](stack-boundaries.svg) -Supabase is managed Postgres (a widely used database) + auth (the login and signup system) + file storage + row-level security (rules that keep each user's rows private to them) 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. +These three became the dominant self-serve path because all three 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: it 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 [full stack-and-tools reference](/course/tech-for-non-technical-founders-2026/reference/stack-tools-full/) has the plain-English deep dive on each tool, the M2-prototype-vs-M4-MVP contrast, all 12 build rules, and the founder communities that replace a co-founder. -The free tier comfortably covers early-stage usage - [check Supabase's pricing page](https://supabase.com/pricing) for current limits. Early-stage usage rarely outgrows the first paid tier before you hit the architectural ceiling. +## The 3 pre-flight rules - true before you open Lovable -Supabase auto-generates a REST API (a standard way for one program to request data from another) 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 most 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. +Twelve rules keep a self-built MVP inside the shed, but only three must be true on day zero. Get these three right and the other nine read as inline checks while you build. Get them wrong and the other nine cannot save the project. -### Stripe - the money layer +1. **Start from a one-page brief that passed the Lesson 3.2 quality-gate.** If Section 3 is feature-shaped, fix it before you open Lovable - feature-shaped briefs produce sprawling 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. **Set up GitHub sync in Lovable Settings on day 1.** GitHub (the online folder that stores your code) is your backup if Lovable drops the work. Skipping this is the top reason founders cannot retrieve their source six months later. -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. +Before you trust the build, have AI check it against the brief you locked in Lesson 3.2. Paste your brief's Section 3 (the outcome-shaped feature list) into [Claude](https://claude.ai), then paste this prompt - the same leakage check you ran in Lesson 3.2, now aimed at what Lovable is about to generate: -The fee is the standard [per-transaction card processing rate](https://stripe.com/pricing) for cards in the US (a small percentage plus a flat per-charge amount); 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 the exact same setup. +```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. +``` -### GitHub for version control +The three features it names are your scope-leak watchlist. Cut them from the Lovable prompt before you build, not after. (The deeper build-time audits - the Supabase row-level-security check and the screenshot happy-path walk - live in the [stack-and-tools reference](/course/tech-for-non-technical-founders-2026/reference/stack-tools-full/#have-ai-review-the-build); run them once the build exists.) AI can flag scope leak against your brief, but it cannot prove real users can navigate the workflow or that the architecture holds at scale - only uncoached users and real traffic do that. -Free for solo founders on the Free plan. You will not write much code yourself, but Lovable can sync to a GitHub repo (short for repository - the online folder that stores your code) 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 a founder cannot retrieve the source six months later. +--- -> **Have AI review the build before real users touch it.** -> -> **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. +> **Set up:** > -> 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.5 ceiling signals can) -> -> **The real gate:** 5 green lights (Phase 4 exit criteria in [Chapter 4.4](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/)) + weekly demo to one non-PRD-reader human. +> 1. Open your one-page brief from Lesson 3.2. Confirm Section 3 reads as outcomes, not features (pre-flight rule 1). +> 2. Write one sentence naming your single workflow, single persona, and single happy path (pre-flight rule 2). If you cannot fit it in one sentence, the scope is too big - cut until you can. +> 3. Paste Section 3 into [Claude](https://claude.ai) with the leakage-check prompt above. Save the 3 flagged features as your "do not build yet" list. +> 4. Sign into [Lovable](https://lovable.dev), open Settings, and turn on GitHub sync (pre-flight rule 3). +> 5. **Success check:** you can name what each tool does, your one-sentence scope is written down, GitHub sync is on, and you have a 3-item scope-leak watchlist from Claude. -## 12 rules for a self-built MVP 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 [Chapter 4.4](/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. +**If this fails: the 12-rules list feels like homework and you still haven't opened Lovable.** +- **Why:** the full rule set reads as a prerequisite checklist, but only rules 1, 2, and 6 (the three pre-flight rules above) must be true before you start - the rest fire inline during the build. +- **Fix:** ignore the other nine for now. Lock the 3 pre-flight rules, paste your brief's Section 3 into Lovable, and ship one screen tonight. The inline rules become reminders as you hit them in Lesson 4.4. -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 sprawling 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. +Can you say your whole build in one sentence - one workflow, one persona, one happy path? If it takes two sentences, you are describing the house, not the shed, and Lovable will build exactly what you describe. -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 sprawling 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.6 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 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.5 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 a paid tier 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.5 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.5 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" | Peer cohort + office hours; best when a deadline is what makes you ship | Paid - check the course page | - -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 - -- [Chapter 4.4: 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/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/) - -> **Stuck 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. - -> **Done:** 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). +--- + +> **Done:** you can name what each of the three tools does, the 3 pre-flight rules are locked (brief quality-gate passed, one workflow scoped, GitHub sync on), and you have a scope-leak watchlist from Claude. > > **You have now:** a validated problem statement (2.5) + a quality-checked one-page brief (3.2) + a self-serve build decision (4.1) + a passed Day-1 ownership audit (4.2) + the three-tool stack mapped and the 3 pre-flight rules locked (4.3). The build itself is the next test. > > **Next:** [4.4 · The Self-Serve MVP Stack: Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/) - takes the 3 pre-flight rules and the stack you just mapped into the Phase 1-4 build. > -> **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. +> **If blocked:** see "If this fails" above. +> +> **Deeper reference:** [Each tool in depth, the M2-vs-M4 contrast, all 12 rules, and the founder communities](/course/tech-for-non-technical-founders-2026/reference/stack-tools-full/) --- diff --git a/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/stack-boundaries.svg b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/stack-boundaries.svg new file mode 100644 index 000000000..224460adb --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/stack-boundaries.svg @@ -0,0 +1,72 @@ + + Three tools, three boundaries. Lovable owns the UI: it renders the screens and sends form data down. Supabase owns the data and auth: it stores the users, rows and files and holds the login. Stripe owns the money: it charges the card and confirms who paid. Data flows left to right from Lovable to Supabase to Stripe, and a Stripe webhook loops back to Supabase to tell it the customer is paid. + Three cards in a row. Left card Lovable, the UI layer, renders the screens and sends form data down. Middle card Supabase, the data and auth layer, stores users, rows and files and holds the login. Right card Stripe, drawn in green as the money layer, charges the card and confirms who paid. Arrows run left to right between the cards, and a dashed webhook arrow loops back from Stripe to Supabase captioned tells Supabase the customer is paid. + + + + + + + + + + + Three tools, three boundaries + The buyer opens the staging URL - then each tool owns one job and nothing else. + + + + + Lovable + the UI layer + + Renders the screens + Sends the form data down + + + + + + Supabase + the data + auth layer + + Stores the users, rows, files + Holds the login + + + + + + Stripe + the money layer + + Charges the card + Confirms who paid + + + + data + + pay + + + + + Stripe webhook: tells Supabase the customer is paid. + 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 index e2eee42f6..1a63c0a88 100644 Binary files a/content/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/cover.png 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 index 420798d3d..5dd4c8d00 100644 --- 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 @@ -21,16 +21,17 @@ tags: - self-serve - vibe-coding categories: ["Templates"] +cover_image_alt: "JetThoughts cover titled Self-Serve Stack Walkthrough, showing four cards - Lovable, Supabase, Stripe, Go live - each marked 5 sessions, with chips reading Pace Evenings OK, Sessions 20, Team Solo." canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/" related_posts: false --- -📋 Template companion to [Chapter 4.3 · The Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) and [4.4 · Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/). Print it, pin it by your monitor, and work one session at a time. - -# Self-Serve Stack Walkthrough - 4 Phases, 3 Tools, 1 Staging URL +Template companion to [Lesson 4.3 · The Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) and [4.4 · Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/). Print it, pin it by your monitor, and work one session at a time. *Session-by-session tasks for shipping the Lovable + Supabase + Stripe MVP. Cross off as you go.* +![The walkthrough, phase by phase. Phase 1 Lovable UI, 5 sessions, demo a clickable staging URL. Phase 2 Supabase and auth, 5 sessions, demo the first real signup. Phase 3 Stripe checkout, 5 sessions, demo a $1 paid flow that clears. Phase 4 go live, 5 sessions, demo 5 ICP users clicking. Twenty build sessions of about 90 minutes each - roughly 10 weeks evenings-only or 4 weeks full-time, the same 20 sessions either way.](walkthrough-milestones.svg) + **The 4-phase roadmap:** 1. **Phase 1 - Lovable + the UI** (no backend yet). Demo: clickable staging URL. @@ -63,17 +64,20 @@ If a session runs long, or a phase takes you a couple of extra weeks, you are no ## Pre-flight checklist (before Phase 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 around Phase 2) -- [ ] **One Supabase project created** (Free tier OK through Phase 4) -- [ ] **One Stripe account created** in test mode (verify the email) -- [ ] **One GitHub account** (Free plan is fine for solo founder) -- [ ] **Recurring calendar blocks** scheduled: your build sessions, ~90 minutes each (two a week if you build evenings only, more if you are full-time) -- [ ] **Demo audience chosen** for each phase (spouse, advisor, peer founder, ICP prospect - rotate) - -If any pre-flight box is unchecked, do that first. The plan does not work without the inputs. +
    +

    Every box below must be checked before Phase 1. If any is unchecked, do that first - the plan does not work without the inputs.

    +
      +
    • One-page brief finalized (template)
      • +
    • Validated Problem Statement filled in (template)
      • +
    • Build Path Decision Worksheet verdict = Path 2 (Self-serve)
      • +
    • One Lovable account created (Free tier OK to start; upgrade to a paid plan - check Lovable's pricing page - around Phase 2)
      • +
    • One Supabase project created (Free tier OK through Phase 4)
      • +
    • One Stripe account created in test mode (verify the email)
      • +
    • One GitHub account (Free plan is fine for a solo founder)
      • +
    • Recurring calendar blocks scheduled: your build sessions, ~90 minutes each (two a week evenings-only, more if you are full-time)
      • +
    • Demo audience chosen for each phase (spouse, advisor, peer founder, ICP prospect - rotate)
      • +
    +
    ## Phase 1 - Lovable + the UI (no backend yet) @@ -122,7 +126,7 @@ Send the staging URL to someone who has not read the one-page brief. Watch them **Result line (fill in)**: ____________________________________________ -> **Phase 1 outcome**: a clickable UI on a public staging URL, GitHub-synced, that a non-PRD reader can navigate without a tour. +> **Good** - Phase 1 done: a clickable UI on a public staging URL, GitHub-synced, that a non-PRD reader can navigate without a tour. ## Phase 2 - Supabase + auth (real signup works) @@ -200,7 +204,7 @@ Send the staging URL to your spouse (or one ICP peer). Ask them to sign up with **Result line (fill in)**: ____________________________________________ -> **Phase 2 outcome**: a real signup persists across refresh, RLS is on, and the first row appears in the Supabase console live during the phase demo. +> **Good** - Phase 2 done: a real signup persists across refresh, RLS is on, and the first row appears in the Supabase console live during the phase demo. ## Phase 3 - Stripe + checkout ($1 test transactions) @@ -249,7 +253,7 @@ Walk through the full flow in test mode: signup -> dashboard -> add a client -> **Result line (fill in)**: ____________________________________________ -> **Phase 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. +> **Good** - Phase 3 done: a paid signup flow end-to-end in test mode, webhook verified, `subscription_status` flips from `trial` to `active` within a minute or two of a $1 charge (Stripe webhooks are asynchronous - delivery can lag or retry). ## When the webhook doesn't fire (troubleshooting in 5 minutes) @@ -308,7 +312,7 @@ The data picks the next week. Do not iterate on what you imagine; iterate on wha **Result line (fill in)**: ____________________________________________ -> **Phase 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 the data review. +> **Good** - Phase 4 done: a live domain pointing at the staging URL, 5 ICP prospects sent the link, and real signup/click/pay metrics on the table for the data review. ## Sample Lovable prompts (verbatim, copy-paste) @@ -390,9 +394,9 @@ The bad pattern ships an MVP where any user with the right URL pattern can fake - **If 1+ paid signups**: continue. The hypothesis is alive. Build the second feature next, 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 next: 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.5), 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. +- **Watch for the architectural ceiling**: when two of the [5 ceiling signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) keep firing for 4+ weeks (covered in detail in Lesson 4.5), plan the 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; finish the build phase you are in, then plan the route rather than panicking mid-ship. -If you want the doctrine in long form, [Chapter 4.3](/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. +If you want the doctrine in long form, [Lesson 4.3](/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 diff --git a/content/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/walkthrough-milestones.svg b/content/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/walkthrough-milestones.svg new file mode 100644 index 000000000..f66b916b5 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/self-serve-stack-walkthrough/walkthrough-milestones.svg @@ -0,0 +1,66 @@ + + The walkthrough phase by phase. Phase 1 Lovable UI, five sessions, demo a clickable staging URL. Phase 2 Supabase, five sessions, demo the first real signup. Phase 3 Stripe, five sessions, demo a one-dollar paid flow. Phase 4 go live, five sessions, demo five ICP users clicking. Twenty build sessions of about ninety minutes each - roughly ten weeks evenings-only or four weeks full-time. + Four milestone cards on a timeline - Phase 1 Lovable UI, Phase 2 Supabase, Phase 3 Stripe, Phase 4 go live - each carrying a five-sessions chip and its demo checkpoint, joined by arrows. A note underneath reads roughly ten weeks evenings-only or four weeks full-time, the same twenty sessions either way. + + + + + + + + The walkthrough, phase by phase + 20 build sessions (~90 min each) - one demo closes each phase. + + + + + Phase 1 + + 5 sessions + Lovable UI + ✓ clickable staging URL + + + + Phase 2 + + 5 sessions + Supabase + auth + ✓ first real signup + + + + Phase 3 + + 5 sessions + Stripe checkout + ✓ $1 paid flow clears + + + + Phase 4 + + 5 sessions + Go live + ✓ 5 ICP users click + + + + + + + + ~10 weeks evenings-only - ~4 weeks full-time - the same 20 sessions either way. + 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 deleted file mode 100644 index a6d6eb327..000000000 --- a/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/decision-matrix.svg +++ /dev/null @@ -1,66 +0,0 @@ - - - - - - - - - - - - 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 (Ch 4.3-4.4) - When: validated. Simple MVP. - 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 (hire track) - 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 index be4322d84..265029ac9 100644 --- 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 @@ -1,7 +1,7 @@ --- 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." +description: "5 questions route you to one of 4 build paths: validate without code, self-serve, fractional CTO, or hire a team. Lesson 4.1 of the course." date: 2026-05-13 draft: false course_chapter: true @@ -22,7 +22,7 @@ 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." + og_description: "5 questions route you to one of 4 build paths: validate without code, self-serve, fractional CTO, or hire a team. Lesson 4.1 of the course." cover_image_alt: "JetThoughts cover showing a decision node branching into the four build paths: Validate, Self-serve, Fractional CTO, and Hire a team" canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/" related_posts: false @@ -30,91 +30,30 @@ related_posts: false > **Module 4 · Lesson 4.1 · [CORE]** · [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) +> **Input:** a quality-checked one-page brief (from [Lesson 3.2](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/)) > -> **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/) +> **Output:** a 4-way build-path decision (validate / self-serve / fractional-CTO / hire) written at the top of the [Build Path Decision Worksheet](/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/) > -> **Progress:** M4 · 1 of 5 · Results so far: a quality-checked one-page brief (3.2) - this page decides who builds from it +> **Progress:** M4 · 1 of 5 · Results so far: a quality-checked one-page brief (3.2) - this lesson decides who builds from it > **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 (an AI app builder that turns a plain-English prompt into a working web app), Supabase (the database that stores what the app records), and Stripe (the service that takes the payments) 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-2.4 recruitment + interview round) proved the problem is real and felt. The clickable prototype shape test (Chapter 2.6) 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 simple hand-built 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 the 30 people 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 30 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 30 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 30 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 30 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-synthesis-build-pivot-kill/)) 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 30 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 30 ICP prospects (ICP = Ideal Customer Profile - the specific kind of person your hypothesis names as the buyer) 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.5 synthesis rubric + a Ch 1.4 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) (free trial available), ship the smallest end-to-end thing it generates, and connect [Supabase](https://supabase.com) (free tier) + Stripe + Resend (the service that sends your app's emails) 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)) +Hiring engineers before a single paying customer is confirmed is the most common build-decision mistake at the idea stage. The hire is the move that breaks the runway; the step it skips is the cheaper experiment that would have told you whether you need to build at all. Five questions route you to the smallest path that answers your next question. -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. +After this lesson you will be able to: **decide which of four build paths fits your evidence and runway - validate without code, self-serve, fractional CTO, or hire a team - and write the verdict at the top of your worksheet.** -### 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)) +Self-serve with Lovable (an AI app builder that turns a plain-English prompt into a working web app), Supabase (the database that stores what the app records), and Stripe (the service that takes the payments) 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. -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 (statement of work - the document listing exactly what the dev shop will build) [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. +By the time you reach this lesson you have already run three validation signals: the [Lesson 1.4 smoke test](/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/) proved strangers click, the [Lesson 2.4 Mom Test interviews](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) (using the [Lesson 2.1 technique](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/)) proved the problem is real and felt, and the [Lesson 2.6 prototype](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/) proved users can navigate the solution without coaching. The [Lesson 3.1 brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) documents what to build. This lesson decides HOW. ## 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. +Answer these five alone, on a printed worksheet, and the matrix picks your path. The diagram is the worksheet - the questions live inside it. ```mermaid -%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%% +%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, Comic Sans MS, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%% flowchart TD Start(["Default: self-serve.
    Five questions test it."]) Start --> Q1["Q1: Problem validated?
    10+ calls, 7+ signals, smoke test 6%+"] @@ -144,62 +83,56 @@ flowchart TD 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 you read next: +**Q1 ("problem validated?")** counts as yes only if you have 10+ Mom Test interviews with strong past-behavior signal in at least 7, a smoke test that cleared the 6%+ "Promising" band, and a Lesson 2.6 prototype run where 4 of 5 testers reached the right screen without coaching. LinkedIn likes don't count; "they said they would buy" doesn't count. Pre-orders and paid pilots come later in Module 5 - do not require them as this gate. -| 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 [the Module 1 smoke test (Lessons 1.2-1.5)](/course/tech-for-non-technical-founders-2026/smoke-test-build-page/) or [Ch 2.3 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.3 · Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) + [4.4 · 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 | +**Q2 ("backend-heavy?")** means: does the app need users to see each other typing in real time (Google Docs / Slack behavior), or does it touch healthcare data, stored card numbers, or SOC 2 audits? If neither, the answer is almost certainly no - dashboards, forms, and single-user tools are not heavy. -**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 Ch 2.6 prototype run with 4 of 5 testers reaching the right screen. +**Q3 ("runway?")** is months of cash until you must show paying customers. Under 4 months routes to Validate regardless of Q1. 4-12 months keeps self-serve and fractional on the table; 12+ makes a team safe to consider. -**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. +**Q5 ("engineering budget?")**: the Fractional CTO band is an $80-$120/hour market rate (per Bolster and Toptal marketplace data), which lands around $400-$600/week for 5 hours; a full team is material monthly burn before revenue. Skip the path you cannot fund through the runway window. -**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. +## The 4 paths and what each one means -**Q5 ("engineering budget?")**: fractional rate fits the Fractional CTO route (an $80-$120/hour market band for a competent Fractional CTO, per Bolster and Toptal marketplace data, which lands around $400-$600/week for 5 hours); full team salaries fit the Hire route. Skip the path you cannot fund through the runway window. +| Path | Route (from the diagram) | Cost shape · what it means | +|---|---|---| +| **1. Validate without code** | Q1 = No, or Q3 tight | Per-vendor pricing (Carrd, Stripe, Notion) + optional ad spend. The Module 1-3 evidence chain isn't done yet - run the Airbnb test before you spend real runway. | +| **2. Self-serve build** | Q2 = No, Q4 = Yes | Per-tool monthly pricing (Lovable + Supabase + Stripe). Default for non-technical founders; a senior engineer in your network is the cheap monthly insurance. | +| **3. Fractional CTO bridge** | Q4 = No, Q5 = fractional | Fractional hourly rate, $0 equity. Same self-serve build, but the architecture review is bought commercially instead of borrowed from your network. | +| **4. Hire a team** | Q2 = Yes, or Q5 = full team | Material monthly burn before revenue. Backend-heavy or a 12+ month runway. Read the SOW (statement of work - the document listing exactly what a dev shop will build) first. | -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 Airbnb test is the cheapest way to answer Q1 when you are unsure. Brian Chesky and Joe Gebbia posted three nights on a hand-built page and waited for three strangers to pay before writing code. The 2026 version takes one afternoon: a Carrd page with a Stripe checkout, a Notion FAQ, and the link sent to your [Lesson 2.3 30-name list](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/). Two paying buyers from 30 is enough to flip the build switch. Zero clicks is data too - find that out for $200 instead of $30,000. The [full hire-decision reference](/course/tech-for-non-technical-founders-2026/reference/hire-decision-full/) walks the Airbnb test, each path in depth, and the Series-A off-ramp. -### 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. +> **Decide:** > -> 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 +> 1. Print the [Build Path Decision Worksheet](/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/) (one side of paper). Bring your [one-page brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) and [Validated Problem Statement](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/). +> 2. Answer the five questions alone, pen on paper: interviews, runway months, backend weight, monthly budget, senior engineer available. No negotiating with yourself. +> 3. Read the path the matrix lands on and write it at the top of your `Founder OS` doc. +> 4. Take the verdict to one peer or advisor for a 20-minute sanity check - not three. +> 5. **Success check:** your build path is written in one line at the top of the worksheet, and you can name the one route that made the matrix pick it. -| 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. +**If this fails: the matrix routes you to "hire a team" but your runway is under 4 months.** +- **Why:** a heavy backend (Q2 = Yes) points at hiring, but under-4-month runway (Q3) cannot fund a team before revenue lands - the two answers collide. +- **Fix:** runway wins. Default to self-serve (Lessons 4.3-4.4), ship the smallest version of the validated core, and revisit hiring when a ceiling signal fires in [Lesson 4.5](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/). -Two refundable deposits beat 200 LinkedIn likes. +--- -## Further reading +Which of the five answers are you least sure of? That one is where your build decision is actually being made - go get the number before you commit the money. -- 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 - the paid live 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:** You have answered the 5 questions on the worksheet and your build path is written at the top. +> **Done:** you answered the 5 questions on the worksheet and your build path is written at the top. +> +> **You have now:** a quality-checked one-page brief (3.2) + a build-path decision - validate / self-serve / fractional CTO / hire - saved in your `Founder OS` folder. The default is self-serve; the build itself is the next test. > -> **You have now:** a quality-checked one-page brief (3.2) + a build-path decision (validate / self-serve / fractional CTO / hire), saved in your `Founder OS` folder. +> **Next:** [4.2 · Who Owns Your GitHub, AWS, and Database?](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/) - locks ownership of the accounts before anything gets built on the path you just chose. > -> **Next:** [4.2 · Who Owns Your GitHub, AWS, and Database?](/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/) - lock ownership before anything gets built on the path you just chose. +> **If blocked:** see "If this fails" above. > -> **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-4.4) and revisit hiring when a ceiling signal fires in Ch 4.5. +> **Deeper reference:** [The Airbnb test, all four paths in depth, and the Series-A off-ramp](/course/tech-for-non-technical-founders-2026/reference/hire-decision-full/) --- 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 index a3d7b02ab..de43a31ce 100644 --- 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 @@ -1,5 +1,5 @@ - + 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 index f7d87527a..f50f7d0de 100644 --- 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 @@ -1,5 +1,5 @@ - + 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 index d025f73dd..d5ccfa454 100644 --- 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 @@ -25,7 +25,7 @@ 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'." +cover_image_alt: "JetThoughts cover for Slopsquatting: Supply-Chain Attack on Vibe Coding - a red npm-install card with a fake package suggested by AI, and chips reading 200+ hallucinated packages, $34K MVP cost, CI safelist gate." canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/slopsquatting-ai-supply-chain-attack/" related_posts: false course_nav: false @@ -40,13 +40,15 @@ course_nav: false **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. You 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. +In March 2025, [Lasso Security published findings](https://www.lasso.security/blog/ai-package-hallucinations) 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. You 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 slopsquatting write-up](https://snyk.io/articles/slopsquatting-mitigation-strategies/) cites follow-up research putting the overall rate at roughly one in five AI-suggested packages across models. 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 - just a developer who trusts a model without checking. +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 slopsquatting write-up](https://snyk.io/articles/slopsquatting-mitigation-strategies/) cites follow-up research putting the overall rate at roughly one in five AI-suggested packages across models. 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 (a secret, unpatched vulnerability) - just a developer who trusts a model without checking. + +![A hand-drawn comparison table across three stacks - Rails/Ruby, Django/Python, and Laravel/npm. Each row shows the plausible-sounding package name an AI model hallucinated (active_support_extras_helper, requestz, react-toastify-fork) next to the real package it was confused with (active_record_extra, requests, react-toastify). All three hallucinated names were registered by Lasso researchers as proof-of-concept in April 2025.](hallucinated-vs-real.svg) ## The 20-line CI gate (the simplest defense) @@ -84,7 +86,7 @@ That is the entire defense. The PR cannot merge until a human looks at the new g ```mermaid -%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#1a1a1a', 'primaryTextColor':'#1a1a1a'}}}%% +%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, Comic Sans MS, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#1a1a1a', 'primaryTextColor':'#1a1a1a'}}}%% flowchart TD @@ -124,7 +126,7 @@ That is it. No Snyk subscription, no Socket.dev license, no signing key infrastr ## 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. +One paragraph. Send it as an SOW (statement of work) addendum to your existing dev shop, or paste it into the next agency MSA (master service agreement) 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. 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 index 2a5a6ff83..d7f14e0d4 100644 --- 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 @@ -53,34 +53,99 @@ The page has four copy blocks that decide whether it converts: ![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) +## Step 1: get 2-3 real customer quotes (10 minutes) + +The builder prompt in Step 2 has three slots for your customers' own words - they become your value props, and they are what makes the page sound like your customer instead of like marketing. Most first-timers don't have quotes yet, and that's expected: run this in [Perplexity](https://www.perplexity.ai/) (or any AI search engine) and keep the best 2-3 lines - and keep the source URLs too, because Lesson 2.3 reads these same threads to find the named people you'll interview. Already have real quotes from conversations? Skip straight to Step 2. Already ran the deeper research pass in the [full hypothesis sprint](/course/tech-for-non-technical-founders-2026/reference/hypothesis-sprint-full/)? Reuse those quotes here - don't search twice. + +```text +Find real, verbatim complaints from [CUSTOMER] about [PROBLEM]. +Search Reddit, G2, Trustpilot, and niche forums. For each result, give me: +- the exact quote, in the person's own words +- a link to the source + +Return 5-8 quotes. Prefer recent posts and specific frustration over +general opinions. +``` + +(These same quotes get reused later: your `[problem]` blank in 1.1 if it's still vague, and Module 2's people-hunting starts from the threads this search finds.) + +## Step 2: the prompt to paste + +Most builders ask you to "describe your idea" and then guess the rest of the page. Don't make them guess. Paste the prompt below instead - it hands the builder your hypothesis, the four blocks above, and the quotes from Step 1, so the first draft comes back close. The same prompt works in Mixo, Carrd, or any AI builder. Fill the `[...]` slots from your Lesson 1.1 Founding Hypothesis; leave the last two lines exactly as written (they're the parts AI builders skip on their own). + +```text +Build a landing page for a product that isn't built yet. Use exactly these +blocks, in this order: +- Hero headline: names the customer and the outcome in one line +- Sub-headline: one line explaining how it works (the mechanism) +- 3-4 value props: what the visitor gets, in their own words, max 6 words each +- Call-to-action button, labeled: Get on the waitlist +- Footer line: Coming soon. Email reserves your spot at launch. + +Here is the product: +Founding Hypothesis: [PASTE YOUR 1.1 SENTENCE] +Who it's for: [CUSTOMER blank] +The problem they have: [PROBLEM blank] +What they use today instead: [COMPETITION blank] +Why they'd switch: [DIFFERENTIATION blank] + +Real customer wording to echo in the value props (keep their words, compress +each to fit the six-word cap - quotes from Step 1): +- "[verbatim customer quote 1]" +- "[verbatim customer quote 2]" +- "[verbatim customer quote 3]" + +Before you write, do a quick web search for how [CUSTOMER] describe [PROBLEM] +in their own words, and match their vocabulary. Do NOT invent customer quotes: +if you can't find real phrasing for a value prop, write it plainly and mark +it [NEEDS REAL WORDING] so I can replace it. + +The page must pass this test: a stranger can say who it is for and what it does +in 3 seconds. No pricing, no FAQ, no testimonials. Never write "Buy now." +``` + ## Build the page > **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. +> 1. Sign up at [mixo.io](https://www.mixo.io/) (email only). Paste the Step 2 prompt, click **Generate**. ~60 seconds. +> 2. Tighten the 4 copy blocks against the draft: +> - Headline names customer + outcome. +> - Value props rewrite as outcomes ("Stop calling 8 centers," not "Calendar integration"). +> - CTA reads "Get on the waitlist." +> - Footer says "Coming soon. Email reserves your spot at launch." (AI builders skip this.) +> - Strip any Pricing, FAQ, or Testimonials blocks the builder added. +> - 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: *"Photorealistic image: [pain scenario in one sentence]. Candid, natural lighting, no text or logos."* +> - No image generator? 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. +> 5. **Know where your signups land.** Find your builder's signup list (Mixo: Subscribers tab) - every email the waitlist collects lives there. Don't export anything yet; just confirm you can see the list. Module 2 interviews and Module 5's first customers both start from these names. ## Test it on one stranger 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 short screen recording of your page with [Loom](https://www.loom.com/) (a free screen-recording tool) and send it to someone tomorrow with the same 3-second question. 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. +> **Good** - **Success check:** they can name both. If they cannot, the headline is almost always the fix - rewrite it and retest. ## If strangers can't name it -**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: strangers cannot name who the page is for or what it does, even after 2 headline rewrites.** -**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. +- **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: 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: +**If this fails: the builder's draft reads generic after 2 regenerations.** -```text -Translate this hypothesis into these landing-page elements -(headline, sub-headline, 3 value props, CTA copy, footer disclaimer): -[PASTE HYPOTHESIS] -``` +- **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. The Step 2 builder prompt works in Carrd's AI assistant too - paste it there instead of writing from scratch. --- 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 index 0248b2ec6..b5f1a92c3 100644 --- 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 @@ -2,11 +2,11 @@ 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 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 deleted file mode 100644 index 64e223393..000000000 --- a/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/channel-icp-matrix.svg +++ /dev/null @@ -1,58 +0,0 @@ - - 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/index.md b/content/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/index.md index cd50a3872..6b7a1477e 100644 --- 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 @@ -37,7 +37,7 @@ After this lesson you will be able to: **make a go / iterate / kill decision on ## Pick your channel -Choose based on who your hypothesis names in the [customer] blank. The dollar ranges below are **CPC** (cost-per-click - what one ad click costs you): +Choose based on who your hypothesis names in the `[customer]` blank. The dollar ranges below are **CPC** (cost-per-click - what one ad click costs you): - **Selling to individual people** → [Meta Ads](https://business.facebook.com/) ($0.70-$1.90 CPC). Best when the product is visual and the audience is broad. - **Selling to businesses, by job title** → [Google Search](https://ads.google.com/) ($3-$8 CPC) if your customer Googles the problem; [LinkedIn](https://www.linkedin.com/campaignmanager/) ($5.70-$22 CPC) if they don't. @@ -50,17 +50,19 @@ Choose based on who your hypothesis names in the [customer] blank. The dollar ra **Start ad-account setup 2-3 days 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) +You will not have to figure out the ad on your own: the launch checklist below links a [step-by-step recipe for your channel](/course/tech-for-non-technical-founders-2026/reference/smoke-test-channel-guide/#campaign-creation-recipes) (7 settings, click by click) plus a copy-paste prompt that writes the ad copy and image concept for you. + +![Signal meter reading the smoke-test conversion rate: 0-3% kill or pivot, 3-6% iterate the message, 6-10% promising, 10-20% strong signal, over 20% suspicious - with the 6% go line marked](smoke-test-signal.svg) ## Launch and read the signal > **Launch:** > -> 1. **Install your channel's pixel.** 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.3. 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). +> 1. **Install your channel's pixel.** A **pixel** is the ad platform's own tracking snippet - it tells the platform which ad clicks turned into signups, so it can find you more of those people and show you cost-per-signup. It reports to the AD PLATFORM; the GA4 you installed in 1.3 reports to YOU. 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 60-second process as Clarity and GA4 in Lesson 1.3. Open your page in an incognito window; verify the pixel fires in your platform's dashboard. Google Ads users: skip this (GA4 links directly and acts as 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.** Resist headline rewrites, bid adjustments, and hourly dashboard refreshes for the full run. 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: +> 5. After 300 visits, work out your conversion rate (form submits ÷ visits that came from your ad campaign - use the campaign's landing-page-view count, not GA4's total page views, so friends and your own refreshes don't dilute the number) and find it on the meter above. The same bands, with the action for each: | Conversion rate from cold traffic | Decision | What to do | |---|---|---| @@ -72,23 +74,27 @@ Choose based on who your hypothesis names in the [customer] blank. The dollar ra *On a boundary (exactly 6%, 10%, or 20%)? Take the higher band's action.* -**✅ Success check:** you have a conversion rate from ≥300 cold visits AND a go/iterate/kill decision written down. +**Success check:** you have a conversion rate from ≥300 cold visits AND a go/iterate/kill decision written down. ## If the number looks wrong -**If this fails: 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 this fails: 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 this fails: 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. +**If this fails: 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. --- -When you read the results, notice which number surprised you most - surprise means the data disagreed with something you believed, and whichever hypothesis blank produced that belief is the one worth testing first in Module 2. +When you read the results, notice which number surprised you most - surprise means the data disagreed with something you believed, and whichever hypothesis blank produced that belief is the one worth testing first in Module 2. Open your Founding Hypothesis doc and check it against the blank you flagged as your riskiest assumption in 1.1: if the surprise landed on that same blank, your instinct was calibrated; if it landed somewhere else, update the flag - Module 2 interviews should chase the new one. --- > **Done:** ≥300 cold visitors have seen your page and you have a conversion rate read against the go/iterate/kill table. Decision written down. > -> **You have now:** Founding Hypothesis (1.1) + clear landing page (1.2) + tracking (1.3) + cold-traffic data + a go / iterate / kill decision (1.4). Price test is next. +> **You have now:** Founding Hypothesis (1.1) + clear landing page (1.2) + tracking (1.3) + cold-traffic data + a go / iterate / kill decision + a waitlist email list in your page builder (typically 15-50 signups - Module 2 interviews and Module 5 invites draw from it). Price test is next. > > **Next:** [1.5 · Price Your Hypothesis on the Smoke-Test Page](/course/tech-for-non-technical-founders-2026/price-hypothesis-on-smoke-test-page/) - adds a Stripe button so you can find out if strangers will pay, not just sign up. > 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 index be011b1b4..53ab5fff9 100644 --- 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 @@ -1,30 +1,70 @@ - - - - - Meta / Google - Ads → - - - Landing - Page - CTA + Form - - - Tracking - Page views: 300 - CTA clicks: 24 - - - Go / Iterate - / Kill - - - - + + Smoke-test signal meter: read your cold-traffic conversion rate against the kill / iterate / promising / strong / suspicious bands. + A horizontal meter from 0 to over 20 percent conversion. Under 3 percent is Kill or pivot (red). 3 to 6 percent is Iterate the message (amber). 6 to 10 percent is Promising (green). 10 to 20 percent is Strong signal (deep green). Over 20 percent is Suspicious - verify with a second channel (gray). A pointer marks the 6 percent line where the demand is real enough to start building. - - - + + + + + Read your conversion rate off the meter + form submits ÷ page views, after 300 cold visitors + + + + 6% = the go line + demand is real - start building + + + + + + + + 0-3% + Kill / pivot + + + + 3-6% + Iterate msg + + + + 6-10% + Promising + + + + 10-20% + Strong signal + + + + 20%+ + Suspicious? + + + + 0% + 3% + 6% + 10% + 20% + + + + + + + A stranger's signup is a real vote. A friend's "sounds great" is not. 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 index db66ffe2e..900a50ab2 100644 --- 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 @@ -28,7 +28,7 @@ related_posts: false > > **Input:** the live landing page URL you published in [Lesson 1.2](/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.4 +> **Output:** you can watch a recording of any visit and read the three numbers that judge your page (views, clicks, signups) - the evidence 1.4's go / iterate / kill call runs on > > **Progress:** M1 · 3 of 5 · Results so far: hypothesis sentence + live landing page @@ -45,9 +45,9 @@ A **tracking snippet** is a small block of code (HTML or JavaScript) that you co You need two things regardless of which ad channel you pick in [Lesson 1.4](/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.4, GA4 links directly to it - no separate pixel needed. +- **[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. -**Your channel-specific pixel** (Meta Pixel, LinkedIn Insight Tag, or Reddit Pixel) gets installed in Lesson 1.4 after you pick your channel - same process (copy snippet, paste in head-tag), under one minute. +(Lesson 1.4 adds one more snippet for the ad platform you pick there - same 60-second copy-paste process, nothing to prepare now.) 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). @@ -72,15 +72,20 @@ Conversion rate = form submits ÷ page views. That is the number your hypothesis > 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.4, 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. +> 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. +> 5. **Verify the conversion event too:** submit the waitlist form once with a test email and confirm a form-submit event appears in GA4's Realtime report. That event is the top of the conversion-rate fraction in Lesson 1.4 - if it doesn't fire now, your week of ad spend reports zero conversions no matter what visitors do. (Builder forms sometimes don't trigger GA4's automatic form tracking; if nothing appears, use your builder's own signup counter as the submit count in 1.4 instead.) > > (One "custom code" field? That field is the head-tag - paste all snippets there.) ## If the dashboard stays empty -**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: 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. +**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. --- 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 index b3675bc90..ebb60b140 100644 --- 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 @@ -2,12 +2,12 @@ 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 **Bad wording** | **Good wording** | +|---|---| +| "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." | 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.) | -**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.) +**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 check. If Exhibit A is vaguer than the outcome-shaped feature list you wrote in Lesson 3.2, that is this flag firing. ### 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. +| **Bad wording** | **Good wording** | +|---|---| +| "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." | "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. | -**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. +**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. ### 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." +| **Bad wording** | **Good wording** | +|---|---| +| "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." | (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. | -**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. +**Flag:** Hourly-rate change-orders with no cap, no estimate review window, and especially "Vendor may proceed upon Client's verbal approval." ### Clause 4 - IP / code ownership @@ -98,13 +96,13 @@ The single highest-stakes clause in the SOW: who owns the code while you're payi ### 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. +| **Bad wording** | **Good wording** | +|---|---| +| "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." | (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. | -**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. +**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. ### Clause 6 - Termination triggers @@ -123,27 +121,27 @@ The [step-by-step exit guide](/blog/fire-dev-shop-guide/) covers what a clean te ### 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." +| **Bad wording** | **Good wording** | +|---|---| +| "Vendor warrants that the Deliverables shall conform to the specifications for thirty (30) days following Delivery." | 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. | -**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. +**Flag:** Warranty starts at "Delivery" rather than "Launch to Production Users." Windows under 60 days. No definition of warranted bug versus "new feature request." ### 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. +| **Bad wording** | **Good wording** | +|---|---| +| "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." | (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." Most commercial disputes settle at mediation before arbitration ever starts. (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 (enforceability varies by forum - confirm this one with your counsel). | -**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. +**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. ## What to do before signing -> **📋 Copy-pasteable pre-sign checklist - do this the night before you sign:** +> **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. 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 index 3332e582b..ef76c4f05 100644 --- 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 @@ -1,7 +1,7 @@ --- 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." +description: "Lesson 3.2 of the From Idea to First Paying Customer course. The quality-gate on your Lesson 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 @@ -23,7 +23,7 @@ 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." + og_description: "Lesson 3.2 of the From Idea to First Paying Customer course. The quality-gate on your Lesson 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 @@ -31,161 +31,83 @@ related_posts: false > **Module 3 · Lesson 3.2 · [CORE] - the quality gate on your 3.1 brief** · [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/)) +> **Input:** a one-page Product Brief (from [Lesson 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 > > **Progress:** M3 · 2 of 2 · Results so far: one-page brief drafted (3.1) - this page stress-tests Section 3 before Module 4 builds from it -> **TL;DR:** Rewrite every feature noun as an outcome-shaped job story. "Build a CSV export" (CSV = a plain spreadsheet file people open in Excel) 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, or jump ahead to [Artifacts you carry out of Module 3](#artifacts-you-carry-out-of-module-3). The examples and the theory will still be here.* +Send a builder four words - "build a simple admin panel" - and you get back 47 buttons, role permissions, an audit log, and an AI co-pilot nobody asked for. This lesson is the 20-minute rewrite that makes the builder ship the three buttons you actually meant, not the spaceship. -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. +After this lesson you will be able to: **rewrite every feature noun in Section 3 of your brief as an outcome-shaped job story - so the builder has no blanks left to fill with a 47-button spaceship.** -You finished Section 3 of your brief in the last lesson, so this page can feel like being asked to write it twice. It is not a rewrite for style - it is the 20-minute check that decides whether the builder ships the three buttons you meant or that 47-button spaceship. The Section 3 you fix here is the exact text Module 4 pastes into Lovable. +The Section 3 you fix here is the exact text Module 4 pastes into Lovable. It is not a rewrite for style - it is the check that decides whether the builder ships what you meant or a bigger thing you'll spend the quarter deleting. ![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 no blanks to fill - 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 bristling with 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 (monthly recurring revenue - what subscribers pay you each month), 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."* (A CRM - customer relationship management tool - is the contact list and deal tracker a sales team works out of.) - -**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. +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 builder invents the missing context. An outcome-shaped request leaves no blanks to fill - the moment, the action, the deadline, and the result are already on the page. ## 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."* +Rewrite every feature noun in three parts. Each part forecloses a category of overbuild. -Put the three parts together and the engineer (or the AI agent) has no gaps left to guess at. 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. +- **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 builder this happens once a week, that there is a deck, that there is a 4pm call. No real-time streaming dashboard for something that happens on a Tuesday afternoon. +- **I want [action + budget]** - a verb on a concrete object, with a limit. *"I want to grab the top 5 metrics in 30 seconds"* is a verb (grab), an object (the 5 metrics), and a budget (30 seconds). No 12-metric dashboard, no async export queue. +- **So I can [outcome]** - the result that proves the build worked. *"So I can paste them into the deck before the 4pm call"* is a finish line the builder holds every feature suggestion up against: does the audit log help you paste before 4pm? No? Cut it. -```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 +Put the three parts together and the builder has no gaps left to guess at. Drop any one - the timeframe, the action, or the outcome - and the gap gets filled from training data instead of your intent. - 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 +Same job, written both ways: - classDef bad fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a - classDef good fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a +> **Feature shape:** *"Build a CSV export button on the dashboard."* The builder ships a reporting module with three dashboards, scheduled email exports, role-based access, a date-range picker, and an audit log. Six weeks. You used the button once a week. +> +> **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."* The builder ships one button that copies five hard-coded metrics to the clipboard. Ninety minutes. The next investor email goes out before the deck opens. - class Feature,F1,F2,F3,F4,FOut bad - class Outcome,O1,O2,OOut good -``` +A second worked pair (the CRM module), the priced-out comparison table, and the full AI-reviewer test protocol live in the [deeper reference](/course/tech-for-non-technical-founders-2026/reference/outcomes-not-features-full/). -## What to do tomorrow +## Do this now -Three actions, in order. +1. Open your filled-in [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) from Lesson 3.1. Find Section 3 ("What you're building"). Read it out loud. Any sentence that leans on a noun-shaped feature ("a CSV button," "a CRM," "user roles," "a settings page") is feature-shaped - mark it. +2. Rewrite each marked sentence in the *When / I want / So I can* shape. The *when* names a specific moment with a deadline; the *I want* names a verb and a budget; the *so I can* names a result you can measure that week. +3. Share the rewritten section with your engineer or your AI agent and ask one question: *"What would you build differently from this brief than from the feature list?"* Their first answer is the scope you were about to lose. -- **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 sentence leans on a noun-shaped feature ("a CSV button," "a CRM," "user roles," "a settings page"), it is feature-shaped. Mark it. -- **Rewrite each marked sentence 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. +**Success check:** every line of Section 3 names a moment and a result, not a piece of software - and the peer's answer stays inside your Section 3 scope and no-go list. -> **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 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. +> **The pass/fail rubric.** The brief PASSES only if the peer's answer stays inside your scope - the features in Section 3 and the items NOT in your no-go list. It FAILS if their answer names anything you cut in the no-go list, OR includes 2+ items outside it (your scope is too vague). No peer handy? Paste Section 3 + Section 5 into [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) and ask it to name 5 things it would build that are NOT in your no-go list. Same signal, no calendar coordination. -> **Test your brief with an AI reviewer.** -> -> **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. -> -> **No peer and no AI account?** The manual pass works too: read each Section 3 line and ask, "is this a thing the user does, or a thing the software has?" A line that names software parts (a dashboard, user roles, a settings page) is feature-shaped - rewrite it in the *When / I want / So I can* shape until it names a moment and a result instead. -> -> **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-2.4 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. +**If this fails: the reviewer names 2+ things outside your no-go list.** +- **Why:** Section 3 is still vague - it names software parts, not moments and results, so the reviewer fills the gaps from training data. +- **Fix:** tighten the *When / I want / So I can* shape on the loosest line and ask a fresh reviewer. Do NOT advance to Module 4 with a failed brief - the Lovable build inherits the fuzziness. ## Artifacts you carry out of Module 3 -After finishing Ch 3.1-3.2, you have five artifacts. Each one feeds a specific downstream destination - this table is the map: +After Lessons 3.1-3.2 you have five artifacts. Each feeds a specific downstream destination - this 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-4.4 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 (Statement of Work - the document that tells a contractor exactly what to build) if you route to hire + Ch 4.3-4.4 Lovable prompt body. Replaces the noun-shaped feature list that causes overbuild. | -| **No-Go list** (5-8 items you explicitly cut from Ch 3.1 Section 5) | Ch 4.3-4.4 self-serve scope guard + Ch 4.5 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-8 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 all three in every line of Section 3, and the builder builds only what you asked for. +| **One-Page Product Brief / Vibe PRD** (3.1 output) | Lesson 4.1 build-path decision + Lesson 4.3-4.4 Lovable kickoff prompt. The single source of truth Module 4 builds from. | +| **Outcome-shaped feature list** (3.2 rewrite of Section 3 in job-story form) | Lesson 4.1 contractor SOW (Statement of Work - the document that tells a contractor exactly what to build) if you route to hire + Lesson 4.3-4.4 Lovable prompt body. Replaces the noun-shaped feature list that causes overbuild. | +| **No-Go list** (5-8 items cut from 3.1 Section 5) | Lesson 4.3-4.4 self-serve scope guard + Lesson 4.5 ceiling-signal monitoring. | +| **Audience-of-one fork** (AI agent / junior dev / senior team, from 3.1) | Lesson 4.1 build-path routing - decides whether the brief goes to Lovable or a contractor. | +| **Quality-check verdict** (3.2 - did the peer answer cleanly?) | Checkpoint before Module 4. If the peer cannot answer cleanly, return here and rewrite Section 3 first. | -## Further reading +> **Module 3 closes here.** Before opening Module 4 you should have: a one-page Product Brief with 5 sections filled in (3.1), Section 3 rewritten as outcome-shaped job stories that pass the peer test (this lesson), and a no-go list of 5-8 items - all in your `Founder OS` folder. If this lesson saved you a build-and-throwaway round, someone you know is about to hand a builder four vague words too - send them this free course page. Missing an artifact? Go back - Module 4 reads the brief into Lovable prompts, and a half-written brief produces a half-working MVP. -- Alan Klement, [*When Coffee and Kale Compete*](https://web.archive.org/web/20230319130354/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://web.archive.org/web/20240819160036/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:** every line of Section 3 is rewritten in the *When / I want / So I can* shape, and one quality-check pass (peer, AI, or the manual question) names nothing outside your Section 3 scope and no-go list. > > **You have now:** the complete Module 3 output - a one-page Product Brief with an outcome-shaped Section 3, a no-go list of 5-8 items, and a passed quality check, all in your `Founder OS` folder. This is the page Module 4 builds from. > > **Next:** [4.1 · Should You Hire? The 2026 Decision Tree](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/) - it reads the brief you just quality-checked as its input. -> **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 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. +> +> **If blocked:** see "If this fails" above. +> +> **Deeper reference:** [The second worked pair, the priced-out comparison, the full AI-reviewer protocol, and stack-ranking outcomes with real users](/course/tech-for-non-technical-founders-2026/reference/outcomes-not-features-full/) --- diff --git a/content/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/daily-weekly-cadence.svg b/content/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/daily-weekly-cadence.svg new file mode 100644 index 000000000..57f727a42 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/daily-weekly-cadence.svg @@ -0,0 +1,84 @@ + + The weekly oversight cadence: five daily standups feed one Friday demo, then the loop resets Monday. + On the left, a daily-standup panel labelled Mon to Fri holds the three questions asked at the end of every standup: show the staging URL of what shipped, walk through one PR you reviewed and what you flagged, and what did we cut to ship it. An arrow labelled five days of proof feeds a green Friday demo card - the week's working software. That feeds a purple weekly report card - what shipped, what is next. A dashed loop returns from the weekly report to the daily standup with the caption: Monday, the loop resets - you already know what should be on staging. + + + + + + + + + + + + The weekly oversight cadence + Five daily standups feed one Friday demo - then the loop resets. + + + + + Daily standup - Mon to Fri + Ask these 3 at the end, every day. + + + 1 + Staging URL of what shipped? + + + 2 + One PR reviewed - what you flagged? + + + 3 + What did we cut to ship it? + + + + 5 days + of proof + + + + + + Friday demo + the week's + working software + + + + + + + + + Weekly report + what shipped, + what's next + + + + + Monday: the loop resets - you already know what should be on staging. + 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 index 06ac3ba69..fd0f5ddbb 100644 --- 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 @@ -37,7 +37,7 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 **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. +*"Yesterday I worked on the order flow. Today I am continuing the order flow."* That sentence can repeat every morning for nine weeks on a **$25K/month** project before anyone clocks that two of the three developers are reading out the same Jira ticket name each day. **Forty-seven standups in**, the ticket has not moved columns in seven weeks - and a founder can sit on every one of those calls, take notes, and nod, because the standup format never asks the question that would catch it. The three questions below are that question, split into three. > **The 3 questions - printable index-card format:** > @@ -59,7 +59,7 @@ The three questions below replace the standard format. You do not have to drop t |----------|----------------|-----------------|------------------------| | **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. | +| **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 two 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. @@ -77,17 +77,17 @@ The question catches the **progress mirage** - tickets moving on Jira while noth 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. +**Pass.** A named PR number, a named reviewer (not "the team"), and 2-3 specific things the reviewer checked. "PR #847, Priya reviewed it. She flagged a missing test on the refund branch, asked why the `Gemfile.lock` had a new gem she had not approved, and pushed back on a hardcoded Stripe key in the controller. The author fixed all three and Priya 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. +**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 ran this check in Q1 2026 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. +**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 two 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. @@ -97,6 +97,8 @@ The question catches **over-engineering** - the failure mode where the team buil The three standup questions are the daily proof. The [Friday demo](/course/tech-for-non-technical-founders-2026/friday-demo-template/) 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. +![The weekly oversight cadence: five daily standups Monday to Friday feed one Friday demo, then the loop resets. Each day's standup ends with the three questions - show the staging URL of what shipped, walk through one PR you reviewed and what you flagged, and what did we cut to ship it. Five days of proof feed the Friday demo, the week's working software, which feeds the weekly report of what shipped and what is next. On Monday the loop resets and the founder already knows what should be on staging.](daily-weekly-cadence.svg) + [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](/course/tech-for-non-technical-founders-2026/friday-demo-template/) holds the full script. ## What to do tomorrow 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 index 9095b39d9..58d7170db 100644 --- 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 @@ -24,9 +24,7 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 related_posts: false --- -📋 Template companion to [the Mom Test synthesis section](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/). Print after running 10 interviews. Fill in 30 minutes. Show to 2 advisors before building anything. - -# Validated Problem Statement Template - One Page, Five Sections +Template companion to [the Mom Test synthesis section](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/). Print after running 10 interviews. Fill in 30 minutes. Show to 2 advisors before building anything. *The synthesis sheet that turns 10 Mom Test transcripts into a build, pivot, or kill decision.* @@ -44,7 +42,7 @@ related_posts: false ## 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. +Send forty-odd cold DMs to strangers venting about their CRM and twelve answer - two yes, ten honest paragraph-long no's - and you have something that feels like validation. Left as transcripts in a folder labeled `notes`, they lie to you. The ten no's blur together in memory and contradict each other on the page; half of them turn out not to be the persona you are building for. Sit down to name the persona, tally the strong signals, and write the why-now, and the 90-minute synthesis can hand you a *pivot to a different ICP* where memory was telling you *build*. That is a weekend you would have spent prompting Lovable, spent instead on five sharper interviews. This template is the page you fill in to force it. ## How to use this @@ -131,7 +129,7 @@ ______ /10 Strong signals (score 7+ with 3+ emotional flags): ___ /10 Decision based on strong-signal count: - [ ] 7 or more → BUILD. Test the shape in Ch 2.6, then Module 3. + [ ] 7 or more → BUILD. Test the shape in Lesson 2.6, then Module 3. [ ] 4 to 6 → PIVOT. Run 5 sharper interviews. [ ] Fewer than 4 → KILL. Find a different problem. @@ -152,6 +150,8 @@ Date: ______________ ## What good looks like vs what bad looks like +Three worked examples for the sections founders most often get wrong - 1, 2, and 4. Sections 3 and 5 are direct transcript copying; the same specific-beats-vague rule applies. + **Section 1 - Who has the problem** > Bad: *"Founders and small business owners who need help with productivity."* @@ -180,13 +180,13 @@ The good version names the specific cost number, the specific competitor's speci 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. Test the shape in [Ch 2.6 · Build a Clickable Prototype](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/), then move to the [Module 3 Product Brief](/course/tech-for-non-technical-founders-2026/). +- **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. Test the shape in [Lesson 2.6 · Build a Clickable Prototype](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/), then move to the [Module 3 Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/). - **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. +- **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/one-page-product-brief-vibe-prd/) 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. diff --git a/content/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/validated-problem-statement-template.pdf b/content/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/validated-problem-statement-template.pdf index 7bee56078..55a487611 100644 Binary files a/content/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/validated-problem-statement-template.pdf and b/content/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/validated-problem-statement-template.pdf 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 index 0eba0a186..125a41f38 100644 --- 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 @@ -30,11 +30,11 @@ 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. +> Companion to [Lesson 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. +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 Lesson 2.1's ten Mom Test interviews. --- @@ -43,29 +43,24 @@ This guide covers three tools - VenturusAI, DimeADozen, and Preuve AI - with eno 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'}}}%% +%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, Comic Sans MS, 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"]) + Draft --> V["VenturusAI · ~30s
    catches weak differentiation
    and missed competitors"] + Draft --> D["DimeADozen · ~2min
    catches wrong unit economics
    and market too small"] + Draft --> P["Preuve AI · ~60s
    catches customer too broad,
    reads market signal"] + V --> Refine["Rewrite the blanks
    the tools flagged"] + D --> Refine + P --> Refine + Refine --> Out(["Sharpened hypothesis
    ready for Lesson 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 ``` @@ -75,10 +70,10 @@ 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 `[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) | +| 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. @@ -125,7 +120,7 @@ Every blank in the Mad Libs sentence is a blank in your VenturusAI input. Specif 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. +**Porter's Five Forces - Competitive Rivalry section.** If it names a competitor you had not thought of, add that competitor to the Competition column in the [full hypothesis sprint](/course/tech-for-non-technical-founders-2026/reference/hypothesis-sprint-full/). 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. @@ -165,7 +160,7 @@ The Starter report is 5-7 pages. You only need to read two sections on the first **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. +**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 Lesson 1.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. @@ -184,7 +179,7 @@ At the pre-interview stage, the $9 Starter is enough. You are looking for red fl ### 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-1.4's smoke test and Ch 2.1's interviews. +- **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 Lesson 1.2-1.4's smoke test and Lesson 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 @@ -218,7 +213,7 @@ The tool matches your description against live data sources. A broad description **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. +**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. @@ -230,7 +225,7 @@ After your first report, the AI Coach suggests pivots based on what the data act - 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. +Treat the pivot suggestions as hypotheses to test in Lesson 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 @@ -260,6 +255,8 @@ For pre-interview validation, the Free Scan + Founder Report is the sweet spot. The three tools work best in sequence, not all at once. Here is the order that produces the most signal for the least time: +![The three validation tools in recommended order: VenturusAI first (free, ~30s) catches missed competitors and weak differentiation, Preuve AI free scan second (free, ~60s) reads market signal and flags a too-broad customer, DimeADozen Starter third (optional, $9, ~2min) catches kill risks and unit economics - none validates the hypothesis, only 10 Mom Test interviews do](tools-in-sequence.svg) + ### 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. @@ -268,7 +265,7 @@ Run your hypothesis paragraph through VenturusAI. Read the Porter's Five Forces ### 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. +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. @@ -278,7 +275,7 @@ If VenturusAI and Preuve both gave green or yellow signals, spend $9 on a DimeAD **Time:** 10 minutes + $9. -### After the tools: Ch 2.1 interviews +### After the tools: Lesson 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. @@ -288,11 +285,11 @@ No tool validates your hypothesis. Only ten strangers describing the problem in 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-1.4's smoke-test landing page and Ch 5.6's Design Partner Agreement with a real deposit. +**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 Lesson 1.2-1.4's smoke-test landing page and Lesson 5.6'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 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 Lesson 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 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 Lesson 1.1 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. @@ -300,9 +297,9 @@ These tools sharpen your hypothesis. They do not validate it. Specifically: ## 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.4 · Smoke Test: Run It and Read the Signal](/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. +- [Lesson 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. +- [Lesson 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. +- [Lesson 1.4 · Smoke Test: Run It and Read the Signal](/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. --- diff --git a/content/course/tech-for-non-technical-founders-2026/validation-tools-field-guide/tools-in-sequence.svg b/content/course/tech-for-non-technical-founders-2026/validation-tools-field-guide/tools-in-sequence.svg new file mode 100644 index 000000000..cd697bd04 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/validation-tools-field-guide/tools-in-sequence.svg @@ -0,0 +1,81 @@ + + The three validation tools in the recommended order: first VenturusAI (free, about 30 seconds) catches missed competitors and weak differentiation; second Preuve AI's free scan (free, about 60 seconds) reads market signal and flags a customer that is too broad; third DimeADozen's Starter report (9 dollars, optional, about 2 minutes) catches kill risks and weak unit economics. None of them validates the hypothesis - only 10 Mom Test interviews do that. + A left-to-right strip of three numbered tool cards joined by arrows. Card 1 VenturusAI: catches missed competitors and weak differentiation; chips read about 30 seconds and Free. Card 2 Preuve AI free scan: reads market signal, flags customer too broad; chips read about 60 seconds and Free scan. Card 3 DimeADozen (optional): catches kill risks and unit economics; chips read about 2 minutes and 9 dollar Starter. + + + + + + + + + The 3 tools, in the order that pays off + Run them in sequence, not all at once - each catches what the next one can't. + + + + + + 1 + VenturusAI + CATCHES + Missed rivals, weak edge + + ~30 seconds + + Free + + + + + + + 2 + Preuve AI + CATCHES + Market signal, too broad + + ~60 seconds + + Free scan + + + + + + + 3 + DimeADozen + optional + CATCHES + Kill risks, unit economics + + ~2 minutes + + $9 Starter + + + + + + + + None of these validates your hypothesis - only 10 Mom Test interviews do that. + 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 index 25af0feb2..b5255dc71 100644 --- 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 @@ -1,7 +1,7 @@ --- title: "4.5 · 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.5 of the course." +description: "The 5 architectural ceiling signals that tell you the Lovable + Supabase + Stripe shed stopped holding. Two firing for 4+ weeks = graduate. Lesson 4.5 of the course." date: 2026-05-13 draft: false course_chapter: true @@ -24,7 +24,7 @@ cover_image: cover.png metatags: image: cover.png og_title: "4.5 · 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.5 of the course." + og_description: "The 5 architectural ceiling signals that tell you the Lovable + Supabase + Stripe shed stopped holding. Two firing = graduate. Lesson 4.5 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 @@ -32,7 +32,7 @@ related_posts: false > **Module 4 · Lesson 4.5 · [OPTIONAL] - a monthly review reference** · [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.3 · Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) + [4.4 · Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/)) +> **Input:** a live MVP on the self-serve stack (from [Lesson 4.3 · Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) + [4.4 · 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 > @@ -40,150 +40,42 @@ related_posts: false > **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 available, no coding required). 38 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). - -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 was coined by Andrej Karpathy in early 2025; indie founder Pieter Levels made it famous in practice 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-4.4); 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 +Your Lovable app is live and the first coaches are paying. The stack that got you here has a ceiling, and it shows up in your dashboard weeks before a customer feels it. This lesson is the monthly check that catches the ceiling early, while it is still a tuning problem and not a rebuild. -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/) handles the common early-SaaS build. The builds it cannot hold are what this post is about. +After this lesson you will be able to: **score five architectural signals each month and decide, on a dated rule, whether to stay self-serve, bridge to a fractional CTO, or hire a team.** -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. +**Vibe Coding** is shipping a real product with AI-generated code from tools like [Lovable](https://lovable.dev), Cursor, or Bolt - no engineer, no dev shop, no months of build. The term was coined by Andrej Karpathy in early 2025; indie founder Pieter Levels made it famous in practice. Done right, it carries you to your first paying users. This lesson is about the moment the shed stops holding. -The 5 signals below are the early-warning system. Run them before you need them. +> **This is a monthly review reference, not an action-today lesson.** 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 (Lesson 4.3-4.4); until then, this 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 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+. +Each signal has a visible symptom you can see in your dashboard tonight, a real cause underneath, and a route to the right kind of help. Score each one green / yellow / red. Signals are ordered by when they typically become detectable - 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 | +| # | Signal (and what you notice) | 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 reviewed in early 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 (roughly $160-$240 - two hours at the $80-$120/hour fractional band). 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) +| 1 | AI inference cost or rate limits - runtime AI bill outruns revenue, or the feature errors at peak | Week 2-4 | Fractional CTO (unit economics) | +| 2 | Data model passes 5 entities - one new feature breaks three old ones | Week 4-6 | Fractional CTO schema review | +| 3 | Real-time becomes non-negotiable - two users edit one record, second save wins | Week 4-8 | Hire engineering team | +| 4 | Auth beyond email + OAuth - a buyer asks for SAML SSO + role access + audit log | Week 6-10 | Fractional CTO scope, then hire | +| 5 | Compliance audit on the calendar - a SOC2 / HIPAA / PCI questionnaire arrives | Week 8-12+ | Hire engineering team | -**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. Some 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. +Run this check monthly and the ceiling shows up while it is still a tuning problem. Wait until something breaks - slow dashboard, duplicate charges, support tickets climbing - and you pay late-fix prices on what was an early-fix problem. The [full signal guide](/course/tech-for-non-technical-founders-2026/reference/ceiling-signals-full/) walks each signal in depth: the symptom, what is happening underneath, the cost of leaving it a month, and the cost of addressing it now. ## The decision: stay self-serve or graduate -The 2-question test runs in 90 seconds. Print it. Tape it inside the laptop case. +The 2-question test runs in 90 seconds. Print it. Tape it inside the laptop case. Two reds count only when each has been firing for 4+ weeks - two reds in a single week is a tuning problem, not a graduation signal. ```mermaid -%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#1a1a1a', 'primaryTextColor':'#1a1a1a'}}}%% +%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, Comic Sans MS, 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)"] + Bridge["GRADUATE:
    BRIDGE
    Fractional CTO
    5 hours / week
    ~$1.6-2.6K / mo"] Hire["GRADUATE: HIRE A TEAM
    1-2 engineers on Rails /
    Django / Laravel. SOW signed
    before kickoff."] Start --> Q1 @@ -194,7 +86,7 @@ flowchart TD 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 bridge fill:#fbe9ff,stroke:#a855f7,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 @@ -204,45 +96,37 @@ flowchart TD 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 No:** stay self-serve. The shed is holding. Re-score every two weeks. Being wrong costs you two weeks of 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 1-2 engineers 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 for a hire. -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. +## Do this now -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. +Three actions. The first is tonight. -> 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. +1. **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. +2. **Score each of the 5 signals green / yellow / red, AND log Date first observed + Date last observed per signal.** Green = no symptom yet. Yellow = symptom in the last 30 days but recoverable. Red = symptom firing 4+ weeks AND you've patched it more than once. Keep it as a Notion table or a sheet: Signal | Status | Date first observed | Date last observed | Notes. Without dated windows you cannot tell "fired once this week" from "fired every week for two months," and the 4-week rule collapses. +3. **If 2+ signals are red AND have been red for 4+ consecutive weeks, start the [Fractional CTO bridge](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge) THIS WEEK.** Not next month, not after the next sprint. The first call is usually free. -## What to do tomorrow +> **Success check:** all 5 signals scored (green/yellow/red) with dated observation windows, and a recurring monthly calendar block titled "Vibe-coding 5-signal check." -Three actions. The first is tonight. +**If this fails: every signal reads yellow and you cannot decide.** +- **Why:** yellow with no dates is a guess, not a reading - you are scoring mood, not symptoms. +- **Fix:** for each yellow, write the exact date you first saw the symptom and the last date you saw it. A symptom you cannot date to a specific dashboard number is a green, not a yellow. Only a symptom firing 4+ weeks with more than one patch is a red. -- **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. Skip the dated logging 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. +Look at your reddest signal. Is it firing because of load you actually have, or load you are afraid you might get? Graduate on the load you have - the shed holds longer than most founders fear. ## Artifacts you carry out of Module 4 -After finishing Ch 4.1-4.5, you have five artifacts. Each one feeds a specific downstream destination - this table is the map: +After finishing Lesson 4.1-4.5, you have 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.7 scripts you use. | -| **Ownership audit results** (12-item checklist - GitHub org owner, repo collaborators, branch protection, AWS root, billing, IAM, DB credentials, secrets store, backups, domain, DNS, third-party keys - all on your company email, from Ch 4.2) | Module 5 contract foundations. The Ch 5.6 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-4.4) | 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.5, 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-2.4 outreach** (from Ch 4.3-4.4 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-2.4 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.7 outbound. | - -Two ceiling signals firing for 4+ weeks means the shed is no longer holding. Either hire a team if you have the runway, or bridge with a Fractional CTO until you do - 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/collection/soc-2/soc-2-compliance-checklist) - the audit-surface checklist a founder usually meets for the first time when an 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. +| **Build-path decision** (validate / self-serve / fractional CTO / hire - chosen and dated, from Lesson 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 Lesson 5.2-5.7 scripts you use. | +| **Ownership audit results** (12-item checklist - GitHub org owner, repo collaborators, branch protection, AWS root, billing, IAM, DB credentials, secrets store, backups, domain, DNS, third-party keys - all on your company email, from Lesson 4.2) | Module 5 contract foundations. The Lesson 5.6 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 Lesson 4.3-4.4) | Lesson 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 Lesson 4.5, 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 Lesson 2.3-2.4 outreach** (from Lesson 4.3-4.4 onboarding) | Lesson 5.1 Sean Ellis 40% test input. 4-6 is the directional starting cohort - Lesson 5.1's "Under-10 respondents" sidebar reads that as MAYBE, not a verdict. Re-engage your Lesson 2.3-2.4 interview leads as Lesson 5.1 invites to get above 10 for a confident reading. Their Q2-Q3 verbatims become the persona language for Lesson 5.7 outbound. | > **Done:** 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." > @@ -251,8 +135,10 @@ Two ceiling signals firing for 4+ weeks means the shed is no longer holding. Eit > **Next:** the core path continues at [5.1 · Your First Customer Is Not a Marketing Problem](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/) - it takes the first users on your live MVP and tests whether they would miss it before you spend on ads. > > **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. +> +> **Deeper reference:** [The full 5-signal guide - each signal's symptom, root cause, cost of waiting, and cost of fixing now, plus the shed-house-skyscraper map and the enterprise "we're pre-SOC2" reply template](/course/tech-for-non-technical-founders-2026/reference/ceiling-signals-full/) -> **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.4), 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. +> **Module 4 closes here.** Before opening Module 5, you should have: (1) a build-path decision from the Lesson 4.1 tree (self-serve / fractional CTO / hire), (2) a Day-1 ownership audit passed (Lesson 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 (Lesson 4.4), and (4) a monthly 5-signal ceiling check on the calendar (this lesson). 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. --- 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 deleted file mode 100644 index df4d3e13d..000000000 --- a/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/signals-scoreboard.svg +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - - - - - - 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/index.md b/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/index.md index be9fb1636..af94633da 100644 --- 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 @@ -9,11 +9,11 @@ author: "JetThoughts Team" slug: vibe-prd-template course_nav_prev: slug: one-page-product-brief-vibe-prd - module: "Chapter 3.1" + module: "Lesson 3.1" title: "3.1 · The One-Page Product Brief (Vibe PRD)" course_nav_next: slug: stop-specifying-features-start-outcomes - module: "Chapter 3.2" + module: "Lesson 3.2" title: "3.2 · Quality-check your brief: features to outcomes" keywords: - vibe prd template @@ -38,9 +38,9 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 related_posts: false --- -> **Template companion to [Chapter 3.1 - The One-Page Product Brief (Vibe PRD)](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/)** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) +> **Template companion to [Lesson 3.1 - The One-Page Product Brief (Vibe PRD)](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/)** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > -> **Input:** your validated problem statement (from the [Chapter 2.5 synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/)) + the "describe in one sentence" vocabulary from your [Chapter 2.6 prototype sessions](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/) +> **Input:** your validated problem statement (from the [Lesson 2.5 synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/)) + the "describe in one sentence" vocabulary from your [Lesson 2.6 prototype sessions](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/) > > **Output:** a filled one-page Product Brief (Vibe PRD), written in one 90-minute sitting, ready to hand to your AI agent or contractor tomorrow @@ -52,18 +52,18 @@ related_posts: false > 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) +> 4. Success metric (one metric, one target 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 a pile of 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 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. +An AI app builder fills every blank you leave with a reasonable default - that is the whole reason a one-page brief exists. Feed it a bare problem statement and "build the simplest version of this," and twelve hours later you are deleting a settings page, a billing dashboard, three integrations, and a pile of toggles you never asked for, and that deleting runs three weeks. Give the same builder a one-page brief with a no-go list, and it ships the smallest end-to-end thing in 90 minutes. The page you fill in between those two attempts is the difference: the agent fills blanks with defaults, and the brief is your only way to forbid them. ## 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: 90 minutes total. If you spill, the persona is too broad or you are designing too much. +Section 1 copies directly from your validated problem statement, word for word. Section 2 pulls from your Module 2 interview notes and [2.6 prototype-session notes](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/) - the moment-of-use detail is already there; don't invent it. Sections 3 through 5 you write from scratch. Hard cap: 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. @@ -71,7 +71,9 @@ Total time budget: 90 minutes to write, 1 hour to read aloud + revise, 0 minutes ## 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. +Use the markdown blocks 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 Lesson 3.1 post for printing. + +Copy section by section, or grab the whole template from the top. ``` ======================= VIBE PRD ======================= @@ -83,7 +85,11 @@ Founder: _________________ Date: _______________________ Source: validated problem statement signed ____/____/____ by ____________________ (advisor 1) and ____________________ (advisor 2) +``` + +**Section 1 - the problem.** Copy this straight from your validated problem statement, word for word. Do not soften the wording. +``` --------------------------------------------------------- 1. THE PROBLEM (copy from validated problem statement) --------------------------------------------------------- @@ -103,7 +109,11 @@ _________________________________________________________ Inherited from validated problem statement - DO NOT paraphrase. If you find yourself softening the wording, stop and reread the original page. +``` +**Section 2 - the user and their context.** The agent or junior needs the moment of use, not the market size. + +``` --------------------------------------------------------- 2. THE USER AND THEIR CONTEXT --------------------------------------------------------- @@ -126,7 +136,11 @@ _________________________________________________________ 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." +``` +**Section 3 - what you're building.** One paragraph's worth, verb-led - the fields below assemble it. If it reads like a feature list, the agent builds a settings page nobody asked for. + +``` --------------------------------------------------------- 3. WHAT YOU'RE BUILDING (one paragraph, plain English) --------------------------------------------------------- @@ -152,9 +166,13 @@ 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. +``` + +**Section 4 - the success metric.** One number, not three. Three metrics let you cherry-pick. +``` --------------------------------------------------------- -4. SUCCESS METRIC (one number) +4. SUCCESS METRIC (one metric) --------------------------------------------------------- Number + unit + timeframe: @@ -171,7 +189,11 @@ _________________________________________________________ One metric, not three. Three metrics let you cherry-pick. One metric forces a build/no-build call in 30 days. +``` + +**Section 5 - what you're not building.** The longer this no-go list, the cheaper your build. +``` --------------------------------------------------------- 5. WHAT YOU'RE NOT BUILDING (the no-go list) --------------------------------------------------------- @@ -191,7 +213,11 @@ 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.** Who the brief is going to, and the dates that keep it honest. + +``` --------------------------------------------------------- HAND-OFF --------------------------------------------------------- @@ -219,8 +245,8 @@ The same one page works for the first three audiences below. Senior engineers an | 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 | +| Hired senior engineer | Traditional PRD | User stories, acceptance criteria, edge cases | 3-5 pages | +| Product committee | Traditional PRD | Goals, KPIs, risks, dependencies, milestones | 5-10 pages | ## What good looks like vs what bad looks like @@ -246,7 +272,7 @@ The good version is one paragraph, verb-led. It names the input (paste CSV), the > 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 the EdTech founder who opens [Chapter 3.1](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) ended up with 17 settings toggles in version one - 12 with no backend, 2 that crashed. Her team had read the brief as a wish list and added everything she didn't forbid. +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 the EdTech founder who opens [Lesson 3.1](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) ended up with 17 settings toggles in version one - 12 with no backend, 2 that crashed. Her team had read the brief as a wish list and added everything she didn't forbid. ## What to do after @@ -256,7 +282,7 @@ The good no-go list names eight things a competent agent or junior might add. Ea 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 for a live cohort vs writing the page yourself for free. +If you want the doctrine in long form, the [Lesson 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 for a live cohort vs writing the page yourself for free. --- 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 index d6ebcc404..09f2411f6 100644 --- 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 @@ -1,5 +1,5 @@ - + 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. @@ -23,7 +23,7 @@ 2. In review PR number + author + named reviewer + what is holding it up - "PR #847 - Marcos opened Tue, Priya reviewing, two changes requested" + "PR #843 - Marcos opened Tue, Priya reviewing, two changes requested" PIPELINE 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 index 6ba49363f..c1027155c 100644 --- 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 @@ -47,7 +47,7 @@ Both teams worked the same five days, and the second report gave you everything ## 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 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 (red-amber-green) status 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. @@ -63,7 +63,7 @@ Send this to your tech lead Sunday night or first-thing Monday. Frame it as the > > **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: demo@example.com / example-pass-123 - 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. +> **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 #843 - 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.` > @@ -96,7 +96,7 @@ 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* +> **Bad** - *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. > @@ -106,14 +106,14 @@ You finish reading at 9:18am. You cannot tell what shipped, who reviewed what, o ### Good report (one page, five sections) -> *Subject: Weekly report - week of 5 Oct* +> **Good** - *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: `demo@example.com / example-pass-123`. > - `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 #843 (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:** 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 index 41d557cbd..0614e2193 100644 --- 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 @@ -1,7 +1,7 @@ - + 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. + 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. @@ -71,7 +71,7 @@ 2. In review - PR #847 - Marcos, Priya reviewing Tue + PR #843 - Marcos, Priya reviewing Tue PR #851 - Marcos, no reviewer (PTO) 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 index 2ea52b5d3..80d824bfe 100644 --- 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 @@ -24,21 +24,19 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 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 +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. *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 +> - **Tier-2 India** (Jaipur, Kochi, Indore, Coimbatore): 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. +The Monday you decide to hire, the map matters more than the job post. Pay $185K base for a San Francisco Senior pitched as "AI-native" and you can still ship one feature every three weeks - a strong coder who has never opened Cursor for a real ship and reviews every contractor PR as if it were a junior's. Walk the same map instead and the arithmetic changes: a Coimbatore Rails engineer at $42 an hour clears a 3-day take-home, ships two features by the following sprint, and has a hallucinated Stripe webhook caught in PR review before it merges - a replacement that costs 22% of the original burn. That map was not on one founder's desk in February. It is on yours now. ## How to use this @@ -50,25 +48,16 @@ Total time budget: 30 minutes alone, 30 minutes posting, 0 minutes second-guessi ## The 4 regions -Walk these four blocks in order. Circle the one your scope and budget land in, then move to the platform list. +Walk the four rows in order. Circle the one your scope and budget land in, then move to the platform list. *The rate bands and hire-cycle times below are our own market reads from placing and hiring engineers through 2025-2026 at JetThoughts, not survey data - treat them as negotiation anchors, and expect your quotes to land inside the band, not on its edges.* -### 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. +| Region | Rate band & time to hire | Pick when | Watch out for | +|---|---|---|---| +| **Onshore (US / EU)** | $130K - $210K+/yr, 30-60 days | Regulated industry (HIPAA, SOC 2 with US data residency, fintech license), security clearance, or board-mandated US team | Low offer-acceptance rates and the worst cost-to-output ratio on the map | +| **Nearshore (LATAM)** | $45 - $100/hr ($90K - $200K annualized), 2-5 days | Real-time timezone overlap for pair programming, customer calls, or daily standups; US founder default in 2026 | 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 | Backend-heavy work where async is acceptable (Jaipur, Kochi, Indore, Coimbatore - NOT Bangalore) | No 9am Pacific standups; async PR culture; build CLAUDE.md / coding-standards docs before the first PR | +| **Mass-market (Upwork)** | $35 - $120/hr project-based, 1-3 days | Single landing page, logo, or one-off scraper - anything you'd ship and never touch again | You become the technical interviewer; no platform vetting; NOT for backend, payments, or auth | ## The 6 platforms ranked @@ -179,12 +168,12 @@ The good answer is countable: years, ships, scale, recent quarter, screenshare o > 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. +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 [Infosecurity Magazine writeup on AI code supply chain attacks](https://www.infosecurity-magazine.com/news/ai-hallucinations-slopsquatting/); 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). +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 [7-question hiring interview script](/course/tech-for-non-technical-founders-2026/hiring-interview-script/). 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. diff --git a/data/course_banned_strings.yaml b/data/course_banned_strings.yaml index 157688097..b17637148 100644 --- a/data/course_banned_strings.yaml +++ b/data/course_banned_strings.yaml @@ -319,3 +319,44 @@ banned: - string: "clicked your fake" reason: "worksheet Q1 conflated the 1.4 Promising band (email sign-ups) with the 1.5 Buy-button price test" scope: "build-path-decision-worksheet" + - string: "Airtable" + reason: "operating kit tracker teaches a Google Sheet (Ch 5.5/5.7 canon), not Airtable (fixed 2026-07-12); scoped because Airtable is a legitimate Concierge-MVP no-code stack example elsewhere" + scope: "first-paying-customer-operating-kit" + - string: "It's a diagnostic, not a gate" + reason: "banned slogany reveal-twist flip (voice guide)" + - string: "after 12 interviews" + reason: "course canon is ten interviews everywhere" + - string: "Picture the situation" + reason: "banned AI-narration imperative-frame opener" + - string: "standup + report + spaceship" + reason: "fixed 2026-07-12; never re-add" + - string: "Two failed questions is a walkaway" + reason: "contradicted the page's own 2-or-below-out-of-5 walk threshold; fixed 2026-07-13" + - string: "the deposit is year-one ACV" + reason: "deposit is 10-30% of ACV credited toward it (5.6 canon), never the full year-one value" + - string: "51% offer-acceptance rate" + reason: "fabricated-precision market stat outside the rate-band disclaimer scope" + - string: "Devon in the table above" + reason: "wrong-direction table reference; the invoice table is below" + - string: "In April 2025, Lasso Security" + reason: "Lasso research is March 2025; April is the Infosecurity coinage" + - string: "Marcus reviewed" + reason: "recurring reviewer cast is Marcos/Priya; Marcus spelling retired 2026-07-13" + - string: "Eight of the first twenty replied" + reason: "40% reply rate overshoots the 2.4 lesson's own 20-30% ceiling" + - string: "substitutes at ~10% of the cost" + reason: "overstated; Reddit substitute is a quarter to a seventh of LinkedIn cost, two others free" + - string: "The founders we work with in 2026 did not lose money" + reason: "fake-authority cohort generalization (voice guide)" + - string: "In April 2025 a security researcher published" + reason: "Lasso research is March 2025; April is only the slopsquatting coinage" + - string: "2.9% + 30c per transaction" + reason: "hardcoded Stripe rate dodging the '2.9% + $0.30' ban via rephrase; use capability language + pricing link (fixed 2026-07-17 outbound-full)" + - string: "who came to us in early 2026" + reason: "rescue/client-attribution + year-stamp in course bodies (voice wave attribution sweep); build-path opener converted to disclaimered composite 2026-07-17" + - string: "came to us in March 2026" + reason: "rescue/client-attribution + date-stamp straggler the voice wave missed (fixed 2026-07-17 outbound-full)" + - string: "part-time work, ~$8-15K" + reason: "inflated fractional total contradicting the doc's own $80-120/hr band; express as the band instead (fixed 2026-07-17 ceiling-signals-full)" + - string: "12 rules, communities" + reason: "over-attributes migrated content to Lesson 4.3; the 12 build rules + founder communities live in reference/stack-tools-full after 4.3 was compressed - 4.3 covers tool boundaries, the 3 pre-flight rules, and the AI critic block only (3 instances fixed 2026-07-17 seam audit)" diff --git a/data/course_sequence.yaml b/data/course_sequence.yaml index 165792006..3bb4bb415 100644 --- a/data/course_sequence.yaml +++ b/data/course_sequence.yaml @@ -11,7 +11,7 @@ # {{< course-stat chapters >}} counts entries minus the Chapter 0 overview, # {{< course-stat modules >}} counts distinct module numbers, and any other # key resolves from the stats: map below. Never hardcode exact counts in -# course prose; frontmatter/covers use near numbers ("20+ chapters") instead. +# course prose; frontmatter/covers use near numbers ("20+ lessons") instead. # # 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. @@ -28,52 +28,61 @@ stats: 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." + module: "Overview" + goal: "The map: 5 modules, 20+ lessons, 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" + module: "Lesson 1.1" goal: "Rewrite your idea as a one-sentence bet scored ≥14/20 across four lenses - five specific blanks, each one a testable assumption." - slug: smoke-test-build-page title: "1.2 · Smoke Test: Build the Page with an AI Builder" - module: "Chapter 1.2" + module: "Lesson 1.2" 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.3 · Wire Tracking Before Traffic Starts" - module: "Chapter 1.3" + module: "Lesson 1.3" goal: "Install Microsoft Clarity and GA4 before you spend a cent on traffic - the ad-platform pixel follows in 1.4." - slug: smoke-test-landing-page-7-day-demand-test title: "1.4 · Smoke Test: Run It and Read the Signal" - module: "Chapter 1.4" + module: "Lesson 1.4" 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.5 · Price Your Hypothesis on the Smoke-Test Page" - module: "Chapter 1.5" + module: "Lesson 1.5" 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" + module: "Lesson 2.1" goal: "Learn the 5-question Mom Test technique and build your draft interview question list." + # 2.2 is an optional rehearsal detour (FEEDBACK.md item 6) - mirror the + # 5.1-around-5.2 branch pattern so the core path doesn't funnel through it. + branches: + - slug: find-10-people-where-to-look + direction: "Core path →" + title: "2.3 · Find 10 People: Where to Look" + - slug: ai-persona-pre-validation-mom-test-prep + direction: "Optional rehearsal →" + title: "2.2 · Sharpen Your Question List with AI Personas (skip if your list already reads past-tense and specific)" - slug: ai-persona-pre-validation-mom-test-prep title: "2.2 · Sharpen Your Question List with AI Personas" - module: "Chapter 2.2" + module: "Lesson 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.3 · Find 10 People: Where to Look" - module: "Chapter 2.3" + module: "Lesson 2.3" 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.4 · Find 10 People: What to Say" - module: "Chapter 2.4" + module: "Lesson 2.4" goal: "The 3-message sequence, volume targets, and research-panel fallback that turn the 30-name list into 10 booked interviews (expanding the list if replies run thin)." # Branch-aware strip (40.17 P1 #1): the linear Next jumped straight to the # 2.5 scoring gate, skipping the days-long "actually run the interviews" loop. @@ -87,7 +96,7 @@ sequence: - slug: mom-test-synthesis-build-pivot-kill title: "2.5 · Mom Test Synthesis: Build, Pivot, or Kill" - module: "Chapter 2.5" + module: "Lesson 2.5" goal: "Score the 10 transcripts, count strong signals, and make the build / pivot / kill call: 7+ build, 4-6 pivot, under 4 kill." # Branch-aware strip (40.17 P1 #1): a single "Next → 2.6" hid the gate and # funneled pivot/kill scorers into building the thing they just invalidated. @@ -104,47 +113,47 @@ sequence: - slug: clickable-prototype-validation-2-hour-lovable title: "2.6 · Build a Clickable Prototype" - module: "Chapter 2.6" + module: "Lesson 2.6" 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" + module: "Lesson 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" + module: "Lesson 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" + module: "Lesson 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" + module: "Lesson 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.3 · The Self-Serve MVP Stack: Tools & Setup" - module: "Chapter 4.3" + module: "Lesson 4.3" 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.4 · The Self-Serve MVP Stack: Build Phases" - module: "Chapter 4.4" + module: "Lesson 4.4" 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.5 · Vibe Coding Done Right: 5 Ceiling Signals" - module: "Chapter 4.5" + module: "Lesson 4.5" 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" + module: "Lesson 5.1" goal: "Pass the Sean Ellis 40% test against your earliest users before any paid ads." # Branch-aware strip (40.17 P1 #1): the linear Next detoured the core path # into optional 5.2; the core path continues at 5.3. @@ -158,30 +167,30 @@ sequence: - slug: channel-selection-before-outbound title: "5.2 · Choose Your Channel Before You Send One Message" - module: "Chapter 5.2" + module: "Lesson 5.2" goal: "Pick one outreach channel you'll commit to before scaling." - slug: first-ten-customers-network-list title: "5.3 · Build Your 50-Name Network List" - module: "Chapter 5.3" + module: "Lesson 5.3" goal: "Sort 50 names into 4 outreach buckets so you know exactly who to message first." - slug: first-ten-customers-outreach-message title: "5.4 · Write the Outreach Message" - module: "Chapter 5.4" + module: "Lesson 5.4" goal: "Write 4 outreach message variants (one per bucket) and record a 90-second Loom that gets replies." - slug: first-ten-customers-send-track title: "5.5 · Send, Track, and Read the Replies" - module: "Chapter 5.5" + module: "Lesson 5.5" goal: "Send 50 messages in the right sequence, track replies in a spreadsheet, and diagnose what a no actually means." - slug: paid-pilot-charge-before-ship title: "5.6 · Charge Before You Ship: The Paid Pilot Contract" - module: "Chapter 5.6" + module: "Lesson 5.6" goal: "Sign a Design Partner Agreement with a refundable Stripe deposit before writing new code." - slug: outbound-without-sales-team title: "5.7 · Going Outbound Without a Sales Team" - module: "Chapter 5.7" + module: "Lesson 5.7" goal: "Send 30 filtered cold messages and book 1-2 paid pilots after the warm-network pass." diff --git a/docs/projects/2605-tech-for-non-technical-founders/FEEDBACK.md b/docs/projects/2605-tech-for-non-technical-founders/FEEDBACK.md new file mode 100644 index 000000000..bcf51a903 --- /dev/null +++ b/docs/projects/2605-tech-for-non-technical-founders/FEEDBACK.md @@ -0,0 +1,43 @@ +0. Overall: + + a. It's very common to see that list elements are rendered as raw parahpgra. For example we have block with "Why:" and "Fix:", which are different blocks, but in the same paragraph; also we have Channel:, When to pick:, and Skip when: - they are as one pragraph is hard to find or scan, but it uses less spaces. Please re-review all those blocks with some steps, categorizations, and other good for list content and revise the solution. You can check online for similar soultions. Before start, review the screenshots with those blocks to understand me, ex: "Channel by ICP (Full Breakdown)", "If the dashboard stays empty", "If the number looks wrong", and etc. + +1. https://jetthoughts.com/course/tech-for-non-technical-founders-2026/smoke-test-build-page/ + + a. As user I do not feel confident how to build for site the Value Props. It has only 1 sentence. Also I have concern, how Mixo would know the structure of the page, which we want it: 4 blocks? Should we build the prompt for Mixo? How that prompt should looks like? Basically we need to give the student the prompt whihc they should use for Mixo. There is no clue what is it. Only acceptance criteria. In Build the page section, we have some prompt to improve but we can from first step in proactive way to give Mixo correct prompt with some acceptance critieria. Later in the text we have some prompt to use for general AI but for Carrd, why we can have the same for Mixo? Also the prompt for Carrd is too general, and based on the best practices of the prompting need to provide more context in order to build, ideally in the prompt ask to run simplest research too to pre-validate and find all missed details or stuff from competitors or similar services or from forums and etc. In the prompt we can add all details which already know: hypothesis, similar products, pain points, forum messages and etc. By the way we can have a prompt for search ai engine like perplexitiy to find all appropriate forum messages to find exact their opinions or pains or gains with using the real user wordings. + b. "Build the page" section has too big paragraphs, and hard to follow or scan the steps + c. "Why:" and "Fix:" should have appropriate colors or be as list to easily detected. For example: Why as yellow like and Fix as green like; or as list will be fine. + +2. https://jetthoughts.com/course/tech-for-non-technical-founders-2026/smoke-test-wire-tracking/ + + a. cover image is not available, there is 404 error + b. `Output: Clarity + GA4 installed on your landing page - ready for channel selection and pixel install in Lesson 1.4` - we should speak about outcome not output, so here what are the value produces Clarity and GA4? Metrics? Insights? What is the outcome? + c. why do we need to say about " channel-specific pixel " on this stage? is it critical to say about it here, or 1.4 will be enough for introduction? + +3. https://jetthoughts.com/course/tech-for-non-technical-founders-2026/smoke-test-landing-page-7-day-demand-test/ + + a. `names in the [customer] blank.` `[customer]` does not have any formatiting or typogrpahy + b. there is just saying that you need to setup ads, but there is no help how to build good enough ad for the landing page, which is the blocker for me. I need to have more explicit instructions how to run ideal ad, with image and copy generation. I do not want to research myself how to do it. I have frustration and pain to do stuff which I do not know, show me that this is simplest and I should not be worry. But later there is the link to the instruction, which is too late as for me, will be great to notice in advance that you will guide me how to do it, and what to use for this, but later. + c. but if we have GA on 1.3 step, why do we need to say about "channel-specific pixel" on this step? What is the difference? here we itnroduces pixels and new channels, but CPC we arelady introduced on previous step. This is confusion, can you some how distinct them? originally it was on one big page and we have splitted it, so how to make them atomic steps, where next step extends previous. Here is looks like setup Ads for the landing page to increase paid channels, and on 1.3 we just review metrics, including views, clicks, and etc. + +4. https://jetthoughts.com/course/tech-for-non-technical-founders-2026/reference/smoke-test-channel-guide/#campaign-creation-recipes + + a. will be great to have some prompt template to build ideal Ad based on the details which we already have, like Hypothesis, landing page blocks, ICP (pains, wordings, gains, goals) + +5. http://localhost:1313/course/tech-for-non-technical-founders-2026/form-your-founding-hypothesis-90-minute-sprint/ + + a. will be great to companion page or isntructions how easily to get "find a verbatim quote from a real person complaining about this problem (Reddit, G2 reviews, or a conversation you had).", I think we have some reference for such tools in the existed companion page. + +6. http://localhost:1313/course/tech-for-non-technical-founders-2026/ai-persona-pre-validation-mom-test-prep/ + + a. looks like AI helper, companion. Do we need this step as required? should it come before real itnerview? should it be companion page as others AI enabler or this is must have as step? + b. if this is a step, is it pass our lesson length constraint? or it should be as companion with whole details and should not apply lessons lenght cosntrain? + +7. http://localhost:1313/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/ + + a. "Before you start: write three sentences" in this section we again have similar to our hypothes sentences, which a little beigger. Is it ok? should we notice that this is expand our original hypothesis? or even can we reuse our hypotheis isntead? + 1) should we use this section recomendation on lesson 1.1 where we are trying to build hypotheiss? + 2) "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." - why we references future material? can we skip this step until 3.1? + b. we have introduced Competitors, but before we have not used them, is it too late to use them? or should we review and track compettiotrs earlier? + c. "Read where they’re already complaining" - we only now looks where are they compaining, but in Module 1 for site we already asking to find the quotes, which is result of this section. Confusion? + diff --git a/docs/workflows/course-audit-checklist.md b/docs/workflows/course-audit-checklist.md new file mode 100644 index 000000000..1d1d80c33 --- /dev/null +++ b/docs/workflows/course-audit-checklist.md @@ -0,0 +1,196 @@ +# Course Audit Runbook (mechanical checklist for any agent) + +Purpose: let a less-powerful agent run the FULL course audit (structure, length, +terminology, canon, voice, reuse/seams, render) with minimal judgment. Every +check below is a command + a pass rule. Where judgment is unavoidable, the check +gives scoring anchors and an escalation rule instead of asking for taste. + +Scope root: `content/course/tech-for-non-technical-founders-2026/` (call it `$C`). +Run everything FROM THE REPO ROOT. Background shells inherit cwd - launching +`bin/rake` from a subdirectory fails with a misleading exit 0 (2026-07 incident). + +Binding sources (read before starting; do not audit from memory): +- Format spec: `docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.03-course-format-requirements-for-creators.md` +- Canon: `.okf/content/course-canon.md` (numbers, cast, terminology, progressive-elaboration rule) +- Voice: `docs/90-99-content-strategy/strategy-analysis/90.11-voice-guide.md` + CLAUDE.md "Zero tolerance AI patterns" + "Slop detector" sections +- Render gate: `docs/workflows/visual-scroll-gate.md` (the FULL protocol; Phase 6 below is a pointer, not a replacement) +- Sequence/wiring: `data/course_sequence.yaml` + +--- + +## Phase 0 - Setup + +```sh +bin/hugo-build # must exit 0; 8 course validators run inside +ls $C # enumerate pages; classify each as: + # lesson (N.N in title), walkthrough, + # template/companion, reference/*-full, landing/faq/overview +``` +Never review repo-root `public/` - built output is `_dest/public-dev/` only. + +## Phase 1 - Length (mechanical) + +Body word count, uniform basis (frontmatter + code fences stripped): + +```sh +for f in $C/*/index.md $C/reference/*/index.md; do + w=$(awk 'f&&!/^---$/{print} /^---$/{f++}' "$f" | sed '/^```/,/^```/d' | wc -w) + echo "$w $f" +done | sort -rn +``` + +Pass rules: +- Lessons: 900-1,500 on this basis = PASS ("exemplar parity" - the migrated + 1.4 exemplar measures ~1,258; the 30.03 raw bands of 400-600/600-900 are on a + stricter prose-only basis and are NOT the gate). 1,500-2,100 = PASS only if + the overage is mandated keeps (full prompts, teaching tables, reuse bridges) - + name them. >2,100 = FAIL (unmigrated or bloated). +- reference/*-full pages: 1,100-2,900 = PASS. >2,900 = flag. +- Walkthroughs/landing: no band; flag only >2,500 as "long, not auto-defect". + +## Phase 2 - Structure (mechanical greps, one per element) + +For every LESSON (numbered N.N), each must be exactly 1 (0 = missing, 2+ = duplicated): + +```sh +grep -c "After this lesson you will be able to" $f # outcome line +grep -c "Success check" $f # labeled success check +grep -c "If this fails" $f # >=1 labeled failure block +grep -c "> \*\*Done:\*\*" $f # closure slots: +grep -c "> \*\*You have now:\*\*" $f +grep -c "> \*\*Next:\*\*" $f +grep -c "> \*\*If blocked:\*\*" $f +grep -c "Deeper reference" $f # footer pointer (lessons with a reference companion) +grep -c "Module [0-9] · Lesson" $f # orientation badge line +grep -c "\*\*Input:\*\*" $f ; grep -c "\*\*Output:\*\*" $f ; grep -c "\*\*Progress:\*\*" $f +grep -c "See it in action" $f # walkthrough link +grep -c "Built by \[JetThoughts\]" $f # JT footer +``` + +Visual count - exactly ONE per lesson body (references may hold more): + +```sh +grep -c '!\[' $f # markdown images (SVG/PNG) +grep -c '```mermaid' $f # mermaid blocks; images+mermaid total == 1 +``` + +Optional lessons additionally need: `[OPTIONAL]` in the orientation badge + a +skip line. Check `data/course_sequence.yaml` for which are optional/branched, +and that each lesson's `Next:` matches the yaml order (branches included). + +## Phase 3 - Terminology + banned strings (mechanical) + +```sh +grep -rn "—" $C --include="*.md" --include="*.svg" # em-dash: ZERO allowed; dashes are "-" +grep -rnE "\b(Chapter|Ch)\s+[0-9]+\.[0-9]+" $C # ZERO; numbered units are "Lesson N.N" +grep -rn "this chapter\|next chapter\|the chapter" $C --include="*.md" + # allowed ONLY for the non-numbered Going-Further long-form set; on numbered + # lessons = violation ("this lesson") +grep -rn "## Why this matters\|Founders who\|Most founders\|Founders we worked with" $C +grep -rn "we picked up\|we worked with\|I rode shotgun\|I spoke with last" $C --include="*.md" + # ZERO outside the 4 approved composite-disclaimed vignettes +grep -rn "Illustrative composite" $C --include="*.md" # every retained vignette needs this line +``` + +Also run every signature in `data/course_banned_strings.yaml` (the build does +this, but run it explicitly when auditing uncommitted work). +SVGs are NOT scanned by the ratchet - grep them separately (first command above) +and rasterize in Phase 6. + +## Phase 4 - Canon numbers (mechanical diff against the table) + +Open `.okf/content/course-canon.md`. For each canonical number, grep the course +for the concept and compare EXACTLY. Current table (verify against canon file - +it is the source of truth, this list is a convenience snapshot): + +| Concept | Canon | Watch for | +|---|---|---| +| Smoke-test cold visits | 300 | any other visit count | +| Conversion bands | <3 kill / 3-6 iterate / 6-10 promising / 10-20 strong / >20 suspicious | boundary drift | +| Interviews | 10 (30-name list feeding them) | "5 interviews" etc. | +| Sean Ellis | 40% = SURVEY very-disappointed share; thresholds >=10 directional / 20+ useful / 30+ sliceable | conflation with the 40% retention cut (churn page keeps them distinct) | +| Deposit | 10-30% of year-one ACV, $500 floor; customer-cancel = forfeit, founder-cancel = 100% refund | "refundable" applied to customer-cancel | +| Reply bands | 20-30% named-post / 1-5% generic (M2 research); 3-8% cold, <5% stop, 5-10% continue, >10% accelerate (5.7); 30+% warm (M5) | cross-assignment | +| Build/pivot/kill | 7+ / 4-6 / <4 | - | +| Tokens | $80-300 API on top of $20-40 Cursor seat; $500 undisciplined ceiling; $80-120 disciplined team total | Cursor $20-60 (wrong); note: app RUNTIME inference cost (4.5 Signal 1) is a different mechanism - do not "fix" it to seat numbers | +| Weekly-dev-report PRs | #843 admin-search (Priya), #851 rate-limiting (no reviewer, PTO); #847 reserved for refund-branch story | #847 used as generic example | +| Cast | Mia (walkthroughs), Marcos/Priya | "Marcus" misspelling | + +Rule: a mismatch is a defect ONLY if it is the same concept. Same number for a +different mechanism (runtime inference vs dev seats) is NOT drift - record it as +"checked, distinct concept". + +## Phase 5 - Reuse / seams (procedural) + +1. Build the artifact ledger: read every lesson's `Output:` + `You have now:` + lines in yaml order. The ledger is what the reader HOLDS after each lesson. +2. For every prompt/worksheet/tool step in later lessons: does it consume the + ledger artifact BY NAME (link or canonical slot: `[customer]` `[problem]` + `[approach]` `[competition]` `[differentiation]` `[hypothesis]` + `[customer quote]` `[competitor URL]`)? A step that re-asks for something the + ledger holds ("describe your product") = FAIL (owner rule: "expand previous + results, never start over"). A renamed slot for an existing artifact = FAIL. +3. Inbound anchors: `grep -rn "/#" $C --include="*.md"` - for each `slug/#anchor`, + verify the id exists in `_dest/public-dev//index.html`. +4. Lesson-vs-reference duplication: for each `reference/*-full`, spot-diff its + tables/prompts/scripts against its lesson - moved content must live in ONE + place (byte-excerpt + pointer is allowed; the 5.6 DPA block is canonical in + the LESSON, the kit excerpts it). +5. Positional prose: `grep -rn "above\|below" $f` on any page whose content + moved - verify each still points the right way in the BUILT page. +6. Walkthroughs (`module-N-walkthrough-mia`): each per-lesson beat must not + contradict the compressed lesson. +7. One-canonical-home registry: SOW table = sow-reading-guide; agency rubric = + agency-ai-five-questions; DPA = 5.6 `#dpa-template`; outreach sequence = + outreach-sequence-template. Siblings point, never duplicate. + +## Phase 6 - Render gate (pointer - run the real one) + +Run `docs/workflows/visual-scroll-gate.md` IN FULL on every page you touched or +audited as changed: headless walk at 1280 wide reading EVERY slice, numeric +probes, rasterize EVERY SVG in scope and read each PNG (moved SVGs especially - +their internal text may reference their OLD host page). Mobile needs +chrome-devtools MCP; raw headless 390px is fake overflow - never report it. +Report as evidence ("N pages x M slices, found X, fixed Y"), never "looks fine". + +## Phase 7 - Judged checks (anchored, escalate when unsure) + +- Opener-shape taxonomy: mechanism-first / artifact-first / direct-address / + question / composite vignette (disclaimed). Count shapes across the audited + set: no shape on more than 4 pages in a sibling set; no 3 consecutive pages + (in reading order) sharing one; linked pairs must differ. +- Shape-tells (flag, quote the sentence, propose a one-edit fix): reveal-twist + flips ("It's not X. It's Y."), cost-stacked tri-list openers, aphoristic + closers, cinematic present-tense scene-setting, sustained staccato (3+ + fragments), "The..." paragraph-opener density >20%, unsourced cohort stats. +- Sam glossing: list every acronym/tool on the page; each must be glossed at + FIRST mention in plain words. (Audience: idea-stage non-technical first-timer; + NOT the website rescue ICP - rescue/trauma framing in course bodies = flag.) +- Callout rhythm: 3+ same-form blockquotes adjacent = flag. +- ESCALATE to a stronger model / the owner instead of guessing: taste scores, + rewriting more than 2 sentences, canon conflicts between two sources, any fix + that would touch structure or >1 paragraph (surgical-edit discipline). + +## Phase 8 - Fix + report protocol + +- One defect = one edit. Never re-theme a page. Preserve reuse bridges byte-exact. +- Prose-defect fixes add a `data/course_banned_strings.yaml` signature in the + same change set (SVG fixes cannot be ratcheted - re-run Phase 6 instead). +- Gates before any commit, FROM REPO ROOT, reading the output file: + `bin/hugo-build` AND `bin/rake test:critical` AND (if `lib/` or validators + changed) `bundle exec rake test:unit` - CI runs the unit suite; test:critical + does not include it (2026-07-17 incident). +- Template pages in `bin/generate-template-pdfs` need PDF regen when their body + changes; restore untouched PDFs (regen churns bytes). +- Report format: counts per phase, then severity-ranked defects, each with + file:line + verbatim offending text + the fix applied (or "report-only" + + why). State what you did NOT check. + +## Known process failure modes (from retrospectives) + +- Audits must run on the CURRENT tree - an audit of pages that a fixer then + rewrites certifies nothing; re-audit after any rewrite wave. +- Fixer self-reports are claims: verify counts/greps/renders yourself. +- Parallel fixers own files; NOBODY owns seams unless a seam pass is scheduled. +- Agents go idle without reporting - inspect their work in the tree. +- `.git/index.lock` contention from daemons - retry loop around git ops. diff --git a/docs/workflows/visual-scroll-gate.md b/docs/workflows/visual-scroll-gate.md index 80d1b3aa6..de12528e3 100644 --- a/docs/workflows/visual-scroll-gate.md +++ b/docs/workflows/visual-scroll-gate.md @@ -54,6 +54,32 @@ EVERY page, which reads as fake overflow. Mobile checks need the chrome-devtools MCP resize (or DevTools device emulation); use raw headless only for desktop-width captures. +## Design-quality pass (separate from defect QA - 2026-07-12 lesson) + +Defect-checklist reviews systematically MISS taste problems: reviewer +rubrics bias toward provable failures (overflow, broken links, banned +strings) and "intentional style" allowances teach reviewers to wave +through badly-executed instances of the style. The owner repeatedly +caught dated/ugly visuals that geometry-QA rounds had passed. When the +goal is "premium", run a dedicated critic pass with these properties: + +1. **Score, don't checklist**: 1-5 design-quality scale per asset with a + FORCED worst-first ranking (must name the bottom N with specific + visual sins). Critics allowed to say "this is ugly" without a rule ID. +2. **External anchor**: judge against market-premium references, not + against the sibling corpus - when 40 assets share a style, the style + becomes the baseline and only outliers get flagged. +3. **Judge in page context too**: an asset fine in isolation fails if it + duplicates the adjacent table/list, or repeats what the H1 says. +4. **Read the TEXT inside artwork against policy**: prices, counts, + chapter numbers, banned phrases inside SVG/mermaid escape the + banned-string ratchet (it never scans them) - check manually. +5. **"Intentional style" never exempts execution**: the question is not + "is sketch style allowed?" but "is this a GOOD sketch?". +6. Mermaid renders client-side: text validators never see it. Theme-level + problems (edge weight, label chips, font-to-node ratio) repeat across + every diagram - diagnose once at the theme, not per diagram. + ## Per-view checklist | Class | What to look for | Caught before | diff --git a/lib/course_validators.rb b/lib/course_validators.rb index e9d0c3774..262bf82bd 100644 --- a/lib/course_validators.rb +++ b/lib/course_validators.rb @@ -43,9 +43,11 @@ def run_all 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. + # ── Validator 1: Lesson-number consistency ─────────────────────────────── + # Every "Lesson N.X" reference in body/frontmatter/SVG must resolve to an + # entry in data/course_sequence.yaml. Course canon calls the numbered core + # units "Lessons" (30.03 format spec); any numbered "Chapter N.X" or + # "Ch N.X" reference is a terminology violation. def check_chapter_number_consistency violations = [] @@ -55,14 +57,19 @@ def check_chapter_number_consistency 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| + # Find all "Lesson N.X" patterns in the body (not inside URLs or code blocks) + body.scan(/Lesson\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" + violations << "#{slug}: references 'Lesson #{ref}' which is not in course_sequence.yaml" end end + # Numbered Chapter/Ch references are retired terminology (canon: Lesson) + body.scan(/\b(Chapter|Ch)\s+(\d+\.\d+)/) do |match| + violations << "#{slug}: uses '#{match[0]} #{match[1]}' - numbered core units are 'Lesson N.N' (30.03 spec)" + 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 @@ -84,13 +91,17 @@ def check_chapter_number_consistency slug = File.basename(File.dirname(svg_path)) content = File.read(svg_path) - content.scan(/Chapter\s+(\d+\.\d+)/) do |match| + content.scan(/Lesson\s+(\d+\.\d+)/) do |match| ref = match.first - next if ref == "Chapter 0.0" # Skip any default/placeholder + next if ref == "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" + violations << "#{slug}/#{File.basename(svg_path)}: SVG references 'Lesson #{ref}' which is not in course_sequence.yaml" end end + + content.scan(/\b(Chapter|Ch)\s+(\d+\.\d+)/) do |match| + violations << "#{slug}/#{File.basename(svg_path)}: SVG uses '#{match[0]} #{match[1]}' - numbered core units are 'Lesson N.N' (30.03 spec)" + end end Result.new(name: "chapter-number-consistency", passed: violations.empty?, violations: violations) diff --git a/test/unit/course_validators_test.rb b/test/unit/course_validators_test.rb index 78f35d8fb..2ced8e8a3 100644 --- a/test/unit/course_validators_test.rb +++ b/test/unit/course_validators_test.rb @@ -79,7 +79,7 @@ def test_chapter_number_consistency_all_valid { "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") + body: "See Lesson 1.1 for details. Also Lesson 1.1 has more info.\n") results = CourseValidators.run_all result = results.find { |r| r.name == "chapter-number-consistency" } @@ -87,17 +87,31 @@ def test_chapter_number_consistency_all_valid assert result.passed, "Expected no chapter-number violations, got: #{result.violations.inspect}" end + def test_chapter_number_consistency_flags_chapter_terminology + write_yaml([ + { "slug" => "ch1", "title" => "1.1 · Test Chapter", "module" => "Lesson 1.1", "goal" => "Test" } + ]) + write_course_chapter(slug: "ch1", title: "1.1 · Test Chapter", + body: "See Chapter 1.1 for details.\n") + + results = CourseValidators.run_all + result = results.find { |r| r.name == "chapter-number-consistency" } + + refute result.passed, "Expected a terminology violation for 'Chapter 1.1'" + assert result.violations.any? { |v| v.include?("Lesson N.N") } + 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") + body: "See Lesson 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" + refute result.passed, "Expected a violation for invalid Lesson 9.9" assert result.violations.any? { |v| v.include?("9.9") } end diff --git a/themes/beaver/assets/css/style.css b/themes/beaver/assets/css/style.css index 81ac43388..e5fbf664e 100644 --- a/themes/beaver/assets/css/style.css +++ b/themes/beaver/assets/css/style.css @@ -590,6 +590,155 @@ input[type=submit]:disabled { margin-bottom: 0; } +/* Worksheet cards — fill-in form treatment for course companion worksheets. + Use as
    blocks in content markdown. Route colors are + semantic: green = advance to the next question, purple = terminal path + assignment (the worksheet's output). Red stays reserved for insight + blockquotes so the five stacked cards don't shout. */ +.blog .ws-card { + background: #faf7f2; + border: 2px solid #2b2b2b; + border-radius: 14px; + padding: 22px 28px; + margin: 24px 0 40px; +} +.blog .ws-card p { + font-size: 17px; + line-height: 1.55; + margin: 0 0 12px; + color: #1a1a2e; +} +.blog .ws-field { + display: flex; + flex-wrap: wrap; + align-items: baseline; + gap: 10px 14px; + margin: 14px 0; + font-size: 17px; +} +.blog .ws-flabel { + font-weight: 600; + color: #1a1a2e; +} +.blog .ws-blank { + flex: 1 1 140px; + min-width: 110px; + border-bottom: 2px dotted #8b8578; + height: 1.3em; +} +.blog .ws-card ul.ws-checks { + list-style: none; + margin: 0 0 16px; + padding: 0; +} +.blog .ws-card ul.ws-checks li { + position: relative; + padding-left: 34px; + margin: 10px 0; + font-size: 17px; + line-height: 1.5; + color: #1a1a2e; +} +.blog .ws-card ul.ws-checks li::before { + content: ""; + position: absolute; + left: 2px; + top: 4px; + width: 17px; + height: 17px; + border: 2px solid #444; + border-radius: 4px; + background: #fff; +} +.blog .ws-verdict { + display: flex; + flex-wrap: wrap; + align-items: center; + gap: 10px 26px; + background: #fff; + border: 2px dashed #b9b2a4; + border-radius: 10px; + padding: 12px 18px; + margin: 18px 0; + font-size: 17px; +} +.blog .ws-verdict-stack { + flex-direction: column; + align-items: flex-start; + gap: 8px; +} +.blog .ws-vlabel { + font-weight: 700; + letter-spacing: 0.08em; + font-size: 14px; + text-transform: uppercase; + color: #6b6558; +} +.blog .ws-opt { + display: inline-flex; + align-items: center; + gap: 9px; + color: #1a1a2e; +} +.blog .ws-opt .ws-box { + width: 17px; + height: 17px; + flex: none; + border: 2px solid #444; + border-radius: 4px; + background: #fff; +} +.blog .ws-route { + font-size: 16.5px; + line-height: 1.5; + border-radius: 8px; + padding: 10px 16px; + margin: 10px 0; + color: #1a1a2e; +} +.blog .ws-route p { margin: 0; font-size: 16.5px; } +.blog .ws-route-go { + background: #f0f9f0; + border-left: 5px solid #2e7d32; +} +.blog .ws-route-alt { + background: #fbe9ff; + border-left: 5px solid #a855f7; +} +@media (max-width: 480px) { + .blog .ws-card { padding: 16px 14px; } +} + +/* Course reading typography — course pages only (body.section-course). + Lessons run 3-5K words; the site-wide 22.4px body stretches them past + 15K px tall and shows barely two paragraphs per screen (Gloria Mark: + ~43s attention per screen). 20px/1.65 keeps the approachable size while + fitting ~30% more per screen, restores H3 contrast (26/20 = 1.3x) so + scanning landmarks work, and drops callouts a step (19px) so they read + as asides, not more wall. Blog pages keep the site-wide scale. */ +/* Selectors mirror single-post.css's `.blog article.single-content + .fl-rich-text p` (0,3,2) - anything weaker silently loses to it. */ +.section-course .blog article.single-content .fl-rich-text p, +.section-course .blog article.single-content .fl-rich-text li { + font-size: 20px; + line-height: 1.65; +} +.section-course .blog article.single-content .fl-rich-text li { + margin-bottom: 12px; +} +.section-course .blog article.single-content .fl-rich-text blockquote p { + font-size: 19px; + line-height: 1.6; +} +.section-course .blog article.single-content .fl-rich-text .ws-card p, +.section-course .blog article.single-content .fl-rich-text .ws-card ul.ws-checks li { + font-size: 17px; + line-height: 1.55; +} +.section-course .blog article.single-content .fl-rich-text .ws-route p { + font-size: 16.5px; +} + /* Details/summary — collapsible tool-stack accordion. Summary looks like a clickable heading, details body has standard spacing. */ .blog details { diff --git a/themes/beaver/layouts/_shortcodes/course-stat.html b/themes/beaver/layouts/_shortcodes/course-stat.html index 6a453d517..8a71b50fd 100644 --- a/themes/beaver/layouts/_shortcodes/course-stat.html +++ b/themes/beaver/layouts/_shortcodes/course-stat.html @@ -1,6 +1,6 @@ {{- /* Course stats from the single source data/course_sequence.yaml. Usage in body prose (positional param): - course-stat chapters -> count of sequence entries excluding Chapter 0 + course-stat chapters -> count of sequence entries excluding the Overview course-stat modules -> count of distinct module numbers in the sequence any other key -> looked up in the yaml's `stats:` map (e.g. artifacts) Frontmatter and cover binaries cannot run shortcodes - use near numbers @@ -10,14 +10,14 @@ {{- if eq $key "chapters" -}} {{- $n := 0 -}} {{- range $data.sequence -}} - {{- if ne .module "Chapter 0" -}}{{- $n = add $n 1 -}}{{- end -}} + {{- if ne .module "Overview" -}}{{- $n = add $n 1 -}}{{- end -}} {{- end -}} {{- $n -}} {{- else if eq $key "modules" -}} {{- $mods := slice -}} {{- range $data.sequence -}} - {{- $m := index (findRE `^Chapter (\d+)` .module 1) 0 -}} - {{- if and $m (ne $m "Chapter 0") (not (in $mods $m)) -}}{{- $mods = $mods | append $m -}}{{- end -}} + {{- $m := index (findRE `^Lesson (\d+)` .module 1) 0 -}} + {{- if and $m (not (in $mods $m)) -}}{{- $mods = $mods | append $m -}}{{- end -}} {{- end -}} {{- len $mods -}} {{- else -}} diff --git a/themes/beaver/layouts/baseof.html b/themes/beaver/layouts/baseof.html index 0ea975af0..04ca9cb9f 100644 --- a/themes/beaver/layouts/baseof.html +++ b/themes/beaver/layouts/baseof.html @@ -91,6 +91,16 @@ {{ partialCached "page/site-scripts" . "site-scripts" }} {{ if .Store.Get "features.mermaid" }} + {{/* The house diagram font. Without this, 'Caveat, Patrick Hand, + cursive' resolves to the PLATFORM generic cursive (Apple + Chancery on macOS, varies elsewhere) - a per-visitor identity + lottery caught by the 2026-07-12 M5 design review. Loaded only + on pages that render mermaid. */}} + + +