🚀 pitch¶

Go-to-market launch engine. Use when converting a validated offer spec into ready-to-execute landing page copy, launch posts, GitHub README, email sequence, launch checklist, A/B test spec, and kill criteria.

License: MIT | Security: INFO (1)

Install¶

brunnr install pitch

Tags: Hunter Pipeline

Security Scan¶

INFO — 1 finding(s)

Minor informational findings that don't affect installation.

View findings

Threat Class	Severity	Description	Line
`semantic_mismatch`	INFO	URL to non-allowlisted domain: launchpad-git-{product-slug}-kwayet-fs-projects.vercel.app	466

File Info¶

Property	Value
Path	`skills/pitch/SKILL.md`
Size	28.1 KB
SHA-256	`577b81d94cb04be9248da0e712fe2a61f033ce488a0eb4b39db54e82456d98ae`
README	`skills/pitch/README.md`

Skill Prompt¶

Pitch¶

Transform an offer-scope build spec into a complete go-to-market launch kit. Produces ready-to-execute landing page copy, platform-specific launch posts, a GitHub product README (with product structure sketch for technical domains), a post-purchase email sequence, an hour-by-hour launch checklist, an A/B test spec, and refined kill criteria -- all grounded in persona data, SWOT findings, and offer-scope positioning.

Step 0: Load Conventions¶

Before doing ANYTHING, read the shared conventions file:

Read ${SKILLS_DIR}/_conventions.md

This file defines: canonical vault path, folder-to-type mapping, frontmatter contract, valid statuses, tag hierarchy, cross-reference syntax, and the PipelineEnvelope schema. All output from this skill MUST conform to those conventions. If there is a conflict between this SKILL.md and _conventions.md, the conventions file wins.

Pipeline Position¶

signal-scan -> decision-log -> persona-extract -> swot-analysis -> offer-scope -> positioning -> **pitch** -> hunter-log

This skill consumes the output of offer-scope, persona-extract, swot-analysis, decision-log, and signal-scan, and feeds into hunter-log for execution tracking. The pitch output is the complete "go live" package -- everything needed to launch the product.

When to Use¶

Converting a validated offer spec into ready-to-execute launch materials
Generating landing page copy grounded in persona language and offer-scope positioning
Creating platform-specific launch posts that follow the 80/20 value-first rule
Building a GitHub product README that serves as both documentation and conversion engine
Drafting a post-purchase email sequence for nurturing and community building
Planning a day-by-day launch execution sequence with specific times and platforms
Defining what to test (headlines, prices, channels) once traffic is flowing
Sharpening kill criteria inherited from offer-scope with pitch-level specifics

Trigger Phrases¶

"Build the launch kit for [product]"
"Create pitch materials from this offer spec"
"I need landing page copy for [product]"
"Generate the go-to-market package"
"Turn this offer scope into launch-ready materials"
"/pitch [offer-scope output]"
"Deploy artifacts from [pitch doc]"
"Split the pitch into deployable files"
"/pitch --deploy-only [pitch-slug or path]"

Deploy-Only Mode¶

Reads an existing pitch document from the vault and splits/deploys its artifacts without re-generating content. Use when: - A pitch was generated before the deployment extensions existed - You want to re-deploy artifacts after editing the pitch document - Testing the deployment pipeline against an existing pitch

Deploy-Only Input¶

One of: - Pitch slug: e.g., devops-decision-kit-pitch-2026-02-08 (searches Admin/Product-Discovery/Pitches/) - Full vault path: e.g., Admin/Product-Discovery/Pitches/devops-decision-kit-pitch-2026-02-08.md - Absolute path: the full filesystem path to the pitch markdown

Optional: - Launch date: ISO date for kanban task dates. If omitted, uses relative dates (T-7, T+0, T+1, etc.) - Skip list: Deployment phases to skip (e.g., --skip emails,kanban if those are already deployed)

Deploy-Only Workflow¶

Existing pitch markdown (from vault)
    |
Step 1: Parse pitch document into sections
    |
Step 2: Check what is already deployed (launchpad branch? seeds exist? kanban exists?)
    |
Step 3: Deploy missing artifacts only
    |    ├── Phase 2.4: Launch posts → Obsidian content seeds
    |    ├── Phase 3e: Landing page copy → index.html on launchpad branch
    |    ├── Phase 4.6: Email sequence → individual files on launchpad branch
    |    ├── Phase 5.6: Launch checklist → Obsidian kanban
    |    └── Phase 7.6: Kill criteria → Obsidian Tasks on pitch doc
    |
Step 4: Update Pipeline tracker
    |
Output: Report of what was deployed and where

Parsing Contract¶

The deploy-only mode reads the pitch markdown and locates content by H2 section headers. The pitch doc may use either short headers (## Launch Posts) or phase-numbered headers (## Phase 2: Launch Posts). Match on the section name, ignoring any Phase N: prefix.

Pitch Section	Header (either format)	Parser	Deploy Phase
Landing Page Copy	`## Landing Page Copy` or `## Phase 1: Landing Page Copy`	Read all subsections (### Headline through ### Call to Action) and pass to Phase 3e HTML generator	3e (index.html on launchpad branch)
Launch Posts	`## Launch Posts` or `## Phase 2: Launch Posts`	Split by `### {Platform}: {Title}`, `### Reddit r/{sub} Post`, or `### Twitter/X Thread`	2.4 (Obsidian seeds)
Email Sequence	`## Email Sequence` or `## Phase 4: Email Sequence`	Split by `### Email {N}: {Subject} (Day {N})`	4.6 (individual files)
Launch Checklist	`## Launch Checklist` or `## Phase 5: Launch Checklist`	Split by `### Pre-Launch`, `### Launch Day`, `### Week 1`, `### Ongoing Cadence`, `### Month 2-3 Growth`	5.6 (Obsidian kanban)
Kill Criteria	`## Kill Criteria` or `## Phase 7: Kill Criteria`	Read `### 7.1 Week 1 Threshold`, `### 7.2 Month 1 Threshold`, `### 7.3 Month 3 Threshold` (also accepts unnumbered `### Week 1`, etc.)	7.6 (Obsidian Tasks)

If a section is missing or cannot be parsed, skip that deployment phase and warn the operator. Do not fail the entire deploy because one section is malformed.

Deploy-Only Checks¶

Before deploying each artifact:

Content seeds (Phase 2.4): Check if {vault}/Writing/Content-Briefs/{product-slug}-{platform}-seed-*.md already exists. If yes, skip and warn (or append under ## Update: {timestamp} per conventions).
Landing page HTML (Phase 3e): Check if index.html exists on the launchpad branch root. If yes, skip and warn. If the branch does not exist, warn that Phase 3d (launchpad branch creation) should run first.
Email files (Phase 4.6): Check if emails/ directory exists on the launchpad branch. If yes, skip and warn. If the branch does not exist, warn that Phase 3d (launchpad branch creation) should run first.
Kanban (Phase 5.6): Check if {vault}/Admin/Product-Discovery/Pitches/{product-slug}-launch-checklist.kanban.md exists. If yes, skip and warn.
Review reminders (Phase 7.6): Check if the pitch markdown already has a ## Review Reminders section. If yes, skip and warn.

Deploy-Only Output¶

Returns a deployment report:

{
  "pitch_ref": "devops-decision-kit-pitch-2026-02-08",
  "deployed": {
    "landing_page_html": "index.html (on {product-slug} branch)",
    "content_seeds": ["path/to/seed-1.md", "path/to/seed-2.md"],
    "email_files": ["emails/email-1-welcome.md", ...],
    "kanban": "path/to/launch-checklist.kanban.md",
    "review_reminders": "appended to pitch markdown"
  },
  "skipped": {
    "kanban": "already exists at path/to/..."
  },
  "warnings": ["No launch date specified; using relative dates"]
}

Prerequisites¶

Before starting, the following must be available:

Offer-scope output -- A completed offer-scope result containing: product name, format, price, value equation, build spec, positioning (headline, subheadline, bullet points, objection handlers, social proof angle, guarantee), distribution plan, revenue model, and kill criteria
Persona extraction output -- The persona used by offer-scope, containing: pain stories (with situation/pain/workaround/emotional state/evidence), decision triggers, objections, willingness-to-pay data, and channel behavior
SWOT analysis data -- The SWOT for this hypothesis, containing: validated strengths, key weaknesses, opportunities, threats, risk registry, and moat assessment
Positioning data (optional, recommended) -- If a positioning skill run exists, its output becomes the PRIMARY source for: landing page headline (from messaging hierarchy lead message), problem section (from competitive alternatives), copy anti-rules (from anti-messaging). When positioning output is available, use it instead of offer-scope Phase 5 positioning. If no positioning output exists, fall back to offer-scope positioning as before.
Decision log entry -- The decision record for the chosen opportunity
Signal scan data -- The original signal scan with PAIN, SPEND, COMPETITIVE, and AUDIENCE signals

If any of these are missing, prompt the user to run the upstream skill first or provide the data manually. The pitch skill is a synthesis layer -- it assembles and refines upstream outputs into execution-ready materials, not a research layer.

Input¶

The skill expects the following input structure (assembled from upstream skill outputs):

interface PitchInput {
  offer: {
    product_name: string
    format: string
    price_point: string
    ship_time: string
    value_equation: {
      dream_outcome: string
      perceived_likelihood: string
      time_delay: string
      effort_sacrifice: string
    }
    build_spec: {
      deliverable: string
      transformation: string
      sections: { title: string, estimated_time: string, content_type: string }[]
    }
    positioning: {
      headline: string
      subheadline: string
      bullet_points: string[]
      objection_handlers: { objection: string, counter: string }[]
      social_proof_angle: string
      guarantee: string
    }
    distribution_plan: {
      launch_channel: string
      launch_strategy: string
      ongoing_channels: string[]
      email_capture: boolean
    }
    revenue_model: {
      unit_price: number
      first_week_target: { units: number, revenue: number }
      first_month_target: { units: number, revenue: number }
      assumptions: string[]
    }
    kill_criteria: string[]
  }
  persona: {
    persona_name: string
    pain_stories: {
      situation: string
      pain: string
      current_workaround: string
      emotional_state: string
      evidence: string
    }[]
    decision_triggers: { trigger: string, urgency: string, channel: string }[]
    objections: { objection: string, counter: string }[]
    willingness_to_pay: { range: string, evidence: string, anchor_products: string[] }
    channels: { platform: string, behavior: string }[]
  }
  swot: {
    verdict: string
    validated_strengths: string[]
    key_risks: string[]
    modifications: string[]
    moat_assessment: { current_strength: string, timeline: object }
  }
  positioning?: {
    lead_message: string                // headline source (overrides offer.positioning.headline)
    category_frame: string              // subheadline / positioning line
    primary_hook: string                // above-the-fold emotional hook
    anti_messaging: { phrase: string, use_instead: string }[]  // copy rules
    competitive_alternatives: string[]  // problem section source
    icp_title: string                   // copy targeting
    first_conversation_moats: string[]  // credibility claims
    positioning_canvas_ref: string      // artifact slug for cross-reference
  }
  domain: string
  opportunity: string
  offer_ref: string
  persona_ref: string
  swot_ref: string
  positioning_ref?: string  // slug of the positioning-canvas artifact
  decision_ref: string
  signal_scan_ref: string
}

Workflow¶

Offer Spec + Persona + SWOT + Decision + Signal Scan (from upstream)
    |
Phase 1: Landing Page Copy (complete, ready to paste)
    |
Phase 2: Launch Posts (platform-specific, ready to publish)
    |
Phase 3: GitHub Product Repo (3a: structure + 3b: README + 3c: hero + 3d: branch/PR + 3e: landing page HTML)
    |
Phase 4: Email Sequence (3-5 emails, post-purchase nurture)
    |
Phase 5: Launch Checklist (hour-by-hour execution plan)
    |
Phase 6: A/B Test Spec (what to test once traffic flows)
    |
Phase 7: Kill Criteria Refinement (time-bounded, measurable)
    |
Phase 8: Slide Deck (Slidev presentation with extracted SVG diagrams)
    |
Output: JSON spec + Markdown summary -> vault

Phase 1: Landing Page Copy¶

Generate complete, paste-ready landing page copy with headline, subheadline, above-the-fold hook, problem section (minimum 3 persona pain story references), solution section, what's inside breakdown, social proof strategy, pricing with value stack and guarantee, FAQ mapped to persona objections (minimum 5), and primary/secondary CTAs. Every line must trace to persona data or offer-scope positioning.

Read ${SKILLS_DIR}/pitch/references/landing-page-template.md

Phase 2: Launch Posts¶

Generate 2-3 platform-specific posts following the 80/20 value-first rule. Includes primary channel post, LinkedIn version, and Twitter/X thread. Each post is ready to publish and provides genuine standalone value. Also writes Obsidian content seeds for the content-planner pipeline and integrates with the ::linkedin convention for LinWheel scheduling.

Read ${SKILLS_DIR}/pitch/references/launch-posts-templates.md

2.5 LinkedIn Launch Post Convention (`::linkedin`)¶

For LinkedIn launch posts, write them to Obsidian with the ::linkedin prefix in the note body (before the post content). This triggers the OpenClaw ambient pipeline:

OpenClaw detects the ::linkedin prefix in the Obsidian note
Pipes the note content to LinWheel (the LinkedIn content generator + scheduler)
The operator reviews and approves the post in LinWheel
LinWheel schedules and publishes to LinkedIn

Format: Write the LinkedIn seed to {vault}/Writing/Content-Briefs/{product-slug}-linkedin-seed-{YYYY-MM-DD}.md with ::linkedin as the very first line of the file (line 1, before frontmatter). NOT after frontmatter — BEFORE it. The ::linkedin trigger must be byte 0 of the file or the OpenClaw pipeline won't fire. Frontmatter follows on line 2+. This makes it a live launch post that can be approved and scheduled, not just a draft.

The full pipeline: pitch skill → Obsidian seed → OpenClaw → LinWheel → LinkedIn publication.

Phase 3: GitHub Product README¶

Multi-sub-phase: 3a produces product structure sketch (technical domains only, enriched with buildlog data), 3b produces README conversion copy, 3c generates hero image via ComfyUI (or writes image intent comment), 3d deploys to launchpad repo branch with PR, and 3e generates a single-file dark-theme landing page HTML from Phase 1 copy with full design system, OG tags, and mobile responsiveness.

Read ${SKILLS_DIR}/pitch/references/github-readme-template.md

Phase 4: Email Sequence¶

Generate 5 post-purchase emails: welcome/delivery (Day 0), quick win (Day 2), story/credibility (Day 4), objection handler (Day 6), and community invite (Day 7). Each email has one job, specific subject lines, and practitioner-to-practitioner tone. Outputs individual email files to the launchpad branch emails/ directory.

Read ${SKILLS_DIR}/pitch/references/email-sequence-template.md

Phase 5: Launch Checklist¶

Step-by-step execution plan: pre-launch setup (Days -7 to -1) with specific tools and time estimates, hour-by-hour launch day sequence, daily Week 1 follow-up actions, ongoing cadence (Weeks 2-4), and Month 2-3 growth actions. Outputs an Obsidian Kanban board with dated tasks.

Read ${SKILLS_DIR}/pitch/references/launch-checklist-template.md

Phase 6: A/B Test Spec¶

Define testable variables for solo operators with 100-500 visitors: 2-3 headline variants with rationale, 2-3 price variants cross-referenced with SPEND data, ranked channel priority, metrics with targets and measurement methods, and decision thresholds defined before testing. Sequential testing approach -- one variable at a time.

Read ${SKILLS_DIR}/pitch/references/ab-test-spec.md

Sharpen kill criteria from offer-scope and SWOT with pitch-level specifics: Week 1, Month 1, and Month 3 thresholds with exact numbers and actions. Includes qualitative signal interpretation (iterate vs pivot vs kill), pivot triggers with direction, and Obsidian Tasks output with review reminder dates queryable by Dataview.

Read ${SKILLS_DIR}/pitch/references/kill-criteria-template.md

Phase 8: Slide Deck (Slidev)¶

Generate a Slidev presentation summarizing the validation pipeline output. The deck lives in launchpad/deck/ and deploys alongside the landing page.

8.1 Structure¶

The deck is a single slides.md file using Slidev's markdown syntax. Global config in frontmatter, per-slide frontmatter between --- separators. Speaker notes go in  comments at the bottom of each slide.

Required slides (in order): 1. Cover — product name + validation date (use layout: cover in global frontmatter) 2. Opportunity — the gap diagram 3. Evidence Wall — signal count + key stats 4. Reddit Voices — 3 direct quotes with source citations 5. SDP Scoring — bar chart of opportunity ranking 6. Personas — persona cards with WTP 7. Four Forces — push/pull/inertia/anxiety 8. Two Offers — offer tiers side by side 9. Curriculum Stack — week-by-week breakdown 10. Revenue Model — bar chart of revenue streams 11. Revenue Breakdown — table with unit economics (Stream / Unit Economics / Annual Estimate) 12. Competitive Map — price vs depth scatter plot 13. Execution Calendar — timeline with milestones and kill gate 14. Kill Criteria — gate cards with thresholds 15. Bias Check — status indicators per bias type 16. Next Steps — table with Milestone / Deadline / Kill Condition columns 17. Appendix — asset map linking to all pipeline artifacts 18. Closing — pipeline attribution

8.2 SVG Conventions¶

All diagrams are extracted SVG files in deck/public/. Reference them with <img src="/filename.svg"> tags. NEVER inline complex SVGs in the markdown — Vue's template compiler will mangle them.

SVG style rules: - Font: font-family="'Inter', sans-serif" on all text elements. Never use Caveat, cursive, or handwriting fonts. - Displacement filter: feDisplacementMap scale="0.4" max. Subtle texture, not wobbly hand-drawn. - Color palette: background #0d1117, text #eee0cc, muted #8b949e, coral #e88072, red #f87171, green #4ade80, yellow #facc15 - XML safety: Always escape < as < in SVG text content. Unescaped < breaks the SVG parser. - Sizing: Use viewBox for dimensions. Set style="width:100%;max-width:NNNpx;" on the root <svg> element. - Text overflow: Ensure text fits inside containing boxes. For label text inside bounded shapes, measure the text width against the shape width and reduce font-size or widen the shape if needed. - Overlap: Maintain minimum 50px center-to-center spacing between elements with labels. Check that label text from one element doesn't collide with the heading of the next.

SVG animation rules: - Use CSS @keyframes inside <style> blocks within the SVG for auto-playing animations (pulse, blink, breathe). These work in <img> tags. - For hover interactivity, use <object data="..." type="image/svg+xml"> instead of <img>. Add :hover CSS rules inside the SVG's <style> block. - Good candidates for animation: alert indicators (blink), kill/flag states (pulse), highlighted elements (breathe/glow).

8.3 Slidev Config¶

theme: default
fonts:
  sans: Inter
  mono: Fira Code
  provider: google
transition: slide-left
css: unocss
drawings:
  persist: false

Use style.css for global styles (background, heading colors, v-click animation overrides). Do not use scoped <style> blocks in slides.

8.4 Speaker Notes¶

Every slide gets presenter notes in  comments. Notes must: - State what the slide shows and why it matters - Reference specific numbers, sources, or upstream pipeline data - Be written in direct, conversational tone — not LLM summary voice - Avoid em-dash chains, tricolons, performative honesty, or "landscape/tapestry/crucible" vocabulary

8.5 Content Seed Trigger¶

If generating a LinkedIn content seed, the ::linkedin trigger tag MUST be byte 0, line 1 of the file — BEFORE frontmatter. This triggers the OpenClaw → LinWheel → LinkedIn pipeline.

::linkedin

---
type: content-brief
...

Output¶

The pitch produces multiple output artifacts across the vault and launchpad repo.

Vault path: ${VAULT}/

For the complete output markdown structure (frontmatter, all sections, deployment outputs):

Read ${SKILLS_DIR}/pitch/references/output-template.md

Primary Outputs (Vault)¶

1. JSON Spec: `{vault}/Admin/Product-Discovery/Pitches/{product-slug}-pitch-{YYYY-MM-DD}.json`¶

Structured data following the schema in references/output-schema.json. Must validate against that schema.

2. Markdown Summary: `{vault}/Admin/Product-Discovery/Pitches/{product-slug}-pitch-{YYYY-MM-DD}.md`¶

Human-readable launch kit containing all phase outputs in the structure defined by the output template.

Deployment Outputs (Launchpad Repo + Vault)¶

3. Launchpad Product Branch: `github.com/Peleke/launchpad` branch `{product-slug}`¶

Full product directory structure from Phase 3a
Product README from Phase 3b
Hero image from Phase 3c (or HTML comment with image intent)
emails/ directory with individual email files from Phase 4.6
PR opened against main for operator review (Phase 3d)

3b. Landing Page HTML: `index.html` on launchpad branch root¶

Single-file HTML landing page generated from Phase 1 copy (Phase 3e)
Dark theme, mobile responsive, zero dependencies
Open Graph meta tags for social sharing
Immediately deployable via Vercel branch preview
Preview URL: https://launchpad-git-{product-slug}-kwayet-fs-projects.vercel.app

4. Content Seeds: `{vault}/Writing/Content-Briefs/{product-slug}-{platform}-seed-{YYYY-MM-DD}.md`¶

One file per launch post (Phase 2.4)
Frontmatter: type: content-brief, status: backlog, platform tag
Picked up by content-planner for full brief generation after operator review

5. Launch Checklist Kanban: `{vault}/Admin/Product-Discovery/Pitches/{product-slug}-launch-checklist.kanban.md`¶

Obsidian Kanban board with Pre-Launch, Launch Day, Week 1, Ongoing columns (Phase 5.6)
Tasks have dates, checkable on mobile via iCloud sync

6. Review Reminders: Appended to pitch markdown in vault¶

Obsidian Tasks format with dates and #hunter/review tags (Phase 7.6)
Week 1, Month 1, Month 3 review dates
Queryable by Obsidian Tasks and Dataview plugins

7. Pipeline Tracker: `{vault}/Admin/Product-Discovery/Pipeline.md`¶

Table of all products with branch links, preview URLs, status
Updated by pitch skill when creating a new product
Format:

| Product | Branch | Preview URL | Price | Status | Pitch Date |
|---------|--------|-------------|-------|--------|------------|
| {name} | [{slug}](https://github.com/Peleke/launchpad/tree/{slug}) | [Preview]({vercel-url}) | ${price} | spec | {date} |

Vault Output Contract¶

All vault output files are written to the Obsidian vault (iCloud-synced):

${VAULT}/

Pitch files: Admin/Product-Discovery/Pitches/ - Filename format: {product-slug}-pitch-{YYYY-MM-DD}.md and {product-slug}-pitch-{YYYY-MM-DD}.json

Content seeds: Writing/Content-Briefs/ - Filename format: {product-slug}-{platform}-seed-{YYYY-MM-DD}.md

Launch kanban: Admin/Product-Discovery/Pitches/ - Filename format: {product-slug}-launch-checklist.kanban.md

Pipeline tracker: Admin/Product-Discovery/Pipeline.md

Rules: - If a file already exists at the target path: APPEND under ## Update: {ISO timestamp}, do NOT overwrite - Frontmatter MUST include: type: pitch, date, status: draft, tags (minimum: hunter/pitch, hunter/domain/{slug})

Resources¶

references/¶

output-schema.json -- JSON Schema for the structured pitch output. Load when producing the JSON file to validate against.
landing-page-template.md -- Phase 1: landing page copy structure, section breakdown, copy rules
launch-posts-templates.md -- Phase 2: platform-specific post templates, 80/20 rule, Obsidian seed output, ::linkedin convention
github-readme-template.md -- Phase 3: product structure sketch, README copy, hero image, launchpad branch, landing page HTML design system
email-sequence-template.md -- Phase 4: 5-email post-purchase sequence, tone rules, file output format
launch-checklist-template.md -- Phase 5: pre-launch through Month 2-3 execution plan, Obsidian Kanban output
ab-test-spec.md -- Phase 6: headline/price variants, channel priority, metrics, decision thresholds
kill-criteria-template.md -- Phase 7: time-bounded thresholds, qualitative signals, pivot triggers, Obsidian Tasks output
output-template.md -- Full markdown output structure and deployment output inventory

README.md¶

The full Launch Architecture framework reference, including intellectual lineage (Ogilvy, Schwartz, Halbert, Godin, Dunford, Fitzpatrick, Lavingia, Hoy, McKenzie), detailed methodology, anti-patterns, and calibration examples. Consult for deep framework questions during a pitch session.

Quality Checklist¶

Run this checklist before delivering the pitch:

[ ] Landing page copy is complete and standalone -- someone could build a page from it
[ ] Every line of landing page copy traces to persona data or offer-scope positioning
[ ] Headline stops the scroll -- uses persona's exact pain language, not generic marketing
[ ] Problem section uses minimum 3 persona pain story references with specific language
[ ] FAQ section maps each Q to a specific persona objection
[ ] Launch posts follow 80/20 value-first rule -- genuine value even without buying
[ ] Launch posts follow platform norms (no self-promo spam, platform-specific formatting)
[ ] Each launch post is ready to publish, not an outline or draft
[ ] GitHub README is excellent technical documentation first, marketing second (if technical domain)
[ ] Product structure sketch covers directory layout, file manifest, learning path (if technical domain)
[ ] Free preview in README is genuinely useful -- not a teaser but real, usable content
[ ] Email sequence has specific subject lines -- not "Hey!" but specific to the content
[ ] Each email has ONE job -- no multiple CTAs crammed into a single email
[ ] Email tone is practitioner-to-practitioner, not marketer-to-mark
[ ] Launch checklist has specific dates, times, and platforms -- not "post on social media"
[ ] Launch day plan is hour-by-hour with specific actions
[ ] A/B test spec has measurable metrics with decision thresholds defined before testing
[ ] Price variants are grounded in SPEND data, not guesses
[ ] Kill criteria are time-bounded and measurable -- "sell 10 units in 14 days" not "get traction"
[ ] Kill criteria distinguish between iterate, pivot, and kill signals
[ ] All upstream refs linked (offer_ref, persona_ref, swot_ref, decision_ref, signal_scan_ref)
[ ] JSON output validates against references/output-schema.json
[ ] Markdown output has correct frontmatter (type: pitch, date, status: draft, tags, all refs)
[ ] Both files are saved to vault Admin/Product-Discovery/Pitches/
[ ] Launchpad branch created with product structure, README, hero image, and emails/
[ ] Landing page index.html generated from Phase 1 copy and committed to launchpad branch
[ ] Landing page renders at mobile (640px) and desktop, no horizontal scroll
[ ] Landing page has zero external dependencies (no CDN, no JS, no external CSS)
[ ] Open Graph meta tags present with product name, description, and hero image URL (if hero exists)
[ ] PR opened against launchpad main with review checklist
[ ] Content seeds written to Writing/Content-Briefs/ with correct frontmatter
[ ] Launch checklist written as Obsidian kanban with dated tasks
[ ] Kill criteria review reminders appended with Obsidian Tasks format (dates, #hunter/review)
[ ] Pipeline tracker updated with new product row
[ ] All prose content reviewed by buildlog_gauntlet Bragi persona (all rules)
[ ] Deploy-only mode: all deployment phases either succeeded or were skipped with warnings (no silent failures)

README¶

Pitch¶

A Ground-Up Masterclass in Go-to-Market Execution for Indie Product Builders¶

What this is: An exhaustive guide to the discipline of turning a validated product spec into launch-ready materials -- landing page copy, distribution posts, product READMEs, email sequences, and execution plans -- written for the engineer who can build the product but has never launched one.

Who this is for: You have a validated offer spec. The signal scan found real pain. The persona research confirmed who hurts. The SWOT stress-tested the hypothesis. The offer scope defined what to build, how to price it, and where to sell it. And now you are staring at a blank landing page builder, a blank GitHub README, and a blank email draft, wondering: how do I turn this spec into words that make someone reach for their credit card? This document teaches you that discipline. All of it. The intellectual lineage, the named frameworks, the vocabulary, the psychology, and the specific process this skill uses to produce launch-ready materials from validated product data.

Table of Contents¶

The Discipline: What Is a Launch Architecture?
The Canon: Thinkers, Texts, and Frameworks
Schwartz's Five Levels of Awareness
The Value-First Principle for Technical Audiences
Why Developers Hate Being Marketed To
Landing Page Anatomy for Technical Products
GitHub as Distribution: The README IS the Pitch
The Product Structure Sketch
Email Sequence Psychology
A/B Testing for Solo Operators
Kill Criteria as a Launch Feature
Anti-Patterns: How Launches Fail
Calibration: What Good vs. Bad Looks Like
How Pitch Feeds Execution
The Framework This Skill Implements

The Discipline¶

What Is a Launch Architecture?¶

Here is the gap that kills most indie products: the product is good, the market is real, the price is right, and the launch fails anyway. Not because of the product. Because of the launch materials. The landing page reads like a feature list. The Reddit post reads like spam. The email sequence reads like a marketer who has never touched a terminal. The GitHub README is either a bare-bones install guide or a wall of badges with no substance.

Launch architecture is the discipline of constructing every piece of go-to-market material as a coherent, evidence-grounded system. Not marketing. Not copywriting. Architecture. The landing page, the launch posts, the README, the email sequence, and the execution plan are not independent creative exercises. They are components of a single system designed to move a specific person (the persona) from a specific state (unaware or problem-aware) to a specific action (purchase or signup) through a specific mechanism (providing genuine value first, earning the right to ask for money second).

The discipline sits at the intersection of three practices:

Direct response copywriting asks "what words make someone take action?" This is the world of David Ogilvy, Eugene Schwartz, and Gary Halbert. It is the craft of writing words that sell, grounded in a century of tested principles about human attention, belief, and desire. It is not manipulation -- it is communication precision. The right headline is not the cleverest headline. It is the one that makes the right person stop scrolling and think "this is about me."

Product-led growth asks "how does the product itself drive distribution?" This is the world of GitHub READMEs, open-source adoption funnels, and the concept that the best marketing for a technical product is the product being excellent and visible. When the README IS the pitch, the quality of the documentation IS the quality of the marketing.

Permission marketing asks "how do I earn the right to sell?" This is Seth Godin's fundamental insight: in a world where attention is the scarcest resource, the only sustainable marketing strategy is to earn attention by providing value first. The 80/20 rule that this skill enforces -- give 80% of the insight for free, sell the organized version -- is permission marketing applied to technical product launches.

Launch architecture is all three, woven together and grounded in validated upstream data. Every line of copy traces to a persona pain story. Every headline maps to a level of awareness. Every post follows platform norms. Every email has one job. Every metric has a threshold. The result is not a pile of marketing materials. It is a launch system.

If you are an engineer who has never written a landing page, composed a launch post, or drafted an email sequence, this document will teach you the complete discipline. By the end, you will understand why certain words convert and others do not, why the same product pitched differently succeeds or fails, and how to construct a launch that feels like genuine contribution rather than self-promotion -- because it IS genuine contribution, by design.

The Canon¶

Every discipline has its foundational thinkers. Launch architecture draws from direct response copywriting, positioning theory, permission marketing, and indie product strategy. Here are the people whose work you need to know, what they contributed, and how each feeds into what this skill does.

David Ogilvy -- Ogilvy on Advertising (1983)¶

Key insight: "On the average, five times as many people read the headline as read the body copy. When you have written your headline, you have spent eighty cents out of your dollar." Ogilvy proved, through decades of tested advertising at his agency Ogilvy & Mather, that the headline is not just important -- it is disproportionately important. Most of the money, most of the attention, and most of the conversion power lives in the headline and the first few lines.

Framework: Ogilvy's approach to copywriting was empirical, not creative. He tested everything. He tracked response rates. He built a body of knowledge about what works based on data, not taste. His principles include: the headline must promise a benefit, the body copy must deliver specific information (not puffery), and "the consumer isn't a moron, she's your wife" -- meaning respect your audience's intelligence.

Feed into launch architecture: Ogilvy's headline discipline directly informs Phase 1 of this skill. The landing page headline must promise a specific benefit using the persona's language. It must be tested (Phase 6 A/B test spec generates headline variants). And the body copy must be specific and informative -- not "our product is amazing" but "here is exactly what you get, here is exactly what changes, here is exactly how fast." Ogilvy would have loathed the modern SaaS landing page with its generic hero image and "Empower your workflow" headline. He would have written: "Stop spending 4 hours on Terraform plans that should take 20 minutes. Here is the decision tree."

Ogilvy's other enduring contribution is the concept of long-form copy. He demonstrated repeatedly that long copy outperforms short copy -- provided every sentence earns its place. People do not read long copy because it is long. They read it because it is interesting and relevant. A landing page with 2,000 words of specific, persona-relevant copy will outperform a landing page with 200 words of generic claims. This is especially true for technical audiences, who evaluate depth as a proxy for competence.

Eugene Schwartz -- Breakthrough Advertising (1966)¶

Key insight: The market, not the copywriter, determines the message. Schwartz's most enduring contribution is the Five Levels of Awareness framework, which states that every prospect exists at one of five awareness levels, and the copy must match the level. You cannot sell to someone who does not know they have a problem. You cannot educate someone who already knows the solution. Matching the message to the awareness level is the single most important decision in copywriting.

Framework: The Five Levels of Awareness:

Unaware: The prospect does not know they have a problem. They are not looking for anything. Reaching them requires pattern-interrupt content that makes them realize something is wrong. This is the hardest level to sell to and the most expensive to reach.
Problem-Aware: The prospect knows they have a problem but does not know solutions exist. They search for "why does my Terraform deployment keep failing?" not "Terraform decision framework." Copy at this level must name and validate the problem.
Solution-Aware: The prospect knows solutions exist but has not chosen one. They are comparing options, reading reviews, evaluating alternatives. Copy at this level must differentiate your solution from alternatives.
Product-Aware: The prospect knows about YOUR product specifically but has not bought yet. They are on your landing page, reading your README, considering your offer. Copy at this level must overcome objections and prove value.
Most Aware: The prospect knows your product and wants it. They just need the final push -- the right price, the right guarantee, the right moment. Copy at this level is about making the purchase easy.

Feed into launch architecture: Schwartz's framework is the architectural blueprint for this entire skill. Each output targets a different awareness level:

Landing page = Most Aware and Product-Aware. They are already on the page. The copy's job is to overcome objections and convert.
Launch posts = Problem-Aware and Solution-Aware. They are scrolling Reddit or LinkedIn. The copy's job is to name the problem, provide genuine value, and introduce the product as a natural next step.
GitHub README = Solution-Aware. They found the repo through search or a link. The copy's job is to prove competence through documentation quality, provide genuine value through the free preview, and position the paid product as the complete version.
Email sequence = Product-Aware to Most Aware. They already bought. The copy's job is to activate usage, build trust, and expand the relationship (community).

Every piece of copy this skill produces is designed for a specific awareness level. This is not optional. Copy that mismatches the awareness level fails regardless of how well it is written. A landing page written for Problem-Aware prospects (explaining what the problem is) bores Product-Aware prospects (who already know the problem and want to know about your solution). A Reddit post written for Most-Aware prospects (hard sell with a buy link) repels Problem-Aware prospects (who do not even know your product exists yet).

Schwartz also introduced the concept of market sophistication -- the idea that markets evolve through stages of increasing skepticism. In a Stage 1 market, you can make a simple claim ("This will help you deploy faster"). In a Stage 5 market, every claim has been made and the prospect is jaded. You must either identify the mechanism behind the claim ("Here is the specific decision tree, based on 200 production deployments, that eliminates guesswork from your deploy process") or identify with the prospect's experience ("You have tried three different approaches and none of them stuck -- here is why, and here is what is different about this one").

Technical audiences are almost always Stage 4 or Stage 5. They have seen every pitch. They have tried every tool. They are immune to hype. This is why the "value-first" principle is non-negotiable for technical product launches: you must prove competence before asking for money.

Gary Halbert -- The Boron Letters (1984)¶

Key insight: Before you write a single word of copy, ask one question: "Is there a starving crowd for this?" Halbert, writing from prison to his son Bond, laid out the foundational principle that the market matters more than the copy. The greatest copywriter in the world cannot sell ice to a crowd that is not thirsty. But a mediocre copywriter can sell steak to a starving crowd.

Framework: The Starving Crowd principle and the A-Pile / B-Pile distinction. Halbert observed that when people sort their mail, they create two piles: the A-pile (personal letters, things that look important -- they read these) and the B-pile (junk mail, obvious marketing -- they throw these away). The goal of direct response is to get into the A-pile. In the digital era, this translates to: your email must look like it was written by a real person to a real person, not by a marketing automation system to a segment.

Feed into launch architecture: Halbert's "starving crowd" principle is the reason this skill sits downstream of signal-scan, persona-extract, and offer-scope. By the time we reach the pitch phase, the starving crowd has been identified (signal-scan), profiled (persona-extract), stress-tested (SWOT), and the product has been scoped specifically for them (offer-scope). The pitch skill does not find the crowd. It feeds the crowd.

The A-pile / B-pile distinction directly informs the email sequence in Phase 4. Every subject line is written to pass the "A-pile test": does it look like a specific message from a specific person about a specific thing? "Your DevOps Decision Kit is ready -- start with the Kubernetes section" passes. "Your Weekly Newsletter Issue #47" does not. The body copy is written as a practitioner talking to another practitioner, not as a brand talking to a subscriber. This is the difference between email that gets opened and email that gets archived.

Halbert also emphasized writing to one person. Not "Dear DevOps professionals." Not "Attention, engineers." Instead: imagine one specific person from your persona data sitting across the table. Write to them. What would you actually say? How would you actually explain this? The persona extraction output provides that person. Every line of copy this skill produces is written to ONE person -- the persona.

Seth Godin -- Permission Marketing (1999) + This Is Marketing (2018)¶

Key insight: The old model of marketing (interruption marketing -- TV ads, cold calls, spam) is dying because attention is now the scarcest resource. The new model is permission marketing: earn the right to communicate with someone by providing value first, then gradually deepen the relationship. Godin later refined this with the concept of the smallest viable audience: do not try to reach everyone. Find the smallest group of people who would miss you if you were gone, and serve them so well that they become your evangelists.

Framework: The permission marketing ladder: stranger -> friend -> customer -> loyal customer -> evangelist. Each step requires providing value before asking for more. You do not go from stranger to customer in one step. You go from stranger (they read your free post) to friend (they join your email list) to customer (they buy your product) to loyal customer (they use it and get results) to evangelist (they share it with their peers). Each step earns permission for the next.

Godin also introduced the concept of status roles in marketing. Every purchase is partly about status -- not in the luxury-goods sense, but in the "what does buying this say about who I am?" sense. A DevOps engineer buying a decision framework is saying "I take my craft seriously enough to invest in my own development." Understanding the status role helps you write copy that resonates at the identity level, not just the feature level.

Feed into launch architecture: Godin's permission marketing ladder IS the structure of the pitch output:

Free content (launch posts, GitHub README preview) = stranger -> friend. Provide genuine value. Earn the right to be noticed.
Email signup (lead magnet, newsletter CTA) = friend -> known contact. They give you their email because you earned it with free value.
Product purchase (landing page conversion) = contact -> customer. They buy because you proved competence and relevance.
Email sequence (post-purchase nurture) = customer -> loyal customer. You help them use the product and get results.
Community (Email 5 invite) = loyal customer -> evangelist. They join a community of peers and become part of something larger.

The smallest viable audience concept is why this skill does not try to write copy that appeals to "everyone interested in DevOps." It writes copy for ONE persona, using THEIR language, addressing THEIR pain. The copy will not resonate with everyone. It will deeply resonate with the exact people who should buy the product. That is the point.

April Dunford -- Obviously Awesome (2019)¶

Key insight: Positioning is not messaging. Positioning is the foundational strategic decision about what your product IS, who it is FOR, and why they should CARE. Most products fail not because of bad marketing or bad products, but because of bad positioning. They are described in ways that make their value invisible to the people who need them most.

Framework: Dunford's positioning methodology asks five questions in order:

What are the competitive alternatives? What would your customer do if your product did not exist? (Not just competitors -- also "do nothing," "use a spreadsheet," "ask ChatGPT.")
What are your unique attributes? What do you have that the alternatives do not?
What value do those attributes enable? Not features, but outcomes. What can the customer DO because of your unique attributes?
Who are the customers who care most about that value? Not everyone. The specific segment that values your differentiation the most.
What market category makes your value obvious? How do you frame the product so the right people immediately understand it?

Feed into launch architecture: Dunford's positioning work was done in offer-scope. The pitch skill consumes the positioning output. But Dunford's framework still matters here because the pitch skill must DEPLOY the positioning correctly across different channels and formats.

The landing page deploys positioning for Product-Aware prospects (they are already here -- tell them why to buy). The launch post deploys positioning for Solution-Aware prospects (they are browsing -- tell them why this is different from alternatives). The GitHub README deploys positioning for Solution-Aware technical prospects (they found the repo -- prove competence and differentiation through documentation quality). Each deployment is the same positioning, adapted for a different context and awareness level.

Dunford's emphasis on competitive alternatives is especially important for the FAQ section. Every objection is, at its core, a comparison to an alternative: "I could just use ChatGPT for this" (alternative: AI), "I can find this stuff for free on Reddit" (alternative: free content), "I'll just figure it out myself" (alternative: do nothing). The FAQ section addresses these alternatives explicitly, using the counter-arguments from offer-scope objection handlers.

Rob Fitzpatrick -- The Mom Test (2013)¶

Key insight: People will lie to you about whether they would buy your product. Not maliciously -- but when you ask "Would you buy this?", social pressure makes them say yes. Even your mom will say yes. That is why it is called The Mom Test. The solution: never ask about the future ("would you buy this?"). Ask about the past ("what happened the last time you faced this problem? what did you do? how much did it cost you?").

Framework: Three rules for useful customer conversations: (1) Talk about their life instead of your idea. (2) Ask about specifics in the past instead of generics or opinions about the future. (3) Talk less and listen more. The best validation questions start with "Tell me about the last time..." and "What did you do about it?" and "How much did that cost?" -- not "Would you pay for..." or "Would you use..."

Feed into launch architecture: Fitzpatrick's insight is the reason this skill does not validate the product idea. That was done upstream. But his framework pervades the copy: the problem section of the landing page uses past-tense, specific language ("You spent four hours debugging a Terraform plan that turned out to have a circular dependency") rather than future-tense, generic language ("Are you ready to improve your deployment process?"). Past-tense specificity triggers recognition. Future-tense generality triggers skepticism.

The Mom Test also informs the email sequence. Email 2 (Quick Win) does not ask "How are you finding the product?" It says "Try this with your next [specific task]." It asks them to DO something specific and report back. Action-based feedback is honest feedback. Opinion-based feedback is The Mom Test failure.

Sahil Lavingia -- The Minimalist Entrepreneur (2021)¶

Key insight: You do not need venture capital, a large team, or a grand vision to build a profitable business. Start with a community you belong to, identify a problem they have, build a solution, sell it to them, and grow from there. The minimalist entrepreneur builds in public, charges from day one, and grows revenue before growing the team.

Framework: The minimalist entrepreneur's sequence: (1) Start with community. (2) Build as little as possible. (3) Sell to your first customers (who are in the community). (4) Market by helping (not by advertising). (5) Grow slowly and sustainably. (6) Build the house you want to live in. Lavingia explicitly rejects "growth at all costs" in favor of sustainable, profitable businesses that serve specific communities.

Feed into launch architecture: Lavingia's "market by helping" principle is the 80/20 rule in action. The launch posts in Phase 2 are not advertisements. They are genuine contributions to the community. The value they provide is real, standalone, and useful even if no one clicks the product link. This is not idealism -- it is strategy. Technical communities punish self-promotion and reward genuine contribution. The fastest way to sell to engineers is to help engineers. The launch post that provides real value and mentions the product as an afterthought will outperform the launch post that provides thin value and pushes the product aggressively.

Lavingia's emphasis on community also informs the email sequence endgame (Email 5: community invite) and the entire structure of the launch checklist, which emphasizes ongoing community engagement over one-time promotional bursts.

Amy Hoy -- Just F*cking Ship (2015) + Sales Safari¶

Key insight: Most products die not from being bad products but from never being launched. Perfectionism, scope creep, and fear of public feedback kill more products than bad market fit. Hoy's directive is simple: set a ship date, cut scope until it fits, and ship. The product you ship and iterate on is infinitely more valuable than the product you never finish.

Framework: Sales Safari is Hoy's audience research methodology. Instead of conducting interviews or sending surveys, you "go on safari" in the communities where your audience lives -- Reddit, forums, Stack Overflow, review sites -- and observe what they say, do, complain about, and pay for. You collect their exact language. You map their pain. You understand their world by watching them in their natural habitat, not by pulling them into yours.

Hoy also introduced the concept of ebombs (educational content bombs): standalone, valuable educational content that demonstrates your expertise and provides genuine value. An ebomb is not a teaser. It is a complete, self-contained piece of educational content that makes the reader smarter. The strategy: publish ebombs consistently, build trust and audience, then sell products to the audience you have built. The ebomb IS the marketing.

Feed into launch architecture: Sales Safari is the upstream process -- persona-extract and signal-scan already did the safari. The pitch skill consumes the output. But Hoy's influence is strongest in the launch posts (Phase 2), which are essentially ebombs. Each launch post is a complete, self-contained educational piece that provides genuine value. The product link at the end is the payoff of trust earned through the ebomb, not a bait-and-switch grafted onto thin content.

JFS (Just F*cking Ship) informs the launch checklist in Phase 5. The checklist is designed to prevent the most common launch failure: never actually launching. By defining every task, every timeline, and every tool needed, the checklist removes the ambiguity that perfectionism exploits. You do not need to decide what to do next. You look at the checklist and do the next thing.

Patrick McKenzie (patio11) -- The Oracle of Hacker News¶

Key insight: "Charge more." This is McKenzie's most famous advice, and it is devastatingly effective because almost every indie product is underpriced. Engineers in particular underprice because they are embarrassed to charge for their work, because they compare their price to the marginal cost of production (which for digital products is zero), and because they do not understand that price is a signal of quality. A $9 PDF says "this was a weekend project." A $49 PDF says "this is a professional resource." A $149 course says "this is a serious career investment." The product can be identical. The price changes how it is perceived.

Framework: McKenzie does not have a named framework, but his body of writing on Hacker News, his blog (kalzumeus.com), and his podcast (with Ramit Sethi) constitute one of the richest repositories of tactical wisdom about selling to technical audiences. Key principles include:

Price is a quality signal. Technical audiences are sophisticated enough to know that expensive usually means better, especially in education and tooling. Underpricing makes you look amateur.
Write for technical audiences the way they write for each other. No marketing speak. No buzzwords. Precise language, specific examples, and a willingness to go deep.
The best landing page for a technical product is a detailed, honest, specific description of what the product does and who it is for. Not a clever marketing page. A competent, thorough explanation.
SaaS is not the only business model. Info products, consulting, and one-time purchases are all viable. Do not default to SaaS because it is what VCs talk about.

Feed into launch architecture: McKenzie's influence pervades the tone and pricing of every output this skill produces.

The landing page copy is written in the technical register -- the way engineers write to each other, not the way marketers write to prospects. No buzzwords. No "empower your workflow." Specific claims, specific numbers, specific examples.

The pricing section follows "charge more" by anchoring the price against the value of the transformation and the cost of the alternative (wasted time, bad decisions, stalled career), not against the cost of production.

The GitHub README is written as if McKenzie were reviewing it: technically precise, genuinely useful, and honest about what the product is and is not. A McKenzie-approved README would never have a "synergize your DevOps workflow" section. It would have a "here is a decision tree for choosing between ECS and EKS, with the actual trade-offs listed in a table" section.

Schwartz's Five Levels of Awareness¶

This concept is important enough to warrant its own section, because it is the architectural backbone of every output this skill produces.

The Levels, Applied to Launch Materials¶

Level 1 -- Unaware: The prospect does not know they have a problem. They are not searching, not browsing relevant communities, and not thinking about the topic. Reaching these people requires interruption: ads, viral content, or referrals from someone they trust. This skill does NOT produce content for Unaware prospects. It is too expensive and too speculative for a solo operator launch. Leave Level 1 for when you have revenue to invest in awareness campaigns.

Level 2 -- Problem-Aware: The prospect knows something is wrong but has not identified solutions. They search for "why does my deployment keep failing?" or "how to stop getting paged at 2am." Launch posts (Phase 2) target this level. The post names the problem, validates it ("you are not alone -- this is a structural problem, not a personal failing"), and provides a genuine framework for thinking about it. The product mention at the end moves them from Problem-Aware to Solution-Aware.

Level 3 -- Solution-Aware: The prospect knows solutions exist and is evaluating options. They search for "DevOps decision framework" or "Terraform state management best practices." The GitHub README (Phase 3) targets this level. The README proves competence through documentation quality, provides genuine value through the free preview, and differentiates the paid product from free alternatives.

Level 4 -- Product-Aware: The prospect knows about YOUR product specifically. They are on your landing page or have seen your product mentioned. The landing page copy (Phase 1) targets this level. The copy must overcome objections (FAQ section), prove value (What's Inside, pricing section), and make the purchase easy (CTA copy).

Level 5 -- Most Aware: The prospect wants the product and just needs the final push. The email sequence (Phase 4) starts here -- Email 1 delivers the product to someone who already bought. But the sequence then does something interesting: it moves BACKWARD through the levels, rebuilding awareness at each stage. Email 2 (Quick Win) makes the product tangible. Email 3 (Story) rebuilds why the product exists. Email 4 (Objection Handler) addresses lingering Solution-Aware doubts. Email 5 (Community) introduces a new awareness cycle for the community offering.

The Mapping¶

Awareness Level	Primary Output	Secondary Output
Unaware	(not targeted -- too expensive for launch)
Problem-Aware	Launch posts (Phase 2)
Solution-Aware	GitHub README (Phase 3)	Launch posts (late body)
Product-Aware	Landing page (Phase 1)	GitHub README (CTA section)
Most Aware	Email sequence (Phase 4)	Landing page (returning visitors)

This mapping is not academic. It is the reason the same product information is presented differently in each output. The landing page does not explain what the problem is -- the visitor already knows. The launch post does not hard-sell the product -- the reader is not ready. Mismatching awareness level to output is the single most common copywriting failure in indie product launches.

The Value-First Principle for Technical Audiences¶

Why 80/20 Works¶

The 80/20 value-first rule states: give away 80% of the core insight for free, and sell the organized, actionable, complete version as the product.

This seems counterintuitive. Why would someone pay for something if they already have 80% of it for free? The answer lies in how technical professionals actually consume information.

The free 80% proves competence. When a DevOps engineer reads a detailed, specific, technically accurate post about container orchestration decision-making, they are evaluating the author as much as the content. "This person actually knows what they are talking about." The free content is an audition. If you pass, they will pay for more.

The free 80% is unorganized. A Reddit post or a README section is valuable but scattered. The paid product organizes the same insights into a workflow, a decision tree, a checklist, a sequence -- a SYSTEM. The transformation from insight to system is what people pay for. They pay for "I can actually use this tomorrow morning" rather than "I learned something interesting."

The free 80% is incomplete. An 80% decision framework is useful but has gaps. The 20% that is behind the paywall is the gap-filler: the edge cases, the advanced scenarios, the templates that turn understanding into action. The free version makes you smarter. The paid version makes you faster.

The free 80% is distribution. Every person who reads your free content and finds it valuable is a potential link-sharer, upvoter, and word-of-mouth amplifier. Free content with genuine value spreads. Thin content with a sales pitch does not. The free content IS your marketing budget.

What 80/20 Looks Like in Practice¶

In a launch post: You share the core decision framework (the 80%). You explain the logic, the trade-offs, and the criteria. A reader who never buys the product can still use this framework. At the end: "I packaged this framework along with [specific additional things] into [product name]. It includes [specific things the free post does not have]."

In a GitHub README: You include a complete, usable subset of the product. A functional decision tree, a working checklist, a real template. Someone who clones the repo gets genuine value. The paid product adds: more frameworks, more edge cases, a complete learning path, and premium support.

In an email sequence: You teach something specific and actionable in Email 2. Not a teaser. Not "buy the product to learn this." An actual technique they can use TODAY. Demonstrated competence and generosity builds trust faster than any sales pitch.

Why Developers Hate Being Marketed To¶

This section exists because the number one failure mode for engineers selling to engineers is writing copy that sounds like marketing. Here is why that fails and what to do instead.

The Pattern Recognition Problem¶

Developers are trained to detect patterns. Marketing language is a pattern. The moment a developer sees "Unlock your potential," "Revolutionary approach," "Game-changing framework," or any other marketing cliche, a pattern match fires: "This is marketing. Marketing lies. Ignore." The reaction is automatic, subconscious, and nearly universal among technical audiences.

This is not irrationality. It is learned behavior from years of being targeted by products that overpromise and underdeliver. Enterprise software marketing, in particular, has trained a generation of engineers to assume that any product described in marketing language is worse than the marketing implies. The marketing IS the negative signal.

The Hoy Solution: Sell Without Selling¶

Amy Hoy's approach is the antidote. Instead of selling, you EDUCATE. Instead of pitching, you CONTRIBUTE. Instead of marketing language, you use PRACTITIONER language -- the same language you would use explaining something to a colleague.

The pitch skill enforces this by requiring that all copy trace to persona data. Persona data uses the persona's OWN language -- the words engineers use when talking to each other. "I spent three hours debugging a Terraform plan that touched 47 resources" is practitioner language. "Streamline your IaC workflow" is marketing language. The first makes the developer think "this person has been there." The second makes the developer close the tab.

The McKenzie Standard¶

Patrick McKenzie's writing about selling to developers establishes the gold standard: be specific, be honest, be technical, and be direct. His landing pages for Appointment Reminder read like detailed technical documentation, not marketing pages. They describe exactly what the product does, exactly who it is for, exactly what it costs, and exactly what happens when you sign up. No mystery. No hype. No "schedule a demo to learn more." This directness is not the absence of marketing. It IS the marketing for technical audiences.

The pitch skill produces landing page copy, launch posts, and email sequences that meet the McKenzie standard. Specific claims, not vague promises. Honest limitations, not hidden caveats. Technical depth, not buzzword density. If the copy would make McKenzie cringe, it fails the quality checklist.

Landing Page Anatomy for Technical Products¶

The standard SaaS landing page template -- hero image, three feature boxes, testimonial carousel, pricing table -- does not work for technical products sold to technical audiences. Here is what works instead and why.

What Technical Buyers Actually Evaluate¶

When a developer lands on a product page, they evaluate in this order:

Headline: Is this about my problem? (0.5 seconds)
Subheadline: What specifically does this product do? (2 seconds)
Specificity check: Does this person actually understand the problem, or are they selling generic advice? (5 seconds)
Competence check: Is the writing technically accurate? Does it demonstrate real knowledge? (10 seconds)
Scope check: What exactly do I get? Is this worth the price? (30 seconds)
Trust check: Who made this? Do they have credibility? (30 seconds)
Risk check: What is the guarantee? Can I get my money back? (10 seconds)
Decision: Buy, bookmark for later, or leave. (5 seconds)

Total evaluation time: about 90 seconds. The landing page must deliver all of this information in 90 seconds for the scanner, while also providing depth for the reader who wants to evaluate thoroughly.

The Structure That Works¶

The landing page structure this skill produces follows the evaluation order above:

Headline + Subheadline = Steps 1-2 (problem + solution in 10 words)
Above-the-fold hook = Step 3 (specificity proof in 2-3 sentences)
Problem section = Step 4 (competence proof through pain language)
Solution section + What's Inside = Step 5 (scope proof through specific deliverables)
Social proof section = Step 6 (trust proof through credentials)
Pricing section + FAQ = Step 7 (risk reduction through guarantee and objection handling)
CTA = Step 8 (make the purchase frictionless)

This structure is not creative. It is functional. It maps to how technical buyers actually evaluate products. Each section exists to answer a specific question at a specific point in the evaluation process.

GitHub as Distribution¶

The README IS the Pitch¶

For technical products, the GitHub README is not documentation. It is the highest-leverage marketing asset you own. Here is why.

Engineers discover products through GitHub. When a developer searches for "terraform state management framework" or "devops decision tree," they often end up on GitHub. GitHub repos rank well in search results. Stars, forks, and activity create social proof that no landing page can match. A repo with 500 stars has more credibility than a landing page with 500 testimonials.

The README is the first impression. When someone finds your repo, the README is the only thing they see. If the README is excellent -- clear, specific, well-formatted, technically precise, and genuinely useful -- they conclude the product is excellent. If the README is sloppy, sparse, or generic, they leave. README quality IS product quality in the mind of the technical buyer.

The free content in the README IS the 80%. A README that includes a complete, usable decision framework is the ebomb (Hoy) and the value-first content (Godin) all in one. The developer gets value. The repo gets stars and forks. The CTA at the bottom captures the 2-5% who want the full version. This is the entire funnel in a single document.

Product Structure as Marketing¶

The product structure sketch (Phase 3a) exists because technical buyers evaluate structure as a proxy for quality. A well-organized repo with clear directories, descriptive filenames, and a logical progression signals "the person who built this thinks clearly." A flat repo with ten files named "framework1.md" through "framework10.md" signals "this was thrown together."

The directory tree in the README is not just documentation. It is a preview of the product's architecture. When a developer sees a clean directory tree with intuitive naming and logical organization, they think "this person builds things the way I would want to build things." That recognition is more powerful than any testimonial.

The Product Structure Sketch¶

Why Technical Products Need Architectural Documentation as Marketing¶

For non-technical products -- courses on marketing, ebooks on productivity, templates for social media -- a product description suffices. "This course includes 12 modules covering X, Y, and Z." The buyer evaluates based on topic coverage and instructor credibility.

For technical products -- decision frameworks for DevOps, security checklists, architecture templates -- the structure IS the value proposition. A DevOps engineer buying a decision framework is not buying "information about decisions." They are buying a SYSTEM: specific decision trees organized by domain, specific checklists organized by workflow stage, specific templates organized by use case. The organization of the material is as important as the material itself.

This is why Phase 3a (Product Structure Sketch) exists as a separate sub-phase. Before writing the README, the skill designs the actual product architecture:

What directories exist and what each contains
What files exist and what each does
How someone progresses through the material (learning path)
What they need to know before starting (prerequisites)

This architectural documentation serves three purposes:

Product design: It forces clarity about what the product actually IS before writing marketing copy about it.
Preview content: The directory tree and file manifest in the README give the prospect a concrete picture of what they are buying.
Quality signal: A well-designed product structure demonstrates the same systematic thinking that the product teaches. It is proof of concept in the packaging.

Email Sequence Psychology¶

The Trust-Building Arc¶

The email sequence is not a sales funnel. It is a trust-building arc. Each email earns a deeper level of trust and engagement:

Email 1 (Delivery): Trust = "this person delivered what they promised." This is the minimum bar. Deliver immediately, deliver clearly, and make the first action obvious.
Email 2 (Quick Win): Trust = "this product actually works." By helping the buyer achieve a specific result, you validate the purchase and build usage momentum.
Email 3 (Story): Trust = "this person has been where I am." Shared experience creates connection. A specific production war story -- not a "my journey" narrative, but a "here is what went wrong at 2am" story -- establishes credibility at the visceral level.
Email 4 (Objection Handler): Trust = "this person is honest about limitations." Addressing doubts proactively, rather than waiting for them to fester, signals confidence and integrity.
Email 5 (Community): Trust = "there are others like me on this path." The community invite transforms a transactional relationship (I bought a product) into a social one (I belong to a group).

This arc is not arbitrary. It follows the psychological progression from transactional trust (Email 1) through competence trust (Email 2) through character trust (Email 3) through vulnerability trust (Email 4) through belonging trust (Email 5). Each type of trust is harder to earn and more durable once earned.

The One-Job Rule¶

Every email has ONE job. Not two. Not three. One. The reason: multiple calls to action create decision paralysis and reduce compliance with ALL of them. An email that asks you to read the quick start guide AND join the community AND share on social media AND reply with feedback will achieve none of these. An email that asks you to do ONE thing -- "Open Section 3 and try the Kubernetes decision tree with your current architecture" -- will achieve that one thing at a much higher rate.

The one-job rule also prevents the email sequence from feeling like a sales campaign. Each email earns its open through the value it provides, not the products it promotes. The sequence builds trust because each email GIVES something (a quick win, a story, an honest answer) rather than ASKS for something (buy this, share this, review this).

A/B Testing for Solo Operators¶

The Honest Truth About Testing with Small Numbers¶

Enterprise CRO teams run A/B tests with thousands of visitors per variant and calculate statistical significance to three decimal places. You have 100-500 visitors in your first month. Here is what you can and cannot learn from that.

What you CAN learn: Directional signals. If Headline A gets a 2% click-through rate and Headline B gets a 6% click-through rate over 200 visitors each, Headline B is probably better. You cannot prove it with statistical significance, but the direction is clear enough to act on.

What you CANNOT learn: Small differences. If Headline A converts at 3.1% and Headline B converts at 3.4% over 100 visitors each, that is noise. You cannot distinguish signal from randomness at this sample size. Do not try.

Sequential Testing for Small Audiences¶

Instead of splitting traffic (which requires enough traffic to split), use sequential testing:

Run Version A for one week. Measure conversion.
Run Version B for the next week. Measure conversion.
Compare. If the difference is large (2x or more), it is probably real. If it is small (less than 50% difference), it is probably noise.

This is not rigorous. A purist would object that week-over-week variation introduces confounding variables. They are right. But sequential testing with 200 visitors beats no testing with 200 visitors. The goal is not academic rigor. The goal is "is this headline clearly better than that headline?"

What to Test First¶

The testing priority for solo operators:

Headline: The highest-leverage element. If the headline does not stop the scroll, nothing else matters. Test 2-3 variants.
Price: The second highest-leverage element. A 50% price increase with no conversion drop doubles your revenue. Test 2-3 price points.
Channel: Which distribution channel converts best? Track UTM parameters and compare conversion rates by source.
CTA: "Get the Decision Kit" vs "Download Now" vs "Start Making Better Decisions." Small change, sometimes big impact.
Everything else: Not worth testing until you have 1,000+ visitors per month.

Kill Criteria as a Launch Feature¶

Why Kill Criteria Belong in the Launch Kit¶

Most launch guidance ends with "launch and see what happens." This is the "launch and pray" anti-pattern. It fails because it provides no framework for interpreting what happens next. If you sell 3 units in the first week, is that good or bad? Without kill criteria, you do not know. And without knowing, you either quit too early (it was actually fine -- 3 units in week 1 can grow) or persist too long (it was a signal that the positioning is wrong, and you spend three more months on a doomed product).

Kill criteria are not pessimism. They are the mechanism that makes a portfolio strategy work. If you launch three products this quarter and set kill criteria for each, you will quickly identify the winner (exceeds criteria), the maybe (meets criteria marginally), and the loser (misses criteria badly). You kill the loser, iterate on the maybe, and double down on the winner. Without kill criteria, all three products linger in zombie state, consuming time and attention without producing results.

The Iterate / Pivot / Kill Framework¶

Not all failure looks the same. The kill criteria in this skill distinguish three types:

Iterate means the mechanism needs tuning. The product is in the right market for the right audience, but something specific is not working. Examples: the landing page converts poorly (rewrite headline), the launch post gets no engagement (try a different angle), the email sequence has low open rates (rewrite subject lines). The fix is tactical: change a specific element and measure again.

Pivot means the approach needs changing. The pain is real and the audience exists, but the product format, price, or distribution channel is wrong. Examples: people love the free content but will not pay the asking price (price pivot), people engage on LinkedIn but not Reddit (channel pivot), people want a video course instead of a PDF (format pivot). The fix is strategic: keep the insight, change the vehicle.

Kill means the opportunity is not viable. The pain is not strong enough, the audience is not reachable, or the competition is too entrenched. Examples: zero engagement on free content across all channels (positioning failure or wrong audience entirely), consistent feedback that free alternatives are good enough (free content floor too high), an established player launches a competing product with 10x distribution (competitive knockout). The fix is to stop and move on.

The qualitative signals in Phase 7 map specific types of feedback to these three responses, so you know which action to take when the data comes in.

Anti-Patterns: How Launches Fail¶

"Launch and Pray"¶

The pattern: Build the product, write a quick landing page, post it once on Reddit, and wait for sales. When nothing happens, conclude that "marketing is broken" or "the market doesn't get it."

Why it fails: A single post on a single channel reaches a tiny fraction of the potential audience. Even a great post will be seen by maybe 1-5% of a subreddit's subscribers. At a 2% conversion rate on those who actually click through, you need thousands of views to generate meaningful sales. One post is not enough. Launch is not an event. It is a process.

The fix: Phase 5 (Launch Checklist) defines a sustained execution plan: hour-by-hour launch day, daily actions for week 1, ongoing cadence for months 1-3. The launch kit is designed for sustained effort, not a single shot.

Overbuilding Before Launching¶

The pattern: Spend weeks perfecting the product. Add more sections. Polish the formatting. Rewrite the introduction three times. When the product is "ready" (it is never ready), spend another week perfecting the landing page. By the time you launch, you are exhausted and the market has moved on.

Why it fails: Perfect is the enemy of shipped (Hoy). Every day you spend perfecting is a day you are not getting market feedback. The first version of the product is almost never what the market actually wants. You learn what the market wants by launching, getting feedback, and iterating -- not by imagining what they want and building to that imagined spec.

The fix: The kill criteria and launch checklist enforce time-boxing. The product is "done" when the build spec is complete. The launch happens on the scheduled date. Iteration happens after launch, driven by actual market feedback, not pre-launch anxiety.

Testing on Friends Instead of Strangers¶

The pattern: Show the product to friends, family, and colleagues. They say it is great. Launch to the general market. Silence.

Why it fails: Fitzpatrick's Mom Test. Friends will not tell you the truth. They want to be supportive. They do not have the same pain as your target persona. Their "this is great" is social courtesy, not market validation.

The fix: The launch posts (Phase 2) are designed for publication to strangers in the target community. Reddit, dev.to, and LinkedIn are audiences of strangers. If strangers engage, the signal is real. If strangers ignore it, the signal is also real -- and far more honest than your friend's thumbs-up.

Optimizing Conversion Before You Have Traffic¶

The pattern: Obsess over landing page conversion rate when you have 20 visitors per week. Rewrite the headline six times. Redesign the page. Rearrange the sections. All while the real problem is that nobody is visiting the page.

Why it fails: Optimizing a 3% conversion rate to a 4% conversion rate on 20 visitors per week means you go from 0.6 sales/week to 0.8 sales/week. The difference is noise. The real problem is getting from 20 visitors to 200 visitors. Traffic is almost always the bottleneck for indie products, not conversion rate.

The fix: Phase 6 (A/B Test Spec) explicitly orders the testing priority: channel testing (where does traffic come from?) before conversion testing (how do we convert it?). The launch checklist emphasizes distribution activity over landing page optimization in the first month.

The Generic README¶

The pattern: Write a README with a project title, a one-line description, "Installation: pip install mypackage", and a bare-bones usage example. Expect the product to sell itself through the quality of the code.

Why it fails: The README IS the pitch for technical audiences. A thin README signals a thin product. Engineers evaluate README quality as a proxy for product quality. A README that does not demonstrate the product's value, provide a genuine preview, or explain who this is for and why it matters will not convert browsers to buyers.

The fix: Phase 3 produces a comprehensive README that includes a product structure preview, a genuine free preview (the 80%), conversion-optimized but technically precise copy, and clear CTAs. The README is treated as the most important single marketing asset for a technical product.

Calibration: What Good vs. Bad Looks Like¶

A Bad Landing Page Headline¶

Supercharge Your DevOps Workflow with Our Comprehensive Framework

Why it is bad: Generic. "Supercharge" is a dead metaphor. "Comprehensive" tells the reader nothing specific. "DevOps Workflow" is too broad. Every DevOps tool on the planet claims to "supercharge" something. The persona reads this headline and thinks "this is marketing" and closes the tab.

A Good Landing Page Headline¶

Stop Guessing Which AWS Service to Use. Start Deciding in 5 Minutes.

Why it is good: Specific pain ("guessing which AWS service to use" -- this is language from the persona's pain stories). Specific outcome ("deciding in 5 minutes" -- this is the time_delay from the value equation). No marketing words. The persona reads this and thinks "that is literally my problem."

A Bad Launch Post Opening¶

I'm excited to announce my new product! After months of hard work, I've created a comprehensive framework for DevOps decision-making. Check it out!

Why it is bad: Self-focused ("I'm excited," "my new product," "months of hard work"). No value for the reader. No reason to keep reading. Violates every platform norm (Reddit will downvote this, LinkedIn will scroll past, Twitter will ignore).

A Good Launch Post Opening¶

Last week I had to decide between ECS, EKS, and Fargate for a new service. Again. For the fourth time this year. So I built a decision tree. Here it is.

Why it is good: Starts with a relatable situation (the persona has done this exact thing). Provides value immediately (a decision tree). No self-promotion. The product mention comes later, after the value has been delivered.

A Bad Email Subject Line¶

Welcome to Our Community! 🎉

Why it is bad: Generic. The emoji signals marketing automation. "Our Community" could be anything. The recipient does not know what to expect.

A Good Email Subject Line¶

Your DevOps Decision Kit is ready -- start with the Kubernetes section

Why it is good: Specific (they know what they bought and what to do next). Action-oriented (start with the Kubernetes section). No emoji. No exclamation marks. Sounds like a person wrote it.

How Pitch Feeds Execution¶

The Handoff¶

The pitch output is the complete "go live" package. When the pitch skill finishes, the operator has:

Landing page copy that can be pasted directly into Carrd, Webflow, Framer, or any page builder
Launch posts that can be pasted directly into Reddit, LinkedIn, and Twitter
A GitHub README that can be pasted directly into a repo
An email sequence that can be loaded directly into ConvertKit, Buttondown, or any email tool
A launch checklist with specific dates, times, and actions
A/B test variants ready to deploy once traffic flows
Kill criteria defined and committed to before emotional investment builds

The next step is execution -- actually publishing, posting, and selling. Execution is tracked by hunter-log, the downstream skill. Hunter-log monitors the kill criteria, logs the outcomes, and determines whether to continue, iterate, pivot, or kill.

The pitch skill does not execute. It does not publish posts or create Gumroad listings. It produces the complete materials that the operator (or hunter-log) uses to execute. The boundary is clear: pitch produces, hunter-log tracks.

What Happens After Launch¶

The launch is not the end. It is the beginning of a feedback loop:

Launch (using pitch materials)
Measure (tracked by hunter-log against pitch kill criteria)
Iterate (update pitch materials based on what is working)
Decide (continue, pivot, or kill based on pitch kill criteria thresholds)

If the product succeeds, the pitch materials evolve: headlines get refined based on A/B tests, launch posts get updated based on what resonated, the email sequence gets optimized based on open and click rates. The pitch is a living document, not a one-time output.

If the product fails, the kill criteria provide a clear decision framework. The operator does not have to agonize over whether to continue. The criteria were set before launch, before emotional investment, before sunk cost. The numbers either hit the threshold or they do not.

The Framework This Skill Implements¶

Launch Architecture¶

This pitch skill implements a named framework called Launch Architecture. It is a synthesis of direct response copywriting principles, permission marketing strategy, and product-led growth tactics, adapted specifically for indie product builders launching validated technical products.

Intellectual Lineage¶

Component	Source	Adaptation
Awareness-matched copy	Eugene Schwartz (Five Levels of Awareness, 1966)	Each output (landing page, launch post, README, email) targets a specific awareness level. Copy is written for that level, not for a generic audience.
Headline discipline	David Ogilvy (Ogilvy on Advertising, 1983)	The headline carries 80% of the copy's weight. Tested via A/B spec. Must use persona's exact language.
Starving crowd validation	Gary Halbert (The Boron Letters, 1984)	The pitch skill sits downstream of signal-scan and persona-extract. The crowd is already validated. The pitch feeds the crowd.
Permission marketing ladder	Seth Godin (Permission Marketing, 1999)	The output structure IS the permission ladder: free content -> email signup -> purchase -> nurture -> community.
Positioning deployment	April Dunford (Obviously Awesome, 2019)	Positioning from offer-scope is deployed differently for each awareness level and channel. Same positioning, different execution.
Past-tense specificity	Rob Fitzpatrick (The Mom Test, 2013)	Copy uses past-tense specific language ("you spent 3 hours debugging...") not future-tense generic ("are you ready to improve...").
Community-first distribution	Sahil Lavingia (The Minimalist Entrepreneur, 2021)	Launch strategy centers on community contribution, not advertising. Market by helping.
Ebombs as launch posts	Amy Hoy (Sales Safari + Just F*cking Ship, 2015)	Launch posts are standalone educational content bombs. The product link is earned, not inserted.
Technical audience tone	Patrick McKenzie (patio11, blog + HN corpus)	All copy meets the McKenzie standard: specific, honest, technical, direct. No marketing speak.
Value-first selling	Hoy + Godin + McKenzie (synthesized)	The 80/20 rule: give 80% for free, sell the organized version. Applied to every output.

Where Launch Architecture Diverges¶

From traditional copywriting: Traditional direct response copy is written for consumer audiences and optimizes for emotional response. Launch Architecture is written for technical audiences and optimizes for demonstrated competence. The emotional triggers are different: engineers respond to specificity, honesty, and technical depth, not to urgency, scarcity, or social proof from unknown people.

From content marketing: Content marketing is a long-term strategy of building audience through consistent publishing. Launch Architecture is a launch-specific strategy that produces all materials simultaneously as a system. It is designed for the moment of launch, not for ongoing content creation (that is handled by content-planner, a different skill in the pipeline).

From SaaS marketing playbooks: SaaS playbooks assume recurring revenue, a free trial or freemium tier, and a product that users can experience before buying. Launch Architecture is designed for one-time purchase products (PDFs, templates, kits) sold to technical audiences through community distribution. The funnel is different: community post -> landing page -> purchase, not free trial -> activation -> conversion.

From generic launch advice: Most launch advice says "build an audience, launch to the audience, iterate." Launch Architecture works for zero-audience operators because the distribution strategy (value-first community posts, GitHub README as discovery engine) does not require an existing audience. The free content IS the audience-building mechanism AND the launch mechanism simultaneously.

The Launch Architecture Lifecycle¶

1. RECEIVE    -> Offer spec + persona + SWOT + upstream refs (from pipeline)
2. COMPOSE    -> Landing page copy (awareness: Product-Aware / Most Aware)
3. DISTRIBUTE -> Launch posts (awareness: Problem-Aware / Solution-Aware)
4. DOCUMENT   -> GitHub README (awareness: Solution-Aware, format: technical)
5. NURTURE    -> Email sequence (awareness: Most Aware -> rebuilds backward)
6. EXECUTE    -> Launch checklist (specific dates, times, actions)
7. MEASURE    -> A/B test spec + kill criteria (what to test, when to decide)

This is the process this skill automates. It is designed to produce every piece of material needed to go from "I have a validated product spec" to "I am live and selling" in a single session. The output is not strategy. It is not a plan. It is the actual words, the actual posts, the actual emails, and the actual checklist. Ready to paste. Ready to publish. Ready to send.

The engineer who runs Launch Architecture on a validated offer spec walks away with a complete launch kit. Not "ideas for a launch." Not "a marketing strategy." A kit. With words. That they can paste into tools and press publish. That is the entire point.

Final Note¶

The discipline described in this document is the bridge between "I built something" and "someone bought it." Engineers tend to treat the launch as an afterthought -- an annoying step between the real work (building) and the desired outcome (revenue). It is not an afterthought. It is the mechanism by which a product becomes a business.

The thinkers listed here -- Ogilvy, Schwartz, Halbert, Godin, Dunford, Fitzpatrick, Lavingia, Hoy, McKenzie -- have collectively spent decades codifying the practices that make products sell. Not through manipulation. Not through "growth hacks." Through the patient, specific, honest work of understanding who needs what you built, writing words that resonate with that person, and distributing those words where that person will encounter them.

This skill synthesizes their work into a repeatable process. Use it after offer-scope validates the product. Use it honestly -- the copy is only as good as the persona data it draws from. And when the launch works, remember that it did not work because the copy was clever. It worked because the signal scan found real pain, the persona research identified real people, the SWOT stress-tested the hypothesis, the offer scope defined the right product at the right price, and the pitch skill turned all of that upstream work into words that the right person could not ignore.

The launch is not the beginning. It is the culmination of a pipeline. Respect the pipeline, and the launch takes care of itself.

🚀 pitch¶

Install¶

Security Scan¶

File Info¶

Skill Prompt¶

Pitch¶

Step 0: Load Conventions¶

Pipeline Position¶

When to Use¶

Trigger Phrases¶

Deploy-Only Mode¶

Deploy-Only Input¶

Deploy-Only Workflow¶

Parsing Contract¶

Deploy-Only Checks¶

Deploy-Only Output¶

Prerequisites¶

Input¶

Workflow¶

Phase 1: Landing Page Copy¶

Phase 2: Launch Posts¶

2.5 LinkedIn Launch Post Convention (::linkedin)¶

Phase 3: GitHub Product README¶

Phase 4: Email Sequence¶

Phase 5: Launch Checklist¶

Phase 6: A/B Test Spec¶

Phase 7: Kill Criteria Refinement¶

Phase 8: Slide Deck (Slidev)¶

8.1 Structure¶

8.2 SVG Conventions¶

8.3 Slidev Config¶

8.4 Speaker Notes¶

8.5 Content Seed Trigger¶

Output¶

Primary Outputs (Vault)¶

1. JSON Spec: {vault}/Admin/Product-Discovery/Pitches/{product-slug}-pitch-{YYYY-MM-DD}.json¶

2. Markdown Summary: {vault}/Admin/Product-Discovery/Pitches/{product-slug}-pitch-{YYYY-MM-DD}.md¶

Deployment Outputs (Launchpad Repo + Vault)¶

3. Launchpad Product Branch: github.com/Peleke/launchpad branch {product-slug}¶

3b. Landing Page HTML: index.html on launchpad branch root¶

4. Content Seeds: {vault}/Writing/Content-Briefs/{product-slug}-{platform}-seed-{YYYY-MM-DD}.md¶

5. Launch Checklist Kanban: {vault}/Admin/Product-Discovery/Pitches/{product-slug}-launch-checklist.kanban.md¶

6. Review Reminders: Appended to pitch markdown in vault¶

7. Pipeline Tracker: {vault}/Admin/Product-Discovery/Pipeline.md¶

Vault Output Contract¶

Resources¶

references/¶

README.md¶

Quality Checklist¶

README¶

Pitch¶

A Ground-Up Masterclass in Go-to-Market Execution for Indie Product Builders¶

Table of Contents¶

The Discipline¶

What Is a Launch Architecture?¶

The Canon¶

David Ogilvy -- Ogilvy on Advertising (1983)¶

Eugene Schwartz -- Breakthrough Advertising (1966)¶

Gary Halbert -- The Boron Letters (1984)¶

Seth Godin -- Permission Marketing (1999) + This Is Marketing (2018)¶

April Dunford -- Obviously Awesome (2019)¶

Rob Fitzpatrick -- The Mom Test (2013)¶

Sahil Lavingia -- The Minimalist Entrepreneur (2021)¶

Amy Hoy -- Just F*cking Ship (2015) + Sales Safari¶

Patrick McKenzie (patio11) -- The Oracle of Hacker News¶

Schwartz's Five Levels of Awareness¶

The Levels, Applied to Launch Materials¶

The Mapping¶

The Value-First Principle for Technical Audiences¶

Why 80/20 Works¶

What 80/20 Looks Like in Practice¶

Why Developers Hate Being Marketed To¶

The Pattern Recognition Problem¶

The Hoy Solution: Sell Without Selling¶

The McKenzie Standard¶

Landing Page Anatomy for Technical Products¶

What Technical Buyers Actually Evaluate¶

The Structure That Works¶

GitHub as Distribution¶

The README IS the Pitch¶

2.5 LinkedIn Launch Post Convention (`::linkedin`)¶

1. JSON Spec: `{vault}/Admin/Product-Discovery/Pitches/{product-slug}-pitch-{YYYY-MM-DD}.json`¶

2. Markdown Summary: `{vault}/Admin/Product-Discovery/Pitches/{product-slug}-pitch-{YYYY-MM-DD}.md`¶

3. Launchpad Product Branch: `github.com/Peleke/launchpad` branch `{product-slug}`¶

3b. Landing Page HTML: `index.html` on launchpad branch root¶

4. Content Seeds: `{vault}/Writing/Content-Briefs/{product-slug}-{platform}-seed-{YYYY-MM-DD}.md`¶

5. Launch Checklist Kanban: `{vault}/Admin/Product-Discovery/Pitches/{product-slug}-launch-checklist.kanban.md`¶

7. Pipeline Tracker: `{vault}/Admin/Product-Discovery/Pipeline.md`¶