Stop sending dead files.

Here's the proof, and it's a stupid story. I had a wild idea I couldn't shake: an Autonomous Fighting Championship. Humanoid robots, an octagon, blacklight and bass, no humans bleed. The UFC of robots, underground first. The kind of idea you say out loud at dinner with friends and watch the table decide whether you're serious.

So I said it out loud at dinner. The table did the thing the table does. And the question that came back wasn't "is this insane" — it was "do you have a deck? Is there an investment doc?" The honest answer was no. There was a thought and a steak.

So one got spun up. Fast — the mechanic from Chapter 19 pointed at an idea instead of a product. Not a slide file. Two linked interactive HTML docs: a pitch — vision, why-now, tier economics, a use-of-funds donut you can hover, a revenue model that toggles by year — and a second doc, the robot stable: every humanoid platform shipping in 2026, filterable, with a profit-per-fighter calculator where you move the sliders and watch the math move. Real links. Forwardable.

The punchline is the part that matters. The artifact existed before the next meeting did. That's the entire reason this might become a company instead of a dinner anecdote. A dead deck would still be in a folder. A live link is already circulating — and circulation is how an idea stops being yours alone and starts being real.

A prospect came in with a problem and a number: a cold-email estate of ~90 sending domains and ~5,000 mailboxes, deliverability quietly collapsing, and a question — "can you run an external audit of our infrastructure?" External meaning passive: no access to their sending platform, just what the public internet already says about them.

That's a Folderly-methodology job. So I swarmed it — Claude Code agents running the deliverability playbooks in parallel: DNS and SPF resolution across every domain, blacklist sweeps, the registration-pattern read that exposes a snowshoe estate, the infra-misrepresentation check. Same-week turnaround, with the rigor the manual version takes a fortnight to reach.

The part that mattered to the client wasn't the speed. It was that the finding arrived as an interactive audit, not a 40-page PDF. They could filter the domain table, sort by risk, click a flagged domain and see exactly why it failed, watch the pooled-IP story render. A PDF would have been argued with. A live artifact where every claim is one click from its evidence is not argued with — it's acted on. The medium made the methodology undeniable, and made the operator look like the operator.

The embed below is that exact deliverable, sanitized: the client, every domain, and the infra fingerprints are de-identified — the structure, charts, and findings shape are the real thing.

Two embedded cases above is the proof, not the catalogue. The pattern crossed every business I run, in a particular order, and the order matters because it's the same one yours will follow.

Pitches went first. The cheapest deliverable to htmlize is the one no compliance team has to approve. An investment deck for a venture that doesn't exist yet — like AFC — is a private repo with a link in it, and the first version is up in an evening. The second time you make a pitch this way, you don't even consider PowerPoint. By the third, you've forgotten the format you used to use. That's the path of every deliverable on this page — it took going from one to two for the old format to feel embarrassing.

Audits and external reports went next. The Folderly case above is the canonical version, but the methodology lifts directly to anything that has a structure (claims → evidence → recommendations). Procurement audits, vendor due-diligence reports, market scans, competitive teardowns, ICP reviews — anything where a static doc would be argued with becomes a link where every claim is one click from its evidence. The medium changes what the reader does, which changes what the conversation is.

Then internal deliverables. Quarterly business reviews, board updates, the weekly KPI digest, offsite strategy memos. The format hits a wall the first time someone wants to "see what happens if we ship two weeks later" — a slide can't answer, an artifact can. The internal version is where the operator gets the muscle memory; the external version is where the operator gets the wins.

Then communication that used to be Notion or email. Briefs to contractors. Mentee session prep. Retrospectives. Vendor RFP responses. None of these need to be interactive — until you ship one that is, watch the recipient open it three times instead of zero, and stop attaching .docx files. Distribution is the only thing that was ever scarce, and a forwardable artifact wins distribution against anything you can attach.

The Playbook itself is the maximal version. Every chapter you're reading is an artifact under this same thesis — the book is a private repo, deployed to a link, updated by commit. Edition 6 added three embedded case studies. Edition 7 made the launch itself an artifact (/launch). Edition 8.1 made the launch week live (/launch-week) — numbers updating from real data, day-by-day timeline, the "what I'd do differently" section that fills from receipts instead of Day-0 guesses. The book is the proof and the demo. You're inside the case study right now.

Four steps. Skip none of them. Total time on a doc you'd previously have spent four hours on is about thirty-five minutes the first time and twelve minutes by the fifth.

Step 1 — Decide the shape, not the content. "What's in it" is the easy part and it's also the wrong part to start on. Start with the shape: a waterfall chart? A filterable table? A scenario calculator with sliders? An audit with one click per finding to its evidence? The shape is the interaction. If you can't describe the interaction in one sentence — "the reader moves a slider for close-rate and watches the year-end number move" — the artifact will look like a slide deck stuffed into HTML and read worse than the deck did. Decide the interaction first; the content will fit around it.

Step 2 — Hand Claude this prompt with your data. Verbatim. This is the prompt I use across the portfolio, with the angle-brackets filled in for the specific job.

You are building a single-file interactive HTML artifact — no build step,
no framework, vanilla HTML/CSS/JS, ~30KB target. The reader will receive
it as a deployed link. It will be forwarded to people I'll never meet.

DELIVERABLE:        <one-line shape from Step 1>
PRIMARY INTERACTION: <the slider / filter / hover / toggle>
AUDIENCE:           <investor / customer / board / client / public>
TONE:               <operator-grade / consulting-grade / brand-grade>
NUMBERS TO LOAD:    <attach JSON or CSV or paste inline>
BRAND:              <link to brand identity OR paste 3 hex codes + 1 typeface>

Constraints:
- Single .html file, no external scripts (inline everything)
- Mobile-first responsive
- All numbers come from the data I just gave you — no hallucinated figures
- Every interactive element answers a question the reader was going to
  ask anyway. Don't add a slider for its own sake.
- The header must say what this is and who it's for in under 12 words.
- If the data has anomalies, show them. Don't smooth.

That's the whole prompt. Adjust the constraint block for the specific surface — add "must work inside a Gmail-rendered iframe" if you're embedding in a newsletter, add "single dark theme only" if you've got a brand book that says so, add "include a print stylesheet" if you genuinely think someone might print it (they won't).

Step 3 — Iterate three times and stop. First pass will be 80% there. Second pass tightens the design and fixes the numbers Claude pulled from the wrong column. Third pass adds the one interaction the first pass didn't have because you hadn't seen the first pass yet. After three, marginal improvement curves out — ship. The chapter on running until done applies here, but the "done" criterion is "would I send this link right now?" not "could it be 5% better next week."

Step 4 — Deploy and send the link. Private repo, GitHub Pages or Vercel, thirty seconds. The mechanic is Chapter 19's Hour 2 pointed at a document instead of a product:

gh repo create board-update-q3 --private
mkdir -p board-update-q3 && cp artifact.html board-update-q3/index.html
cd board-update-q3 && git init && git add . && git commit -m "q3"
vercel --prod   # or push and let GH Pages serve from /docs

The link goes in the email. The dead file does not. Next week's update is a commit, not a re-export and a prayer that they open the newest attachment instead of the one from two Tuesdays ago.

I'd be the only person publishing a chapter on a format if I weren't honest about its edges. Four places htmlization doesn't work — or where it works but the juice isn't worth the squeeze.

Documents the receiver legally needs as a PDF. Court filings, regulatory submissions, signed contracts, tax filings, certain insurance claims, anything a clerk or compliance officer ingests through a fixed pipeline. The format is the format. Don't htmlize the LLC operating agreement, the EIN application, or the response to a regulator's request for production. The dead file is the right file. Reserve the link for the brief that decided you needed the agreement.

Anything that has to be e-signed. DocuSign, HelloSign, the notary's portal — the static-doc format is doing legal work, not communication work. Don't fight it. Send the boring PDF. The opportunity is the artifact that explains why the contract — that one's the link.

One-off deliverables for a reader who doesn't open links. Some recipients will not click. They are who they are. Two paths: send the file and move on, or send both — the file as the attachment, the link in the email body as "live version with the assumptions you can move." The conversion rate from the second path isn't zero. By the third deliverable, half the holdouts are clicking. The other half never will and that's fine.

Internal artifacts where the deploy overhead beats the value. Quick brain-dump, ten-line meeting agenda, Slack DM, a comment on a PR. Don't deploy a webpage to send a fifty-word ask. The whole point is that the format wins distribution. If there's no distribution problem, there's no format problem to solve. Reserve the format for the thing that gets forwarded.

The edges are legal, signature, audience, and minimum-effective-dose. Stay on the right side of all four and the rest of your pipeline moves to links. The list of things that survive as files gets shorter every quarter — but it isn't zero, and pretending otherwise makes the thesis less credible, not more.

The next thing you were about to attach to an email — don't. Spin up the private repo, drop the HTML, deploy, send the link. The mechanic is Chapter 19's Hour 2 pointed at a document instead of a product: gh repo create --private, the artifact, vercel deploy (or GitHub Pages), share the link. Updated by commit, current forever, forwardable.

The people who get it won't wait for a mandate — they'll spin up their own. That's the adoption tell from Chapter 26: when the better way is obviously better, you don't roll it out, it spreads. AFC became plausible because the artifact beat the meeting. The audit closed because the link beat the PDF. Your move is the same one, every deliverable, starting with the next one.

Related: Ch 19 — building products · Ch 26 — team adoption · The launch artifact · Launch week, live