diff --git a/bin/check-svg-floor b/bin/check-svg-floor new file mode 100755 index 000000000..c32e1f802 --- /dev/null +++ b/bin/check-svg-floor @@ -0,0 +1,41 @@ +#!/usr/bin/env ruby +# frozen_string_literal: true +# +# devx O7: catch course exhibit SVGs whose smallest text renders below the +# 9px mobile legibility floor at a 390px content width. The visual suite masks +# , so under-floor SVGs ship invisibly (the defect the M1-M5 O2 rollout +# fixed). This is the build-time net that stops the next one. +# +# floor: rendered_px = font_viewBox * 390 / viewBox_width >= 9 +# => font_viewBox >= 9 * viewBox_width / 390 +# +# Usage: bin/check-svg-floor [dir] (default: content/course) +# Report-only today (exit 0 with a burn-down list) because ~55 not-yet-converted +# reference/continuation SVGs still fail. Flip REPORT_ONLY=false to make it a +# blocking gate once the whole course is converted. + +REPORT_ONLY = ENV.fetch("SVG_FLOOR_BLOCK", "") != "1" +FLOOR_PX = 9.0 +MOBILE_W = 390.0 +root = ARGV[0] || "content/course" + +fails = [] +Dir.glob(File.join(root, "**", "*.svg")).sort.each do |path| + svg = File.read(path) + vb = svg[/viewBox="[\d.\s]*?([\d.]+)\s+[\d.]+"/, 1] and w = vb.to_f + next unless w && w > 0 + sizes = svg.scan(/font-size:?\s*["']?([\d.]+)/).flatten.map(&:to_f).reject(&:zero?) + next if sizes.empty? + min = sizes.min + rendered = min * MOBILE_W / w + fails << [path, min, w, rendered.round(2)] if rendered < FLOOR_PX +end + +if fails.empty? + puts "svg-floor: all #{Dir.glob(File.join(root, '**', '*.svg')).size} SVGs clear the #{FLOOR_PX}px@#{MOBILE_W.to_i} floor" + exit 0 +end + +puts "svg-floor: #{fails.size} SVG(s) under the #{FLOOR_PX}px@#{MOBILE_W.to_i} floor:" +fails.each { |p, min, w, r| puts format(" %6.2fpx (min-font %g @ viewBox %g) %s", r, min, w, p) } +exit(REPORT_ONLY ? 0 : 1) 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 8df55d78e..4240cb3cb 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 @@ -48,7 +48,7 @@ After this lesson you will be able to: **spot and repair pitch-shaped questions 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. -![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) +![A left-to-right flow: input is your draft questions plus the Lesson 1.1 customer blank; step 1 (Prompts 1-2) has 3 personas answer each question in-character; step 2 (Prompt 3, marked ruby) is Claude's out-of-character diagnosis - where the learning happens; step 3 (Prompts 4-5) sharpens weak questions past-anchored; output is 5-7 sharpened questions plus an Objection Tracker for real interviews](rehearsal-loop.svg) ## Build 3 ICP personas in Claude 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 index 2556b52e7..7c4169c7c 100644 --- 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 @@ -1,93 +1,91 @@ - - 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. + + Three free Claude prompts sharpen the question list before you spend a real interview. + A left-to-right flow. Input: your draft question list plus the customer blank from Lesson 1.1. Step 1 (Prompts 1-2): three ICP personas answer each draft question in-character. Step 2 (Prompt 3, marked ruby): Claude's out-of-character diagnosis of each question - the step where the learning happens. Step 3 (Prompts 4-5): surface objections and rewrite weak questions past-anchored. Output: 5-7 sharpened questions plus an Objection Tracker, ready for real interviews. Basis: a mock-interview rehearsal loop (Teresa Torres, Product Talk). - - + + - - 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) - + + Rehearse before you spend a real interview + Three free Claude prompts sharpen the question list first + + + + INPUT + Draft + Qs + + customer + blank - - - - 1 - PROMPTS 1-2 - Build 3 personas - Test each draft - question - in-character - + + + 1 + Prompts 1-2 + Roleplay + 3 personas + answer each + draft Q - - - - - 2 - PROMPT 3 - Diagnose - Claude's out-of- - character read - on each Q - + + + + 2 + Prompt 3 + Diagnose + Claude reads + each Q out + of character - - - - 3 - PROMPTS 4-5 - Objections + fix - Surface 3 objections. - Rewrite weak Qs - past-anchored - + + + 3 + Prompts 4-5 + Sharpen + Fix weak Qs, + rewrite them + past-anchored + + + + OUTPUT + 5-7 sharp + Qs + + Objection + Tracker - - - - OUTPUT - 5-7 sharpened Qs - + Objection - Tracker - → real interviews + + + + + + - - - - - + + The in-character answer is plausible by default - + the out-of-character read is where you learn. - - The in-character answer is plausible by default - the out-of-character diagnosis is where you learn. + + Basis: a mock-interview rehearsal loop (Teresa Torres, Product Talk) diff --git a/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/channel-fit-canvas.svg b/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/channel-fit-canvas.svg index d52cf47ac..5e0e2b961 100644 --- a/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/channel-fit-canvas.svg +++ b/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/channel-fit-canvas.svg @@ -1,156 +1,98 @@ - - Channel-fit canvas: score each candidate channel 1-3 on four dimensions. Price fit, buyer type, your honest time budget, and interview signal. Total out of 12. Fill one canvas per channel you are considering. - A scoring worksheet with four dimension columns: Price fit (1-3), Buyer type (1-3), Time budget (1-3), Interview signal (1-3), totaling out of 12. Five example channel rows below: LinkedIn DM, Cold email, Slack/ Discord community, Content / SEO, and Personal network. Each row has fill-in score cells. Right side shows the gate: 9+/12 commit, 7-8 pilot your top two, 6 or less re-read transcripts. Bottom callout: the 10 interview transcripts from Module 2 already name the channel - pull them up and look for how they discover tools. + + Score a candidate channel 1-3 on four dimensions out of 12, then let the total pick your move. + A scoring rubric. Four dimension cards each scored 1 to 3: price fit (price versus what the channel buys), buyer type (is your ICP active here), time budget (sustainable pace for four weeks), and interview signal (did interviewees name it). The total out of 12 sets the move: 9 or more out of 12 in green - commit to one full send, reply, follow-up arc; 7 to 8 in amber - pilot your top two for one week; 6 or less in ruby - no fit yet, re-read your transcripts. Note: the signal is already in your 10 interview transcripts - how they discover tools. Basis: score one canvas per candidate channel; the fill-in worksheet is the PDF. - - Channel-fit canvas: score before you send - Fill one canvas per candidate channel. Score 1-3 on each dimension. Total out of 12. - - - - - - - - Channel - - - - - - - - Price fit - price vs what - this channel buys - - Buyer type - is your ICP - active here? - - Time budget - sustainable pace - for 4 weeks? - - Signal - did interviewees - name it? - - Total - out of 12 - - - - LinkedIn DM - InMail or connection note - 1-3 - 1-3 - 1-3 - 1-3 - /12 - - - - Cold email - Gmail + personal first line - 1-3 - 1-3 - 1-3 - 1-3 - /12 - - - - Slack / Discord - where your ICP hangs out - 1-3 - 1-3 - 1-3 - 1-3 - /12 - - - - Content / SEO - blog, YouTube, writing - 1-3 - 1-3 - 1-3 - 1-3 - /12 - - - - Personal network - people who know you - 1-3 - 1-3 - 1-3 - 1-3 - /12 - - - Your score means - - - - - 9+ / 12 - Commit. One full send/reply/ - follow-up arc before you switch. + + + + + + Score a channel out of 12 before you send + Four dimensions, 1-3 each - the total picks your move + + + + + + Price fit + price vs what + it buys + + 1-3 - - - - - 7-8 / 12 - Pilot your top two for 1 week. - Higher reply rate wins. + + + + Buyer type + is your ICP + active here? + + 1-3 - - - - - 6 or less - No channel fits yet. Re-read your - transcripts for missing signal. + + + + Time budget + sustainable + 4 weeks? + + 1-3 - - - - - The real gate: - >=9/12 channel-fit score - + reply rate over 5% + + + + Signal + did interviews + name it? + + 1-3 - - - - Where to find the signal: Your 10 interview transcripts already name the channel. Pull them up and look for - how they discover tools, which channel they came to you through, and what tools they use every day. + + + + + 9+ / 12 + Commit - one full + send / reply / + follow-up arc. + + + + + 7-8 / 12 + Pilot your top + two for 1 week - + higher reply wins. + + + + + 6 or less + No fit yet - + re-read your + transcripts first. + + + + The signal is already in your 10 interview transcripts - how they discover tools. + + + Basis: score one canvas per candidate channel - the fill-in worksheet is the PDF 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 fb29eb8f5..8789605f0 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 @@ -56,7 +56,7 @@ Your 10 interview transcripts from [Module 2](/course/tech-for-non-technical-fou 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. -![Channel-fit canvas: score each candidate channel 1-3 on four dimensions. Five example channels with fill-in cells. Right side: 9+/12 commit, 7-8 pilot, 6 or less re-read transcripts.](channel-fit-canvas.svg) +![Channel-fit rubric: score a candidate channel 1-3 on four dimensions - price fit, buyer type, time budget, interview signal - out of 12. 9+/12 commit, 7-8 pilot your top two, 6 or less re-read transcripts.](channel-fit-canvas.svg) *Prefer paper? Download the canvas PDF and score it with a pen.* 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 c4aec6461..a29df0ba1 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 @@ -99,7 +99,7 @@ Design: Clean, minimal. Dark sidebar, white content area. [YOUR COLOR] accent. N 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." -![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) +![A left-to-right flow: step 1 Paste (open Lovable) drop in the prompt template with placeholders filled; step 2 Reword (say it aloud) swap in the words you heard in interviews; step 3 Test (yourself) click all three screens as if new to the idea; the purple output card is the prototype ready to share as a link to 5 Mom Test interviewees - and the ruby reading warns to stop at three screens, since a fourth turns the prototype into the MVP](prototype-build-strip.svg) > **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. 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 index 15eb5c42f..543a094c3 100644 --- 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 @@ -1,77 +1,81 @@ - - 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. + + Three moves in Lovable turn the prompt template into a shareable 3-screen prototype. + A left-to-right flow. Step 1 Paste (open Lovable): drop in the prompt template with your placeholders filled. Step 2 Reword (say it aloud): swap in the words you heard in interviews. Step 3 Test (yourself): click all three screens as if new to the idea. Output, marked purple: prototype ready, share the link to 5 Mom Test interviewees. The ruby reading: stop at three screens - a fourth turns the prototype into the MVP. Basis: a 3-screen clickable prototype built in Lovable. - - + + - - Build the 3-screen prototype - Three moves in Lovable, then hand the link to 5 interviewees. + + + + + + Build the 3-screen prototype in three moves + Fill the template, match their words, then hand out the link - - - - 1 - Open Lovable - Paste the prompt - template with your - placeholders filled - + + + 1 + Open Lovable + Paste + The prompt + template with + blanks filled - - - - 2 - Read it out loud - Change vocab to - match the words you - heard in interviews - + + + 2 + Say it aloud + Reword + Swap in the + words you + heard aloud - - - - 3 - Test it yourself - Click all 3 screens - as if you've never - seen your idea - + + + 3 + Test yourself + Click + All 3 screens + as if new to + your idea + + + + READY + Share the link + to 5 Mom Test + interviewees - - - - PROTOTYPE READY - Share the link - to 5 of your Mom - Test interviewees + + + + + - - - - + + The constraint is the test - stop at three screens. + A fourth turns the prototype into the MVP. - - The constraint is the test - stop at 3 screens; a 4th is the prototype turning into the MVP. + + Basis: a 3-screen clickable prototype built in Lovable 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 index 44052fc52..ea8a98f19 100644 --- 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 @@ -1,91 +1,64 @@ - - 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. + + From your Lesson 1.1 hypothesis, four steps end in ten booked interviews. + A left-to-right journey tracker on one line. It starts at your hypothesis from Lesson 1.1, then runs four numbered steps: 1 Map - paste your three sentences into Claude; 2 Read - where they already complain (marked ruby, the move most founders skip); 3 List - 30 named people; 4 Write - name their post. It ends at ten interviews booked on the calendar, marked green. Basis: the find-10 outreach journey, hypothesis to booked calls. - - + + - - The find-10 journey - Read where they already complain, then write to those specific people. + + + - - - - Hypothesis - from Lesson 1.1 - your starting - bet - + + Read where they complain, then write + Hypothesis to ten booked interviews, in four steps - - - - - 1 - AI ICP map - paste into - Claude - + + - - - - - 2 - Read the - threads - where they complain - + + Hypothesis + Map + Read + List + Write + 10 booked - - - - - 3 - 30-name - list - named people only - + + + 1 + 2 + 3 + 4 + + - - - - - 4 - Write each - personally - name their post - + + your bet from + Lesson 1.1 + paste 3 lines + into Claude + where they + complain + 30 named + people + name their + post + on the + calendar - - - - 10 interviews - booked - on the - calendar - - - - - - - - + + Basis: the find-10 outreach journey - hypothesis to booked calls 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 cbda88380..4f6840ead 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 @@ -45,7 +45,7 @@ Your LinkedIn network is the comfortable place to start - and it books polite ca 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: -![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) +![A left-to-right journey tracker on one line: your hypothesis from Lesson 1.1, then four steps - 1 Map (paste 3 lines into Claude), 2 Read where they complain (marked ruby, the move most founders skip), 3 List 30 named people, 4 Write naming their post - ending at 10 interviews booked on the calendar, marked green.](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 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. 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 921266950..34e2a31df 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 @@ -77,7 +77,7 @@ Teresa Torres names three reasons a stranger turns down an interview ask, and th 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. -![The honest outreach funnel for one batch of 30 - sent, replied at 20-30%, and 2-3 booked calls, with a warning callout for reply rates under 10%](outreach-funnel-strip.svg) +![A three-stage funnel for one batch of 30: SENT 30 by hand, a 20-30% reply rate to REPLIED ~7, a ~50%+ show rate to BOOKED 2-3 (green), then a guardrail reading the reply rate - under 10% rewrite the opener (ruby), 10-20% workable (amber), 20-30% the reference line is landing (green)](outreach-funnel-strip.svg) **Success check:** every subject line in your sent folder names a post the person wrote, replies run 20% or better, and 2-3 calls from the batch are on your calendar. Then stack batches until 10 calls are on the calendar - Done below fires at 10, not at the first batch. diff --git a/content/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/outreach-funnel-strip.svg b/content/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/outreach-funnel-strip.svg index f6ce44eee..07dbe526c 100644 --- a/content/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/outreach-funnel-strip.svg +++ b/content/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/outreach-funnel-strip.svg @@ -1,53 +1,63 @@ - - The honest outreach funnel - 30 sent messages down to booked calls + + One batch of 30 hand-sent messages funnels to 2-3 booked calls. + A three-stage outreach funnel for one batch. SENT 30, by hand, staggered. A 20-30% reply rate leads to REPLIED about 7, where a named post earns the reply. A roughly 50%-or-more show rate leads to BOOKED 2-3 calls, marked green - stack batches to reach 10. A guardrail strip reads the reply rate: under 10% means rewrite the opener (ruby), 10-20% is workable (amber), 20-30% means the reference line is landing (green). Basis: one 30-message batch, replies over page views. - - + + - The honest outreach funnel, one batch - 30 staggered by hand - not a single bulk-send. - - - - SENT - 30 - by hand, staggered - - - 20-30% - - - - REPLIED - ~7 - named post = replies - - - ~50%+ - - - - BOOKED - 2-3 - stack batches to 10 - - - - Under 10% replies? The opener is too generic - rewrite it. - 10-20% is workable. 20-30% means the reference line is landing. + + + + + + Thirty hand-sent messages, 2-3 booked calls + Reply rate is the dial - under 10% means rewrite the opener + + + + SENT + 30 + by hand, staggered + + + REPLIED + ~7 + named post = replies + + + BOOKED + 2-3 + stack batches to 10 + + + + + 20-30% + + + + ~50%+ + + + + Under 10% replies? The opener is too generic - rewrite it. + 10-20% is workable. 20-30% means the reference line is landing. + + + Basis: one 30-message batch - replies staggered by hand, not bulk-sent 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 0fc35c90e..fd592ce53 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 @@ -61,7 +61,7 @@ Open a Google Sheet. Six columns: Name, Company, Role, Bucket, Relationship stre | Warm | 15 | Adjacent. Knew you 6-24 months ago. Reasonable bet they have the problem. | | Cold | 20 | Dormant LinkedIn 1st-degree. Unclear if they have the problem. | -![The 4-bucket grid - how 50 names get sorted before the first message goes out](network-buckets.svg) +![Four numbered buckets sorting 50 names by warmth - 5 champions, 10 hot, 15 warm, 20 cold - sent in that order, champions first](network-buckets.svg) > **First, count your network.** Filter your 1st-degree LinkedIn connections by your must-have segment from Lesson 5.1 (title + company size + industry). > 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 90a7ca5da..461be3eba 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 @@ -1,56 +1,75 @@ - - The 50-name network list sorted into 4 outreach buckets + + Sort 50 names into four priority buckets and send in order, champions first. + Four numbered bucket cards. 1 Champions, 5 names - already complained to you about this problem. 2 Hot, 10 names - your must-have segment, knows you, last contact under six months. 3 Warm, 15 names - adjacent, knew you six to 24 months ago. 4 Cold, 20 names - dormant first-degree connections, unclear if they have the problem. A send-order strip reads champions, then hot, then warm, then cold, 50 names total. Basis: people who already know you - your Module 2 interviewees, smoke-test signups, and first-degree network. - The 50-name network list, sorted - Send Monday in this order. Champions before hot. Hot before warm. Cold is the last 20. + + + - - - CHAMPIONS (5) - 5 names - Already complained about this problem to you. - Will pick up your call. Will refer 2 more. - Send Monday 9 AM. Personalized Loom each. + + Sort 50 names, champions first + Rank by who already knows you - send in this order - - - HOT (10) - 10 names - In the must-have segment from 5.1. - Knows you personally (recent contact <6 mo). - Send Monday afternoon. Loom + Calendly link. + + + + + + 1 + Champions + 5 names + Already complained to you + about this exact problem. + + + + + + 2 + Hot + 10 names + Must-have segment, knows you, + last contact under 6 months. + + + + + + 3 + Warm + 15 names + Adjacent. Knew you 6-24 + months ago. + + + + + + 4 + Cold + 20 names + Dormant 1st-degree. Unclear + if they have the problem. + - - - WARM (15) - 15 names - Adjacent. Knew you 6-24 months ago. - Reasonable bet they have the problem. - Send Tuesday. Template OK, name-personalized opener. + + + Send in order: Champions → Hot → Warm → Cold · 50 total - - - COLD (20) - 20 names - Dormant LinkedIn 1st-degree. - Unclear if they have the problem. - Send Thursday. Hold the bottom 5 for week 2. - - - - 50 messages out by Friday EOD. - Founders consistently get 3-5 pilot conversations from this list. Champions deliver 60-70% of the early conversions. + + Basis: people who already know you - your interviewees, signups, and network diff --git a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/index.md b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/index.md index c3d98387e..db2bbef8f 100644 --- a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/index.md +++ b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/index.md @@ -52,7 +52,7 @@ Every message follows the same 4-part structure. What changes by bucket is the o | **Warm** | "Hey [NAME], have not caught up since [the last specific touchpoint]. Working on something I think you might have a take on." | | **Cold** | "Hey [NAME], a true one-line reference ('we were both in the Acme batch')." | -![A fill-in worksheet with columns for name, last contact, and warm-intro path, plus an example row and 7 blank rows to audit your first 8 names before writing openers](network-audit-grid.svg) +![An audit table with columns for name, last contact, and warm-intro path plus a worked example row, and the rule that recent contact runs a hot opener, 6-24 months a warm opener, and no path means cold or drop](network-audit-grid.svg) If no real reference exists for a cold-bucket name, move them to [Lesson 5.7 cold outbound](/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/) instead. diff --git a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/network-audit-grid.svg b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/network-audit-grid.svg index 1e0aa5add..e268bfa72 100644 --- a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/network-audit-grid.svg +++ b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/network-audit-grid.svg @@ -1,79 +1,75 @@ - - Fill-in worksheet - audit your first 8 names before writing openers + + Audit three facts per name, then let the last contact pick the opener's warmth. + A short audit table with three columns - name, last contact, and warm-intro path - a worked example row (Jordan T., 3 months ago on LinkedIn, via Casey - champion #2) and two blank rows to fill for your first eight names. Below, three mapping cards turn the last-contact date into an opener: recent contact runs a hot opener, six to 24 months runs a warm opener, and no path means cold or drop (in ruby). Basis: your first 8 names - recency of contact sets the opener's warmth. - Audit your first 8, before you write - The facts every bracket in your opener needs. + + + - + + Audit three facts before you write + Last contact picks the opener - recent runs hot + + - NAME - LAST CONTACT - WARM-INTRO PATH + Name + Last contact + Warm-intro path + + + + + + + + Jordan T. (ex.) + 3 months ago, LinkedIn + via Casey, champ #2 + + 2. + + + + 3. + + + - - - + + + + + Recent + Hot opener + + + + + 6-24 months + Warm opener + + + + + No path + Cold, or drop + - - - 1. - Jordan T. (example) - 3 months ago, LinkedIn - via Casey - champion #2 - - - 2. - - - - - 3. - - - - - 4. - - - - - 5. - - - - - 6. - - - - - 7. - - - - - 8. - - - - - - - Recent contact = hot opener. 6-24 months = warm. No path = cold, or drop them. + + Basis: your first 8 names - recency of contact sets the opener's warmth diff --git a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-send-track/send-day-rhythm-card.svg b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-send-track/send-day-rhythm-card.svg index b47dccb17..e106e6295 100644 --- a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-send-track/send-day-rhythm-card.svg +++ b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-send-track/send-day-rhythm-card.svg @@ -1,47 +1,67 @@ - - The send-day rhythm - champions and hot today, warm next, cold last + + Send the warm buckets over three days, oldest relationship first, then read the reply gate. + Three numbered day cards. Day 1: champions (5) plus hot (10), send today with the same Loom link. Day 2-3: warm (15), once Day 1 replies land. Day 4+: cold (20), once early replies settle. A green gate card reads: 10 or more replies logged and 3 to 5 demos booked; expect 15 to 25 replies from 50; fewer than 5 replies means tighten the opener before the next batch. Basis: 50 warm-network messages, sent oldest-relationship first. - The send-day rhythm - A daily handful, oldest relationship first - track every reply. + + + - - - DAY 1 - Champions (5) + Hot (10) - Send today - LinkedIn DM - or Gmail, same Loom link. + + Send champions first, cold last + A daily handful, oldest relationship first - - - DAY 2-3 - Warm (15) - Send once Day 1 is out - and the first replies land. + + + + + + 1 + Day 1 + Champions 5 + Hot 10 + Send today, + same Loom link. + + + + + + 2 + Day 2-3 + Warm 15 + Once Day 1 + replies land. + + + + + + 3 + Day 4+ + Cold 20 + Once early + replies settle. + - - - DAY 4+ - Cold (20) - Send once early replies - settle in from Day 1-3. + + + Gate: 10+ replies logged, 3-5 demos booked + Expect 15-25 replies from 50. Fewer than 5? Tighten the opener first. - - - Gate: 10+ replies logged, 3-5 demos booked. - Fewer than 5 replies? Tighten the opener before the next batch goes out. + + Basis: 50 warm-network messages, sent oldest-relationship first 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 index b35021af5..534c71d22 100644 --- 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 @@ -1,150 +1,139 @@ - - 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: four checks - GitHub org owner, AWS root with MFA, prod DB password access, and WHOIS - any fail drops into one fix lane, starts a recovery clock, then forks on whether the contractor cooperates. + Four check cards in a two-by-two grid. Code - are you the GitHub org Owner; pass if it is your email, not the agency's. Cloud - is the AWS root email yours with MFA; pass if root is on your domain with MFA on. Secrets - can you read the prod DB password solo; pass if it comes from your own vault with no asking. Domain - does WHOIS list your name; pass if it is your name and your renewal email. Any fail drops into one shared amber fix lane: Slack the lead for an org transfer, self-serve email change or AWS recovery, add a 1Password vault this sprint, registrar move plus ICANN if blocked. All 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 for cloud? Yes routes to a green card: audit clean, recheck quarterly, email the board. No routes to a ruby card: retain a lawyer, 2 to 5 thousand dollars beats a stalled exit. - - + + - - 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 + + + + + + Four checks decide who owns your product + Any fail - fix it in one lane, then start the recovery clock + + + + + + 1 + Code + Are you the GitHub org Owner? + Pass: your email, not the agency - - - - 2 - Cloud - AWS root yours + MFA? - Root on your domain, - MFA on + + + + + 2 + Cloud + Is AWS root yours, with MFA? + Pass: root on your domain + MFA - - - - 3 - Secrets - Read prod DB pw solo? - From your vault, - no asking + + + + + 3 + Secrets + Read the prod DB password solo? + Pass: from your vault, no asking - - - - 4 - Domain - WHOIS shows you? - Your name + your - renewal email + + + + + 4 + Domain + Does WHOIS list your name? + Pass: your name + 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 + + + + + + + If a check fails, fix it right here + + + + Slack the lead + for org transfer + Self-serve email + or AWS recovery + Add a 1Password + vault this sprint + Registrar move + + ICANN if stuck - - - - - + + - - - - Recovery plan started this Friday + + + + Recovery plan started this Friday - - + + - - - - Did the contractor cooperate? - 7 days for code · 14 days for cloud + + + + Did the contractor cooperate? + 7 days for code, 14 for cloud - - - - Yes - No - - - - - Audit clean - Quarterly recurring block. Email investor / board. + + + + Yes + No + + + + + Audit clean + Recheck quarterly; email board - - - - Retain a lawyer - $2K-$5K beats a stalled checkout. + + + + Retain a lawyer + $2K-$5K beats a stalled exit + + + Basis: a Friday afternoon ownership audit - run it before the checkout stalls 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 80aa02f47..98d60a79d 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 @@ -45,7 +45,7 @@ After this lesson you will be able to: **write interview questions that ask abou 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) +![Five stacked question cards - last-time, cost, workaround, priority, buying-committee. Each names the question, the wording to read aloud, a green PASS tell for real demand, and a ruby FAIL tell for the polite noise to reject.](mom-test-script.svg) ## The 5 questions diff --git a/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/mom-test-script.svg b/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/mom-test-script.svg index 77eb1bb8a..e9d9809b6 100644 --- a/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/mom-test-script.svg +++ b/content/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/mom-test-script.svg @@ -1,74 +1,79 @@ - - The Mom Test 5-question script - past-behavior interview questions - Card 1 last-time question. Card 2 cost in time money sanity. Card 3 what have you tried already. Card 4 1-10 priority. Card 5 who else on your team. + + Five past-behavior questions, each with a real-demand tell and a polite-noise tell. + Five stacked question cards read as an interview script. Each card names the question type, gives the wording to read aloud, then a PASS tell in green for what real demand sounds like and a FAIL tell in ruby for the polite noise to reject. Q1 the last-time question, Q2 the cost question, Q3 the workaround question, Q4 the priority question, Q5 the buying-committee question. Basis: The Mom Test by Rob Fitzpatrick, 2013 - a past-behavior interview script. - - - - + + + - The Mom Test interview script - 5 questions, read as written. - Anchors in past behavior. Listens for emotional language. Scores 1-10. + + Ask about the last time, never the future + Five questions - each answer is real demand or polite noise - - Q1 - The last-time question - "Tell me about the last time [problem] happened. Walk me through what you did." - PASS: A date, a time, a tool, a person. "Last Tuesday 9pm I called my CFO..." - FAIL: "Yeah I usually struggle with this." No date, no story. - - + + 1 + The last-time question + "Tell me about the last time [problem] happened. Walk me through what you did." + PASS + A date, a tool, a person. "Last Tuesday 9pm I called my CFO." + FAIL + "I usually struggle with this." No date, no story. - - Q2 - The cost question - "What did that cost you - in time, money, or sanity?" - PASS: A number with a unit. "2 hours every Tuesday for 6 months." "$800 in CFO time." - FAIL: "It costs us time." Unquantified. Polite about an unfelt problem. - - + + 2 + The cost question + "What did that cost you - in time, money, or sanity?" + PASS + A number with a unit. "2 hours every Tuesday." "$800 in CFO time." + FAIL + "It costs us time." Unquantified - polite about an unfelt problem. - - Q3 - The workaround question - "What have you tried already to fix this?" - PASS: A named tool or hired person. "I pay Zapier $79/mo. My VA fixes it weekly." - FAIL: "Nothing yet." "We just deal with it." No workaround = no urgency. - - + + 3 + The workaround question + "What have you tried already to fix this?" + PASS + A named tool or hire. "I pay Zapier $79/mo. My VA fixes it weekly." + FAIL + "Nothing yet." "We just deal with it." No workaround = no urgency. - - Q4 - The priority question - "On a 1-10 scale, how big is this compared to everything else on your plate?" - PASS: 7+ with a comparison. "This is 8. Only hiring is higher." - FAIL: A polite 7 with no comparison. "Probably a 7." Default kindness, not urgency. - - + + 4 + The priority question + "On a 1-10 scale, how big is this next to everything else on your plate?" + PASS + 7+ with a comparison. "It's an 8 - only hiring is higher." + FAIL + A polite "probably a 7" with no comparison. Default kindness. - - Q5 - The buying-committee question - "Who else on your team feels this? How do they handle it?" - PASS: Names a colleague + their workaround. "Jess keeps a parallel sheet she trusts more." - FAIL: "Just me." Either small/local or they don't know how the team works. + + 5 + The buying-committee question + "Who else on your team feels this? How do they handle it?" + PASS + Names a colleague + their workaround. "Jess keeps a parallel sheet." + FAIL + "Just me." Small and local, or they don't know how the team works. + + + Basis: The Mom Test (Rob Fitzpatrick, 2013) - a past-behavior interview script 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 a347fde4e..37c2c47bf 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 @@ -51,7 +51,7 @@ Would your first users be disappointed if your product disappeared tomorrow? Fiv 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). -![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) +![Horizontal signal meter of the share of first users answering very disappointed: amber under the 40% line means product problem, green at 40% or more means a must-have user](sean-ellis-gauge.svg) 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). 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 b48f6d741..63f2e5885 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,64 +1,62 @@ - - 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. + + At 40% very-disappointed the product is a must-have: read the share of your first users against the 40% line. + A horizontal signal meter reading 0 to 100 percent of first users who answer "very disappointed" if the product vanished. Under 40 percent is amber - a product problem no ad budget fixes. 40 percent or more is green - a must-have user, go sell. A ruby line and pointer mark the 40 percent go line. Axis ticks at 0, 40, and 100 percent. Basis: share answering "very disappointed" to "How would you feel if you could no longer use it?", 10 to 30 recent users, the Sean Ellis test. + - - "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. + + + + + + 40% who'd miss it = a must-have + Survey your first users before you buy traffic + + + + 40% = the line + must-have, start selling + + + + + + + + + + + Under 40% + Product problem + 40% or more + Must-have user, go sell + + + + + + + + 0% + 100% + + + + 40% + + + Basis: "very disappointed" share among 10-30 recent users - the Sean Ellis test 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 178750d05..4ce1383ef 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 @@ -45,7 +45,7 @@ After this lesson you will be able to: **write a one-page Product Brief that nam 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. -![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) +![One-page Vibe PRD: five stacked section cards you fill in a single 90-minute sitting. 1 The problem - copy the validated problem statement verbatim. 2 The user and their context - who they are and the 60 seconds before and after. 3 What you're building - the smallest end-to-end thing in plain English. 4 Success metric - one number, unit, and timeframe plus the event that measures it. 5 What you're NOT building - 5-8 lines the builder would add unprompted; a longer no-go list means a cheaper build.](vibe-prd-template-visual.svg) ## The 5-section 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 4b1337393..834d2bcc6 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,81 +1,64 @@ - - 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. + + The one-page Vibe PRD: five sections you fill in one 90-minute sitting, then hand to the builder. + Five stacked section cards make a one-page product brief. Section 1 the problem - copy the validated problem statement verbatim. Section 2 the user and context - who they are and the 60 seconds before and after using it. Section 3 what you are building - the smallest end-to-end thing in plain English. Section 4 the success metric - one number, unit, and timeframe, plus the event that measures it. Section 5 what you are NOT building - five to eight lines the builder would add unprompted; a longer no-go list means a cheaper build. Basis: one page, filled in a single 90-minute sitting. - + + + - - - - - - - - - - Vibe PRD - One-Page Product Brief - One 90-minute sitting. Hand to Lovable, Cursor, or a hired junior. - - + + One page, five sections, hand it off + One 90-minute sitting - then hand it to the builder - 1. - The problem (copy from Lesson 2.5) - Persona + industry + dated sample + verbatim quote + cost. - _______________________________________________________ - _______________________________________________________ - Inherit word-for-word from the validated problem statement. Don't paraphrase. - - + + 1 + The problem + Copy the validated problem statement verbatim - don't paraphrase. + e.g. persona + industry + dated sample + a quote + the cost. - - 2. - The user and their context - Who they are while using your product: __________________ - 60 seconds before reaching for it: ______________________ - 60 seconds after they close it: _________________________ - e.g., "Founder alone at 9pm, two finance tabs open, wants done in 10 min." - - + + + 2 + The user and their context + Who they are, and the 60 seconds before and after they use it. + e.g. "Founder alone at 9pm, two finance tabs open, wants 10 min." - 3. - What you're building (one paragraph) - Smallest end-to-end thing the user can do: ______________ - Inputs they provide + output they get back: _____________ - What v1 explicitly supports (scope of done): ____________ - e.g., "Paste Stripe CSV. Get QuickBooks CSV back. USD only. Magic-link auth." - - + + 3 + What you're building + The smallest end-to-end thing the user can do, in plain English. + e.g. paste a Stripe CSV, get a QuickBooks CSV back. USD only. - 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." - - + + 4 + Success metric (one number) + One number + unit + timeframe, and the event that measures it. + e.g. 10 of first 20 signups convert in 30 days. Event: conversion_completed. - 5. - What you're NOT building (the no-go list) - 5-8 lines of things the agent or contractor will add unprompted: - _______________________________________________________ - Longer list = cheaper build + + 5 + What you're NOT building + 5-8 lines the builder would add unprompted - list them to block them. + A longer no-go list means a smaller, cheaper build. + + + Basis: one page, filled in a single 90-minute sitting - hand to Lovable, Cursor, or a junior dev 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 6027b780c..f1d40fdab 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,72 +1,69 @@ - - 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. + + Product Hunt is a one-day event; the job needs sustained motion - two separate metrics, not one axis. + Two separate stat cards. Left, Product Hunt in ruby: 3.1 percent per launch event, 387 launches studied, 89 percent of founders would not launch again, drawn as a single one-day spike. Right, Indie Hackers in green: 23.1 percent per engaged post, written as engagement not a launch, drawn as sustained repeated motion. Note: Product Hunt is not bad - it is a one-day event in a job that needs sustained motion over a quarter. Basis: OpenHunts 2024 - 387 launches, 156 founders surveyed; separate metrics, shown separately. - + + + - Two channels. Two different jobs. - OpenHunts 2024 - 387 launches, 156 founders surveyed. Separate metrics, shown separately. + + Two channels, two different jobs + Product Hunt is a one-day event; the job needs motion - - - - - PRODUCT HUNT - - 3.1% - per launch event - - 387 launches studied - 89% said they would not launch again - - - - - - one-day spike + + + Product Hunt + 3.1% + per launch event + 387 launches studied + 89% would not launch again + + + + + one-day spike - - - - - INDIE HACKERS - - 23.1% - per engaged post - - Written as engagement, - not a launch announcement - - - - - - - - - - - sustained motion + + + 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. + The job needs sustained motion over a quarter. - - - Product Hunt is not bad - it is a one-day event in a job that needs sustained motion over a quarter. + + Basis: OpenHunts 2024 - 387 launches, 156 founders surveyed; separate metrics 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 c18b1e77a..9a2d0d3c3 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 @@ -1,50 +1,54 @@ - - Why free pilots ghost and paid pilots convert - the skin-in-the-game gap + + A paid deposit converts far more pilots than a free one - same product, buyer, and eight weeks. + A two-bar comparison of the share of pilots that convert to paying. The free pilot bar is short in ruby - about 12 percent convert. The paid pilot bar is tall in green - about 65 percent convert. Same product, same buyer, same eight weeks; the deposit is the only change. Deposit terms: $500 or more, 10 to 30 percent of year-one ACV, charged before kickoff. If the customer cancels early the deposit is forfeited; if you cancel you refund 100 percent. Basis: illustrative convert-to-paying rates; the deposit is the only variable, not the product or the buyer. - Free pilot vs paid pilot - what skin in the game does - Illustrative from 4 founders we worked with who ran both motions in 2026. Your numbers will vary. - - - - FREE PILOT - 12% - convert to paying - Customer never had to defend the spend. - "This is great" emails on Friday, - ghost on conversion in week 8. - Average pilot length: 6-8 weeks. - Average founder hours: 25-40. - Average revenue: $0. - "It is great. Let me circle back next quarter." - - - - PAID PILOT ($500-$6K deposit) - 65% - convert to paying - Customer defended the spend internally. - CFO or boss already approved. - Conversion is paperwork, not a new decision. - Average pilot length: 6-8 weeks. - Average founder hours: 25-40. - Average revenue: $500-$6K + annual. - "Ship the year-one invoice next week." - - - - Same product. Same customer. Same eight weeks. The deposit is the variable. + + + + + + Charge a deposit and pilots convert + Same product, buyer, and 8 weeks - the deposit is the change + + + + + + + + + 12% + 65% + + + + + + Free pilot + convert to paying + Paid pilot + convert to paying + + + + Deposit: $500+, 10-30% of year-one ACV, charged before kickoff. + Customer cancels early: forfeited. You cancel: 100% refund. + + + Basis: illustrative convert-to-paying rates - the deposit is the only variable diff --git a/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/index.md b/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/index.md index 1e70e9f9c..b357fb813 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 @@ -58,7 +58,7 @@ Same product, same buyer, one difference - when the money lands: 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) +![Two bars comparing convert-to-paying: free pilot about 12% in ruby, paid pilot about 65% in green - same product, buyer, and 8 weeks; deposit is $500+ (10-30% of year-one ACV), forfeited if the customer cancels early, 100% refunded if you cancel](free-vs-paid-pilot.svg) > **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. 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 index 22dd28aae..7e2733191 100644 --- 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 @@ -1,81 +1,89 @@ - - 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 build phases, each proven by one demo, then a five-green-lights gate that advances you to Module 5. + Four numbered phase cards in a row. Phase 1 Lovable - screens click, nothing saved. Phase 2 Supabase - a real signup persists. Phase 3 Stripe - a one-dollar test charge flips the row to paid. Phase 4 go live - five ICP users hit the live URL. An arrow drops into a wide green gate card listing five exit lights: Stripe in live mode, custom domain wired, one fresh ICP user hit the paywall, zero JS errors at checkout, a weekly demo recording exists. Any light red means fix it first. All five green advances to Module 5. Basis: the self-serve MVP build - one demo is the proof of each phase. - - + + - 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 + + Four phases, then five green lights + One demo per phase - the demo is the proof, not the screens + + + + + + 1 + Lovable + Screens click, + nothing saved - - - - 2 - Supabase + auth - A real signup - persists on refresh + + + + 2 + Supabase + A real signup + persists - - - - 3 - Stripe checkout - A $1 test charge - flips the row to paid + + + + 3 + Stripe + $1 test charge + flips to paid - - - - 4 - Go live - 5 ICP users click - the live URL + + + + 4 + Go live + 5 ICP users + hit 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. - + + + All 5 lights green - advance to Module 5 + + ✓ Stripe in LIVE mode + ✓ Custom domain wired + ✓ Fresh ICP user hit the paywall + + ✓ Zero JS errors at checkout + ✓ Weekly demo recording exists + Any light red - fix it first, re-check. + + + Basis: the self-serve MVP build - one demo proves each phase 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 fd572a9e8..ee96969ba 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 @@ -48,7 +48,7 @@ You validated the problem in Modules 1-3 and set up the stack in Lesson 4.3. Wha > → **Mia walked the four phases** over three weekends. Her spouse signed up in Phase 2. By Phase 4, five parents clicked through the live URL. [Full walkthrough →](/course/tech-for-non-technical-founders-2026/module-4-walkthrough-mia/) -![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) +![Four build phases, each proven by one demo, then the five-green-lights gate. Phase 1 Lovable - screens click, nothing saved. Phase 2 Supabase - a real signup persists. Phase 3 Stripe - a $1 test charge flips the row to paid. Phase 4 go live - 5 ICP users hit the live URL. An arrow drops into a green gate listing five exit lights: Stripe in live mode, custom domain wired, one fresh ICP user hit the paywall, zero JS errors at checkout, a weekly demo recording exists. All five green advances you to Module 5.](build-phases-strip.svg) ## The ship plan 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 e4cb939b2..f88f24f6e 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 @@ -62,7 +62,7 @@ If you completed Modules 1-3, your default Module 4 path is to build it yourself 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. -![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) +![Three tools, one job each. Lovable is the UI layer - it draws the screens and sends form data down. Supabase is the data and auth layer - it stores your data and holds the login. Stripe, drawn in green as the money layer, charges the card and confirms who paid. A data arrow runs Lovable to Supabase, a pay arrow Supabase to Stripe, and a dashed Stripe webhook loops back to Supabase to tell it the customer is paid.](stack-boundaries.svg) 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. 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 index 224460adb..80400233d 100644 --- 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 @@ -1,72 +1,74 @@ - - 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, one job each: Lovable draws the screens, Supabase stores the data and login, Stripe charges the card, and a Stripe webhook loops back to tell Supabase who paid. + Three cards in a row. Left, Lovable, the UI layer - draws the screens and sends form data down. Middle, Supabase, the data and auth layer - stores your data and holds the login. Right, Stripe, drawn in green as the money layer - charges the card and confirms who paid. A "data" arrow runs from Lovable to Supabase, a "pay" arrow from Supabase to Stripe, and a dashed webhook arrow loops back from Stripe to Supabase to tell it the customer is paid. Basis: the self-serve MVP stack - Lovable UI, Supabase data, Stripe payments. - - + + - - + + - 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 - + + Three tools, one job each + Each owns one job - a webhook loops the payment back - - - - Supabase - the data + auth layer - - Stores the users, rows, files - Holds the login - + + + Lovable + the UI layer + + Draws the screens + Sends form data - - - - Stripe - the money layer - - Charges the card - Confirms who paid - + + + Supabase + data + auth layer + + Stores your data + Holds the login - - data - - pay - + + + Stripe + the money layer + + Charges the card + Confirms who paid - - - Stripe webhook: tells Supabase the customer is paid. + + + + data + + + + pay + + + + Stripe webhook - tells Supabase the customer is paid + + + Basis: the self-serve MVP stack - Lovable UI, Supabase data, Stripe payments diff --git a/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/admin-panel-spaceship.svg b/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/admin-panel-spaceship.svg index 1d2bd22e0..ce5c4b1fe 100644 --- a/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/admin-panel-spaceship.svg +++ b/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/admin-panel-spaceship.svg @@ -1,132 +1,89 @@ - - The simple-admin-panel-to-spaceship anti-pattern, sketched. - A hand-drawn sketch with two panels. Left: a small admin panel mockup with three buttons (hide post, ban user, refund). A small label reads "What you asked for." Right: a giant control deck panel covered in 47 buttons, a role-permissions matrix, audit log, feature flags, multi-tenant switcher, and a co-pilot AI assistant. A label reads "What got built." A wavy arrow connects the two with the words "10-week build, $15K" along it. + + Ask for "a simple admin panel" and a vague brief comes back as a 10-week, $15K spaceship of 47 buttons. + A two-panel comparison. Left, "What you asked for" - a small admin panel with three buttons: hide this post, ban this user, refund this charge; 3 buttons, 2 days of work. A ruby arrow labeled 10 weeks, $15,000 crosses to the right. Right, "What got built", outlined in ruby - a dense control deck of tab and button motifs with the tally 5 tabs, 47 buttons, 1 role matrix, 12 feature flags, 1 AI co-pilot, and the note that only 2 of these get used. Basis: a vague scope lets the builder fill the gap with features you never asked for. - - + + - - - "A simple admin panel" → the spaceship that arrives 10 weeks later - - - What you asked for - - - Admin - - - - Hide this post - - - Ban this user - - - Refund this charge - - 3 buttons - 2 days of work - The one job you - actually had on Tuesday - - - - 10-week build · $15,000 - "interpreted the brief" - - - What got built - - - Admin Control Center v1.0 - - - - - Users - - Roles - - Audit - - Flags - - - Role × Permission matrix - - - - - - - - - - - - + + + + + + "A simple admin panel" arrives as a spaceship + Vague scope - the builder fills the gap with 47 buttons + + + What you asked for + What got built + + + + + 10 weeks - $15,000 + + + + Admin + + + Hide this post + + Ban this user + + Refund this charge + 3 buttons - 2 days of work + + + + Admin Control Center + + + + + + + - - - Quick actions - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + - (47 of them, mostly broken) - - - - Multi-tenant org switcher ▾ - - - 🤖 AI co-pilot · "Ask me anything" + 5 tabs, 47 buttons, 1 role matrix + 12 feature flags, 1 AI co-pilot + 2 of these you actually use - 5 tabs · 47 buttons · 1 role matrix - 12 feature flags · 1 AI co-pilot - 2 of these you actually use. + + Basis: a vague scope lets the builder add features you never asked for 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 95061c437..64b75929e 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 @@ -45,7 +45,7 @@ After this lesson you will be able to: **rewrite every feature noun in Section 3 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) +![A two-panel comparison. Left, "What you asked for" - a simple admin panel with three buttons: hide this post, ban this user, refund this charge; 3 buttons, 2 days of work. A ruby arrow labeled 10 weeks, $15,000 crosses to the right. Right, "What got built" outlined in ruby - a dense control deck of tab and button motifs tallying 5 tabs, 47 buttons, 1 role matrix, 12 feature flags, 1 AI co-pilot, of which only 2 get used.](admin-panel-spaceship.svg) ## Why feature briefs overbuild diff --git a/docs/20-29-testing-qa/screenshot-testing/20.10-visual-suite-speed-research-reference.md b/docs/20-29-testing-qa/screenshot-testing/20.10-visual-suite-speed-research-reference.md index 50e3e2715..376bb0955 100644 --- a/docs/20-29-testing-qa/screenshot-testing/20.10-visual-suite-speed-research-reference.md +++ b/docs/20-29-testing-qa/screenshot-testing/20.10-visual-suite-speed-research-reference.md @@ -172,6 +172,7 @@ shift), `blockquote` on course/chapter (system-font, not a font-swap; verified fixes: mount the worktree's gitdir into the container, or make bin/dtest refuse to run when `.git` is a file (guard + clear message). +- **O7b — SVG legibility-floor check — ✅ DONE 2026-08-01 (M2-M5 rollout 20%-slot).** `bin/check-svg-floor` flags course SVGs whose smallest text renders <9px@390 (viewBox-W vs min-font). Report-only (SVG_FLOOR_BLOCK=1 to make it blocking); flips to a build gate once the deferred ~46 convert. Confirmed: all 17 rollout + 6 M1 SVGs clear; 46 reference/walkthrough SVGs remain (the deferred-wave burn-down). - **O7 — banned-strings validator net gap (found W2-T7, 2026-08-01).** `check_banned_strings` (lib/course_validators.rb:369) scans only pages with `course_chapter: true` - walkthroughs (no flag), `smoke-test-build-page`