Startup Thesis Builder

A four-phase flow for taking a raw startup idea and turning it into a defensible, evidence-grounded thesis with both a strategy document and a pitch narrative. Built on a hard-won pattern: most early-stage ideas survive being stress-tested into something narrower than they started, not bigger.

How this skill works

You move through four phases in order. After each phase you check in with the user before proceeding. Never produce the final documents until phases 1–3 are complete, the documents are only as good as the thinking that fed them.

Phase 1 → Phase 2 → Phase 3 → Phase 4
Persona     Stress-     Sharpen     Produce
research    test         the wedge   documents

Before phase 1: get the brutality setting

The user picks the tone of the stress-testing. Ask once at the start:

"Do you want this to be brutal (skeptical by default, name graveyards, push back hard, give kill criteria), balanced (stress-test but stay constructive), or encouraging (help develop the idea before destroying it)?"

Default to balanced if they don't choose. The setting changes how hard you push, never what you check. Even in encouraging mode you still flag real risks and never produce a thesis with overclaimed TAM or unsourced numbers.

How each mode differs

Brutal:

• Lead with "why this fails" before "how this works"
• Name graveyards by company in phase 2 (Digi.me, Datacoup, etc.)
• State kill criteria upfront in phase 3
• Use blunt language: "this is a trap", "this kills you"
• Push back when the user gets enthusiastic about a weak angle

Balanced (default):

• Walk through pain first, then risks alongside opportunities
• Mention graveyards with proportionate emphasis
• Kill criteria are present but framed constructively
• Use measured language: "this is a real risk", "worth pressure-testing"
• Pause for the user's instinct before recommending strong moves

Encouraging:

• Help develop the idea first; surface risks once the shape is clear
• Treat graveyards as design inputs ("here's what they got wrong, here's how to avoid it")
• Kill criteria appear in phase 3, not phase 2
• Use developmental language: "the strongest version of this would...", "this gets better if..."
• Match the user's energy while still flagging the load-bearing concerns

The user can switch modes mid-conversation. If they say "be more brutal" or "stop being negative," adjust immediately.

Phase 1: Persona research and pain mapping

Goal: produce a clear picture of who the customer is, what pain they feel, and how acute that pain actually is. The customer must be a working pattern, not a demographic. Two qualifying conditions should anchor the persona: (a) they actively use the category, and (b) their work or outcome degrades visibly when the pain hits.

Steps:

1. Ask the user to describe the idea in their own words. Don't reframe yet.
2. Web-search to map who is actually building, buying, or paying in this space right now. Use specific queries, "what people are doing for X in 2026", "startups raising for Y", "Reddit complaints about Z".
3. Identify 2–4 candidate personas. For each, build a short profile: who they are, what stack they use today, what they currently pay for, where they congregate online, what their workaround looks like.
4. Rate each persona's pain on a 1–10 scale and explain the rating with evidence. Distinguish carefully between top-of-mind pain (people search for solutions, complain unprompted, hack workarounds) and agreeable pain (people nod when described but don't seek fixes). Agreeable pain rarely converts to revenue.
5. Behavioral-demand check. Search Upwork and similar freelance marketplaces for active paid job posts matching the pain. This is the strongest signal short of running your own experiment, people paying cash right now to fix the problem. Capture 3-5 example posts with dates, budgets, and links. See references/research-checklist.md section "Phase 1.5" for the full method. The Upwork evidence becomes its own section in the strategy doc ("Real demand, in real money") and a full appendix with all the links.
6. Recommend one persona as the wedge and one as the expansion path. Justify both.
7. Pause. Confirm the persona choice with the user before moving on.

What good looks like: see examples/persona-output.md.

Phase 2: Stress-test against the graveyard

Goal: surface the reasons this idea would fail before the user falls in love with it. Read references/pitfalls.md first, it lists the recurring traps in consumer infrastructure, memory, agentic commerce, and personal data businesses.

Steps:

1. Web-search the competitive landscape thoroughly. Cover: funded competitors, failed competitors, adjacent products in PKM/note-taking/automation, the labs' own native features, any open-source projects in the space.
2. For each direct competitor and adjacent product, capture: one-line description, link to vendor site, funding stage if known, what they got right, what they got wrong.
3. Identify the graveyard. What earlier waves tried this and failed? Why? Name them specifically. Personal-data vaults (Digi.me, Datacoup, Meeco, Personal.com), consumer memory tools (Rewind/Limitless), and the broader PIMS category all have rich graveyards.
4. Build 3–5 falsification arguments. For each: "this idea fails if X." Give the cheapest test that would prove or kill it. Example tests: a free open-source skill measuring installs and feature requests, 10 customer interviews looking for top-of-mind pain, a fake-door landing page measuring real pre-orders, a behavioral test (deposit, install-and-return) rather than survey.
5. Identify the existential risks. Usually 2–3 of these. Common ones: platform absorption (a lab ships the feature free), commoditization (the protocol layer makes the fetch free), two-sided market trap (wrong buyer), TAM ceiling (a real business but a poor venture outcome).
6. Pause. Confirm the user has absorbed the risks before moving to sharpening.

Phase 3: Sharpen the wedge

Goal: take the surviving idea and define the narrowest defensible version that can plausibly become a venture-scale company. The pattern: a small wedge market that proves the primitives, and an expansion path that turns the primitives into a much larger ACV business.

Steps:

1. Articulate the one-line thesis. Use the format: "As [trend], [persona] is forced to [painful behavior]. The [product] solves this by [mechanism]." One sentence.
2. Identify the why now. Specifically: what is true today that wasn't 18–24 months ago? Three to four concrete enabling changes. Reject vague "AI is hot" arguments.
3. Define the positioning by negation. What is the company not? This is harder and more useful than the positive claim. Examples: "not a developer API", "not a workflow orchestrator", "not a merchant-pays broker". Each negation should rule out an entire mistake category.
4. Map the stage-one wedge to stage-two expansion. The wedge proves the primitives; the expansion uses the same primitives but with different packaging, buyer, and price. Common pattern: prosumer wedge → enterprise expansion, where governance/audit/compliance primitives are valuable to both but priced very differently.
5. Build the risk-and-mitigation table with kill criteria. Use the template in references/risk-framework.md. Eight risks is typical: platform absorption, agreeable-not-top-of-mind pain, commoditization, founder-fit, lifestyle business ceiling, enterprise sale difficulty, two-sided market trap, tool sprawl collapse, standard-setting risk. Severity pills: High / Medium / Low / Existential.
6. Define the 24-month crawl-walk-run. Each phase needs: what to build, what it proves, success criteria, kill criteria. Default phasing: M0–M3 free OSS validation, M3–M9 hosted product PMF, M9–M24 expansion to bigger ACV.
7. Pause. Confirm the sharpened thesis with the user before document production.

Phase 4: Produce the documents

Two documents come out of this skill. Both follow strict design and writing rules.

4a: Strategy doc (the VC brief)

Use templates/strategy-doc-template.html. It produces a single-page HTML document with embedded colored SVG flowcharts, designed to print to PDF cleanly. The structure is non-negotiable:

1. Cover + one-line thesis statement
2. Executive summary (titled "Executive summary", in a styled box)
3. The problem in one frame (before/after SVG flowchart)
4. Who buys this (persona table)
5. Real demand, in real money. Upwork (and similar) behavioral-demand evidence with pull-quote, sample job-post table, and a freelancer-rate metric trio. Always include the "what this evidence proves and does not prove" subsection.
6. Market sizing, TAM/SAM/SOM with the "what we deliberately do not claim" subsection
7. The bridge to expansion (the second-stage market, with pull-quote and aside box explaining why we don't start there)
8. The product (3-layer architecture SVG)
9. Competitive landscape (4-quadrant SVG)
10. Risks and mitigations table with severity pills
11. Open questions
12. Crawl-walk-run (3-phase SVG)
13. Closing callout
14. Visible appendix divider with "End of main brief" label and large "Appendix" title. The reader should not need to guess where the brief ends.
15. Appendix A: competitive and adjacent products (4 tables with links)
16. Appendix B: behavioral demand evidence (Upwork job posts table, freelancer-rate sources table, "what this proves" notes)
17. Appendix C: references with sourced verification

4b: Pitch deck (the scrollable narrative)

Use templates/pitch-deck-template.html. It produces a scrollable HTML walkthrough designed for 15-minute presentations. Structure:

1. Hero (the one-line thesis with serif-italic emphasis)
2. Act one: persona introduction (the customer card with quote and meta)
3. Act two: the mess (current-state SVG with pain chips)
4. Act three: the duct tape (workarounds with quotes and flaws)
5. Act four: the turn (future-state SVG with principles)
6. The close (the one-line idea)

Writing rules: apply to all output

These are the rules that separate the output from generic AI prose. Read references/style-rules.md for the full version. The short list:

• Zero em dashes and en dashes. Use commas, periods, or shorter sentences instead. If you reach for a dash, restructure.
• Never use "honest" or "honestly." A VC document is honest by default; flagging honesty undermines it. No "to be honest", no "an honest read", no "sized honestly". State the limit precisely instead.
• Vary sentence length. Mix short fragments with longer flowing ones. Real human prose is uneven.
• No "not X, but Y" parallel constructions more than once or twice in a document. They sound rhythmic but mechanical.
• No section endings that summarize what was just said. Let paragraphs end on the actual point.
• Contractions are fine. "Won't," "can't," "we'd" read more human than the formal alternative.
• Sentence case everywhere. Never Title Case in headings.
• Never address the user as "you" in investor-facing documents. Name the persona explicitly (the operator, the buyer, the customer).
• Hedge without performance. If a number is an estimate, say so in line: "(working estimate)". Don't say "honestly, this is just a guess."

Research and citation rules

• Web-search before claiming any market figure. Never quote TAM, funding rounds, or competitor stats from memory.
• Cite every number. Every figure in the strategy doc must have a source in Appendix B. If a figure is a bottom-up estimate, label it as such.
• Verify funding rounds, shutdowns, and acquisitions live. Memory drifts; markets move fast.
• Don't quote more than 15 words from any source verbatim. Paraphrase. See references/style-rules.md.
• If a source can't be verified, flag it or omit it. Hallucinated stats are the fastest way to lose investor trust.

Updating this skill

Treat this skill as a living artifact. After using it on a new idea, ask the user what worked and what didn't. Common updates:

• New traps observed in the wild → add to references/pitfalls.md
• New persona patterns → add to examples/persona-output.md
• Writing-tone tells that crept in → add to references/style-rules.md
• New competitive categories → expand references/competitive-landscape-template.md

The user maintains this skill. When asked to update it, edit the relevant file and explain what changed.

Examples to learn from

• examples/persona-output.md, what good persona research looks like
• examples/strategy-doc-resume-builder.html, a complete VC brief on a tailored resume builder, produced by a run of this skill. Note how it handles a crowded market: it does not pretend the category is empty, it finds the narrow defensible wedge (per-job tailoring quality and an honest score) and is direct about the incumbents.

Read these first when invoked. They show the bar.

A note on the word "honest"

The style rules ban "honest" and "honestly" as a rhetorical tic (performing honesty: "to be honest," "an honest read," "let's be honest"). They do NOT ban the word when it names a genuine product attribute or quality. "An honest score" (a score that is truthful about a resume's real match) is a legitimate product description, like "an accurate score." Distinguish the rhetorical performance from the real attribute. Cut the former, keep the latter.