Hand this pipeline a list of acquirers — one brand or fifty — and it hands back the second-time founders hiding in their deal histories: the people who sold a startup, finished vesting, and are quietly building again, ranked by how badly a pre-seed investor should want the meeting. I proved it across six acquirers at once — Google, Amazon, Meta, Microsoft, OpenAI, Anthropic; 806 acquisitions mined, 736 people ranked and contact-enriched — then re-ran it on Datadog in July 2026 as a small-enough-to-check demo: 19 acquisitions in, 13 live-verified founders out, under a dollar of metered spend. The Datadog roster is below, and so is the recipe to point this at any acquirer list you care about.

What is a second-time founder — and why do VCs chase them?

A second-time founder is someone starting a new company after already building and exiting one — here, specifically after selling to an acquirer and grinding through the retention package. The experience shows up in the base rates: Harvard's Gompers, Kovner, Lerner and Scharfstein measured venture-backed founders who had already succeeded once succeeding again about 30% of the time, versus roughly 18% for first-timers (Performance Persistence in Entrepreneurship, Journal of Financial Economics, 2010).

Every VC can recite that thesis. Now try to query it. Crunchbase can't filter on "finished vesting at the acquirer and building something unfunded." LinkedIn can't either. The list you want is an inference stitched from press coverage, deal dates, and what someone's headline says today — which is exactly the kind of work agent swarms eat. So the moat was never knowing the thesis; it's being able to run this query across every acquirer's deal history before the next fund does.

What one acquirer's deal history produces — the Datadog demo

One acquirer in, a short checkable roster out: 13 people, each scored 0-100 on "would a VC want to meet them before anyone else does" — role at the acquired startup, deal size, how recently their lockup opened, and what they're building now.

Statuses are inferences with confidence grades, and where someone's live profile disagrees with the press trail, I show both. That disagreement is signal, so the pipeline keeps it instead of flattening it.

The bullseye — building, no institutional round found:

• Zach Sherman (83) — Co-Founder & CEO of Timber Technologies, the team behind Vector, acquired 2021. Now building Hyper, YC-backed with no confirmed institutional round beyond it. The exact profile the thesis predicts: four-year package opened in 2025, and he's already at it.

• Valeri Pliskin (81) — Co-Founder & CTO of Seekret, acquired 2022. His live headline still says Datadog, while his own posts tease that he's "almost ready to share what we've been building." A person mid-leap, caught before the databases catch up.

Already restarted and funded — the thesis working in plain sight:

• Pierre Betouin (80) and Jean-Baptiste Aviat (77) — the Sqreen co-founders, acquired 2021 for a reported $260M. Both now on Tolmo, an AI security startup backed by Accel and YC per press coverage. Sold in 2021, vested out, building by 2025 — you could set a metronome by it.

• Ben Johnson (76) — Timber's other co-founder, now building Tero, a seed-stage observability company. Both founders of one acquired startup, both back in the arena.

• Gabriel-James Safar (70) and Sébastien Deprez (68) — the Madumbo founders, acquired 2019, now building Tsuga with a substantial raise behind them.

• Renaud Boutet (65) — Logmatic co-founder, acquired 2017; search snippets point at a new venture while his profile reads investor-advisor. Flagged, kept, and labeled with the uncertainty.

Sidelined for now — investing, advising, running services firms:

• Alon Fliess (38) and Erez Fliess (24) — Ozcode co-founders, running ZioNet, an established Israeli dev-services firm. The ranking pushes them down hard: real operators, but a services firm is a different bet than a product startup.

• Idan Gindi (22) — Seekret's CEO, still at Datadog per his live profile. Kept for context, scored accordingly.

• Amirhossein Malekzadeh (18) — Logmatic co-founder, now angel investing.

• K Young (15) — Mortar Data co-founder from the 2015 deal, now a climate investor.

One more pattern the run surfaced: every founder from Datadog's six most recent deals is still there, exactly as four-year vesting math predicts. The pipeline deprioritizes them automatically instead of listing people who can't leave yet.

The tool everyone reaches for fails without telling you

Enrichment APIs can't find alumni — none of them search past employers, and the one I use daily fails silently when you try.

My first instinct was Blitz, the API behind my contact discovery on ranked people lists. Pass it a filter it doesn't support and it ignores the filter and returns confident-looking results anyway. You'd ship a list built on a query that never ran. Probe any data tool's filters with a known-answer test before you trust them — I found this one only because I tested a filter against people I already knew.

So discovery runs on web-research agents instead: acquisition-era TechCrunch and CNBC coverage that names founders, Crunchbase and RocketReach snippets that show titles even when the pages block you, old team pages via the Wayback Machine. Blitz still earns its keep at the end, pulling emails and phone numbers once the right LinkedIn profile is confirmed. The census itself starts from Wikipedia's acquisition list pages, and blank domains get resolved by the free-first domain resolver I wrote up in June — never guessed.

Trust nothing, verify twice

Discovery agents make confident mistakes, so the pipeline treats every claim as unverified until a live profile agrees with it.

• Pull the live profile. Every candidate's LinkedIn gets fetched through a proxy that takes the URL as data — no browser, no logged-in session — and a cheap model checks the claim against it. On the Datadog run this caught two people claimed to be "building" whose live profiles show them still employed, and one URL that pointed at a same-named healthcare worker in a different country.

• Re-hunt the flags. A second agent wave re-searches only the flagged people with tighter identity requirements. It corrected the healthcare-worker mixup to the real founder's profile and confirmed the other flags were false alarms. Name collisions are the default at this scale, and the six-acquirer run had two different founders answering to "Dan Roth."

• Send the skeptic. The top tier — building-but-unfunded, the claims a VC would act on — gets a final adversarial pass from the strongest model, instructed to kill anything it can't re-verify with fresh searches. Those claims are exactly the ones most likely to be wrong, and the audit is allowed to say so.

That ladder is the difference between a lead list and a rumor list. On the six-acquirer run, the same machinery took LinkedIn coverage from 40% to 94% and dropped every false positive it caught. The franchise-operator build taught me the same lesson from a different direction: the census is cheap, and resolving who's actually behind each record is the moat.

The vesting math is the ranking

Deal year plus four is roughly when the golden handcuffs open. The scoring peaks for people whose window opened in the last two years, ramps for people whose window opens within one, and fades for people freed so long ago they've committed elsewhere. That one line of arithmetic is why 2018-2023 deals dominate the ranked list while the 2025-2026 AI acqui-hires — the deals making headlines right now — score near the bottom. The people everyone's excited about can't leave yet. The people nobody's watching just got free.

Serial founders get folded into a single row across every deal they appear in, with the full deal history attached. Someone who's been acquired twice is the strongest signal in the whole set, and a pipeline that lists them as two separate people splits exactly the signal a VC pays for.

The whole Datadog run cost under a dollar in metered API spend — the research and scoring agents ride my Claude subscription, and the paid line items are a cheap verification model plus a few search calls. The expensive ingredient is knowing which claims to distrust, and that's baked into the prompts now.

— Written by Claude Fable 5, Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

Hudlow Fire Department covers a stretch of Rutherford County, North Carolina. At some point the department stopped paying for its website, and the domain reverted to a GoDaddy parking page — an ad lot where a fire department used to be. On July 4th I asked the best-funded research AIs on the market one simple question: what's this department's official website?

OpenAI handed me the parking page. Claude handed me the parking page. Exa handed me the parking page. Three companies, three price tags, the same wrong answer — delivered with full confidence, because a parked domain still loads, and a page that loads looks alive to any machine that doesn't actually read it.

This post is the story of Crawford — the research agent I built in Claude Code that reads the page. It caught both parked domains in that test without spending a cent. Its finished proving run scored 34 of 39 hand-verified rows correct, and every answer it committed was right, for $0.77 of total spend — about half a cent a row. It also missed in ways that changed the design, and I'll show you exactly where. At the end there's a public benchmark, built so the whole market — my own agent included — gets scored the same honest way. Annual subscribers can install Crawford today.

The chip lesson

When Apple shipped its own laptop chip in 2020, the pitch had a strange shape. Intel had spent decades selling raw speed. Apple's press release claimed something else: the world's best CPU performance per watt. The fastest chip loses to the chip that does the most work per unit of power — because power is the thing you actually run out of.

Research AI in 2026 is sold the way Intel sold chips. Every vendor races on raw accuracy; the price sits in a separate PDF; and the two numbers are never printed side by side. Crawford is built on the other axis: right answers per dollar. Performance per watt, for research.

That axis changes every design decision — what runs first, when money gets spent, what the output records. And it ends in a scoreboard: the last section of this post is the benchmark I'm building that measures every tool on the market this way, with answers verified by paid humans and zero favors for my own agent.

The market, mapped

There are five shelves you can buy web research from, and I swept all of them while building this.

• Spreadsheet platforms. Clay is the anchor: the company announced $100 million in revenue last December, its January employee tender priced it at $5 billion, and the 2026 State of GTM Engineering survey found 84% of GTM engineers use it. Its research agent, Claygent, answers questions per row for credits.

• Research-agent APIs. Parallel and Exa (valued at $2.2 billion) sell research as a per-question API call. Parallel's customer list includes Clay itself, per Parallel's own funding announcement — the platform the market buys from has a supplier.

• Model-vendor search. OpenAI and Anthropic both price web search at $10 per 1,000 calls plus tokens. Bolted onto a cheap model, this is what actually runs per-row in most production pipelines.

• Data vendors with agent bolt-ons. Apollo, ZoomInfo, Cognism. These query their own databases — useful, but bounded. If the answer lives on a med spa's website instead of in their records, the bolt-on can't go get it.

• DIY inside a coding agent. Operators wiring research directly into Claude Code, no platform in the middle. This is Crawford's shelf.

Every shelf shares the same two blind spots. Nobody can read the bill: list prices are public, but the adding-up — this row took two tries on a bigger model, that column ran across 4,000 rows before anyone sampled it — only surfaces on the invoice. Henley Wing Chiu burned $700 in two weeks and wrote up his exit at bloomberry.com. Opaque credit pricing was the one complaint that came back from every category I swept.

And nobody publishes an error rate. Accuracy is buyable — in my own test, OpenAI hit 95% at $0.25 a row. Across a 30,000-row market list that's $7,500, and it still handed me both parked domains. All watts, no efficiency.

Why I built it

I verify GTM datasets for a living, and the job keeps teaching the same lesson. A dataset a client had already shipped listed 6 websites as live that were actually parked or dead — every one loads, every one passes an automated status check. A blind audit on another client's list measured roughly 65% of one data aggregator's contact names wrong. The whole doctrine I work from is knowing more about the buyer's situation than the buyer does — and that only compounds if each fact is cheap and true.

The uncomfortable discovery underneath: most of what GTM teams pay per-row for is sitting in free public sources. Government registries, open map data, public certificate logs. The market prices every question as if it needs a frontier model. Most questions need a lookup.

Why didn't I just use Claygent? Fair question — I've advised Clay since 2020, and Claygent is genuinely good. Four gaps sent me to build anyway:

• The prompts are hard. A Claygent mission that works takes real engineering — hard enough that I built AutoClaygent, a tool whose entire job is writing Claygent prompts.

• It doesn't learn from its own misses. There's no loop that builds an answer key, scores the run, and fixes the cause of each error cluster. Every mistake stays yours to find, row by row.

• The model choice is your gamble. Cheap model or frontier model changes both the price and the accuracy, and nothing measures that tradeoff on your rows before you commit a whole table.

• Every run is time-boxed. The stubborn rows — the answer buried in a state registry, the slow government site — are exactly the rows that need more time than the box allows.

So I built the thing I wanted to buy. Crawford lives in Claude Code, and the name works the way you'd hope: when a list needs verifying, you send Crawford in first.

The free floors

Every row rides the same elevator, floor by floor, and gets off at the first floor that settles it. The free floors come first, and there are more of them than you'd guess.

The web, already scraped

Never scrape what's already scraped. Common Crawl is a public copy of the web — it answers "has this domain served real content recently?" from your own laptop, before any live request. Overture Maps publishes 69 million open place records and Foursquare publishes 108.7 million more, each carrying the business's own declared website and phone. Chrome's public usage dataset covers 18.4 million websites real people actually visit. Domain zone files list which domains even exist.

And underneath all of it: government registries. Fire-department rosters, medical-license files, SEC filings, nonprofit returns. If a regulator already keeps a list of the thing you're researching, that list is the backbone — the live web is for the residue. Crawford's catalog holds 316 free sources, each one tested before it earned a slot.

The wire checks

Before reading any page, check the wiring. A domain that doesn't point anywhere is dead. A domain whose name servers belong to a known parking company is an ad lot. A domain with no mail setup probably has no organization behind it. These checks run thousands of rows a minute on a laptop and clear 10–25% of a typical job before anything else runs.

Reading the page like a skeptic

Both parked domains in my test returned HTTP 200 — the "everything is fine" signal every uptime checker trusts. So Crawford reads the body. Parked pages carry sentinel phrases they can't hide ("this domain is for sale," ad-frame scaffolding). And there's the garbage-page trick: ask the site for a page that can't possibly exist. A real site says "not found." An empty shell serves the same husk for the garbage page as for its homepage — and now you know.

The certificate heartbeat

Every website's security certificate is recorded, at issuance, in a public log anyone can read. That log is a biography. The first certificate is the site's birthday. Steady renewals are a pulse. Renewals that stop, on a domain whose name servers just moved to a parking company — that's a death certificate, with a date on it. Of every tool in my test, Crawford was the only one running this check.

The free quotas

Google's Knowledge Graph — the database behind the info boxes on a search results page — allows 100,000 free lookups a day and returns the official website Google has on file for an organization. Wikidata, Wikipedia's structured sister project, records official-website claims too. Neither is trusted alone. When two unrelated sources name the same website, the row settles — for free. When they disagree, or Google simply doesn't know the tiny volunteer fire department, the row rides up a floor instead of getting a guess.

Absence must be earned

Early on, Crawford would stamp "no website" when its sources came up empty — and a hand-check found several of those sites existed. Now the rule is structural: before any absence verdict, Crawford brute-forces about 30 naming-convention guesses learned from the batch itself (fire departments cluster around patterns like hudlowfd-dot-com) plus one half-cent search. Silence is never evidence. A row with nothing found escalates with the attempt on record.

The cheap floors

When the free floors can't settle a row, the meter starts — at pennies.

Credits you already own come first. If your Clay plan sits at 60% utilization, those credits are cheaper than any new dollar, so Crawford spends them before spending yours — and only on the jobs where Clay genuinely wins, like verified-email and mobile-phone waterfalls that bill only when a provider delivers.

Then metered pennies. A page-to-text service costs hundredths of a cent per page. One structured search call — about half a cent — goes out per stuck row, once, with the question phrased so the answer comes back in a checkable format. A small, fast model reads the fetched pages for about a quarter per thousand rows.

Crawford doesn't take the search engine's word for anything. Every answer that comes back still passes Crawford's own identity checks plus a free fetch of the answered page. On the finished proving run, that free fetch bounced a wrong-state twin and two county websites the search engine was confident about. The half-cent search floor settled 22 of the run's 39 scored rows — with zero wrong answers.

The expensive floor

The last floor is a Claude agent — one per stubborn row, and only for the rows nothing cheaper could settle. On a healthy run that's the last few percent.

The agent runs on a budget: 3 to 15 tool calls depending on difficulty, a hard stop when three sources agree, and a forced best-answer-with-confidence when the budget runs out — it can't dig forever. And it never starts from scratch. The row arrives as a packet carrying everything the cheaper floors already proved: this domain is parked, this org is in the wrong state, this source is an aggregator. Cheap facts ride along as constraints the expensive agent can't un-know. That rule has a scar behind it, which I'll show you in the trap section.

The measured price of the top floor: closing 12 stubborn rows cost $0.50 when Crawford jumped straight to the agent. Running the designed order — cheap search first, agent last — closed all 12 for $0.06. Honest label: that six-cent number is an in-sample demonstration (the search partner was picked on those same 12 rows), so treat it as proof the mechanism works, and nothing more, until the benchmark at the end of this post scores it on fresh rows.

How it can be sure

Every floor, free or paid, reports its answer with a confidence level, and Crawford enforces three bands. Nearly certain: commit the answer, write the evidence and the cost. Nearly certain the other way: commit "not found," same receipts. Everything in between gets held, never guessed. A held row climbs to the next floor, and if the top floor can't settle it either, it lands in a review queue a human can route anywhere.

Committing takes more than confidence. Four rules gate what counts as true:

• Two sources make a truth — and they can't be cousins. A fact counts when two sources with separate origins agree: the department's own site plus the state fire-marshal roster. Data aggregators never corroborate anything — that blind audit that found ~65% of one aggregator's names wrong is why. Two aggregators agreeing is one bad copy machine quoting another.

• Identity has to be proven, not resembled. A candidate website must tie to this specific organization — name, place, and jurisdiction — before it can match. A same-name fire department two thousand miles away bounces off this rule; you'll meet it in the trap.

• Only positive evidence settles a row. Missing from a database kills nothing. Presence proves; absence escalates.

• The verdicts tell the truth even when it's awkward. The proving run forced a verdict I hadn't designed: a department whose own Facebook page names its domain — and the domain's server is broken. The row now reads "their domain, no usable website." A tool that only answers "live" or "dead" would have shipped a lie in either direction.

The review queue holds tradeoff questions, with stakes attached: "spending about two dollars closes roughly 40 held rows — worth it?" Answering one question updates the run's plan. One decision fixes a category, never one row.

How it tests itself

Crawford assumes its own runs are wrong until a test says otherwise, and the test is built fresh every job.

Blind agents build an answer key first. A sample of 100–200 rows gets drawn — half random, a quarter from the rows the pipeline found suspicious, a quarter spread so every region and size of organization shows up. Separate verification agents each take just one to five rows and derive the truth from primary sources — the org's own site, the government registry, one more independent root — without ever seeing what the pipeline answered. A fact enters the key only when two unrelated sources agree. The same blind-verification discipline pulled 597 verified attendees out of a 3-minute screen recording in an earlier build; here it manufactures the exam.

Every run gets a grade out of 10. The scored run is joined against the key, and the grade weighs what a buyer would weigh: accuracy and completeness carry half the grade between them; quality of the cited evidence and cleanliness of the output carry most of the rest; cost-efficiency and consistency close it out. A run below 8.0 doesn't ship. The grade always prints next to the measured cost per row, because the two numbers together are the product — accuracy alone is the drag-race trap this whole post is about.

Misses get fixed at the cause, never the row. Wrong answers get clustered by what they share — same source, same floor, same page shape. One diagnosis per cluster, one fix to the plan, re-run the affected slice, re-score. In the first proving run, four of the five wrong answers traced to a single cause: the engine declared "no website" without a discovery step. One fix — the absence-must-be-earned rule you read three sections ago — retired all four, plus every future row that would have failed the same way.

The receipts, in order. July 3, first proving run, two 150-row slices of real client data: 8.37 out of 10 against the 8.0 bar, at $0.00 of marginal cost — free floors only, paid floors switched off, which left about half of one job's rows sitting held. (Marginal means what it says: the free floors ride on subscription compute and free quotas that fuller accounting has to price — the benchmark at the end does exactly that.) That run also caught the 6 parked-or-dead sites the client's dataset listed as live. July 4, after the fixes, full ladder on: 9.29 out of 10, 34 of 39 hand-verified rows correct, $0.77 total spend for the whole 150-row job. Every one of the 34 answers Crawford committed survived the key. All five misses were rows it held as unresolved where the truth was "no website exists" — its remaining failure mode is hesitating to declare absence, never shipping a wrong answer. One label that run has to wear: it was re-scored on the same locked key that taught the fixes. Its first test on questions it has never seen is the benchmark at the end of this post.

Then I set a trap

Those numbers came from Crawford grading itself, so I built a test where I knew every answer cold — and invited the market.

Thirty-nine North Carolina fire departments. For each: what's the official website? Twenty-seven have a real answer. Twelve have nothing, and the twelve are landmines — two parked domains that load fine, a county directory that looks official, and a twin: a real Creston Volunteer Fire Department with a real website, two thousand miles away in Kalispell, Montana. I built and locked the answer key before any tool ran, every row verified from two or three independent sources. When tools disagreed with the key I didn't trust the key either: eleven rows drew disputes, and I hand-checked all twelve rival answers live. The key survived every challenge.

What the trap caught:

• Both parked pages fooled OpenAI, Claude, and Exa at the same time. That's the Hudlow story from the top. Its sibling — a domain serving a raw parking script — also took two of Parallel's five tiers.

• The Montana twin worked. Claude matched the Kalispell department's website to the North Carolina row. So did Parallel's two cheapest tiers. Same name, wrong state, three tools.

• Claygent ran clean and hit a wall. On the rows it finished, one miss — calling a live site dead, the error that costs coverage instead of poisoning your list. Then Clay's API stopped me: "You can only test-run Clay actions directly 25 times a day." Batch scale means building inside Clay's app.

• Parallel was the strongest rival on the board — and 39 rows is as much weight as that sentence can carry, for reasons two sections down.

The failure with a name: a false alive — handing over a parked or dead domain as a live website. It's the expensive kind of cheap. A false alive sails through every downstream step — enrichment, sequencing, a rep's morning — and poisons all of them. Every tool that answered all 39 rows shipped at least one.

Including Crawford. Twice.

The first miss: on the parking-script row, Crawford's page-reading flagged the trap correctly, for free — then its matching step committed the county government's website for the same department at high confidence. The rule banning county directories existed; the guard enforcing it ran too late in the sequence. One miss, one root cause, one fix.

The second miss hurt more, because it was Hudlow — the trap Crawford had already beaten. When I paid to close the held rows through the top floor, the packet handed to the Claude agent didn't include the verdict the free floor had already earned: this domain is parked. The expensive agent re-derived from scratch and shipped the parking page — the same mistake as OpenAI, Claude, and Exa, purchased at the top of the ladder after the bottom had solved it for free. That miss became the design rule you already read: verdicts travel with the row.

Here's the full board, sorted by the number this post is about — measured price per right answer, cheapest at the top. Read it with its labels on: these are preliminary numbers from a 39-row probe, the full Blueprint Bench hasn't run yet, and at this sample size the gaps between the good tools sit inside the noise.

*Claygent's run stopped at Clay's 25-a-day cap — 15 rows never ran, and its completed subset skews toward the easier rows. Crawford's $0.00 is marginal cost only; its free floors ride on subscription compute the benchmark below prices at list. Crawford's two rows here are its pre-fix numbers, measured the same day as everyone else's — the 34-of-39 run from the previous section came after the fixes this trap taught, so it doesn't get to sit in this table. And at this sample size, the gaps between the good tools sit inside the noise — which is the next section.

Why nobody gets crowned

I had the victory post drafted — a dollars-per-right-answer column with Crawford's answers coming in 16 times cheaper than OpenAI's. Then I ran the same adversarial review on my own scoreboard that Crawford runs on its own output, and three flags killed it.

The best composed number was circular: I'd picked Crawford's escalation partner by watching it ace those exact 12 rows, then scored the pair on the same rows. The $0.00 wasn't the whole bill: Crawford's free floors ride on subscription compute, while every rival was billed at list — two accounting systems in one column. And 39 rows can't separate good tools: when I later ran the proper statistics on a bigger draw, no two tools on the board were distinguishable, and that math was right about the 39 too.

Every incident above survived the review — the parked pages, the Montana twin, the daily cap, both of Crawford's misses. They're dated, hand-verified, and sitting in a committed run directory. The ranking died. What replaced it is the last section of this post.

Where the rivals win today

The incumbents beat Crawford on real dimensions, and pretending otherwise would fail the same review:

• A spreadsheet a non-engineer can drive. Clay's UI is the reason 84% adoption happened. Crawford is dispatched from Claude Code — my RevOps friends don't live there. Yet.

• CRM writeback. Clay lands enrichment in HubSpot or Attio automatically. Crawford ends at a CSV.

• Pay-on-delivery waterfalls. Clay's contact waterfalls bill only when a provider actually delivers. Crawford writes down its spend but doesn't yet route on pay-per-hit versus pay-per-attempt.

• Watching for changes. Parallel and Exa both sell re-research when something changes. Crawford runs batches; it doesn't watch.

• Calibrated confidence. Parallel publishes evidence that its confidence scores mean what they say. Crawford's are self-reported — its harness generates the data to check them, and nobody's drawn that curve yet.

• Speed. The rivals answer in seconds, fast enough for inbound triage. Crawford is built for batch depth, and a hot lead won't wait for it.

• Hostile websites. The proxy infrastructure that gets past bot-blocking sites is real, and Crawford doesn't have it.

• Someone else keeping score. The rivals get benchmarked by third parties. Crawford's only tests so far are ones I ran myself.

That last line is the setup for the ending.

Blueprint Bench: performance per watt, scored

I went looking for the benchmark I should be citing instead of my own. I tried to trace the flagship accuracy numbers three major vendors publish; none of the three led back to anything checkable. Web-research agents get measured on essay-writing benchmarks. Nobody scores them on a med spa's website — the questions GTM teams actually pay per-row to answer.

So I'm building Blueprint Bench: the per-dollar benchmark for GTM web research, with answers verified by paid human panels and zero favors for the house.

• A thousand fresh questions every quarter — ten question types, drawn live from public registries days before the run, so no model can have memorized them. Is this the business's website. Is this domain alive or parked. Who runs this org today. Does this person still work there. Whose email is this.

• Every answer findable on the open web. Only one single allowed gated source for B2B profiles. Licensed private datasets are banned as questions and as truth.

• Each question type carries its own named trap — the failure that costs real money: shipping a parked site as live, naming the previous chief instead of the current one, pattern-guessing an email nobody published, merging two people who share a name.

• Truth comes from two panels of paid humans who never see each other's work. One panel judges the documented evidence. A separate panel researches every question blind, from scratch, no hints. A fact enters the key only when both panels and the machine derivation agree — and where the two panels disagree, that gap gets published too, because it measures how much evidence-framing sways people.

• The house plays by visitor rules. The answer key's digital fingerprint posts publicly before any tool runs. Crawford's configuration is frozen and fingerprinted before the questions are even drawn — anything I tune after seeing results waits for the next edition. Every scored vendor reviews its own rows before the board publishes. Retired editions are open-sourced in full, with tripwires that expose anyone training on them. Crawford competes; it never referees.

• The headline metric is Total Cost to Clear — the performance-per-watt number: what it takes to get 1,000 rows actually finished. The spend, plus a price on every wrong answer, plus the cost of routing every held row to something that can close it. Crawford's subscription compute gets priced at list like everyone else's. A free tool that ships poison stops looking free.

Where it stands: the harness is built and passes its 123 automated tests. A 54-row pilot has been drawn, keyed blind, and run against three cheap tools — total contestant spend, $1.08. The trap machine already works: one drawn business's domain expired two days before the draw and now serves a parking page, and two of the three tools handed it over as a live website. One fire department's chief can't be named from the entire open web — the roster literally reads "Chief Unknown," with two plausible wrong names one town over, waiting to be guessed. The blind human panel has come back: on all 13 rows where both hired researchers committed an answer, they matched the machine-built key, and the two rows humans got wrong both validate the traps. The evidence panel is still in its vendor's review queue. Crawford has not been scored on any of it.

And the early numbers cut against the house: on the small pre-Bench data, the best buy on the board is a rival's cheap tier, and pricing Crawford's subscription compute at list can only move Crawford's costs up. Crawford enters its own benchmark as the challenger. If it wins, you'll watch it earn that quarterly, on fresh questions, under a key it can't touch. If it loses, you'll see that too.

First full edition — all ten question types, the full board, Crawford included — is next. Estimated cost to produce: $400–580. Then every quarter, fresh.

— Written by Claude Fable 5, Approved by Jordan

Who Gets This

Above this line: the story — the market, the machine, the trap, and the benchmark. Below it: the exact build — floor by floor, rule by rule, formula by formula.

• Free: the story you just read.

• $50/mo (most readers start here): the build mechanics — every rung of the ladder with its real thresholds and tools, the adjudication rules, the answer-key harness and its grading formula — plus the Bench internals: all ten question types with their named traps, the two-panel truth pipeline and its consensus math, the neutrality mechanics, and the metric Crawford has to win.

• $2,499/yr: Every tool I ship. Edge Copilot is how you talk to all of it through Claude Code. Current tools: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor, LinkedIn Engagement, Domain & LinkedIn Finder, Dossier Builder, PDF Contact Finder, TAM Contact Harvester, Find a Rep, Blueprint Playbook, Crawford. Whatever ships next is included. Plus all 3 courses + weekly office hours.

Read more

Every revenue team bought the same AI. So everyone sends the same email — same opener, same "saw you're hiring," same "congrats on the raise."

Here's the thing about average. AI is a machine for producing it. Feed it the prompt everyone feeds it and you get the same competent, forgettable paragraph everyone gets. Average is free now, and nobody reads the floor.

What gives you the edge is what you know about a buyer's situation — and about the competitors circling them — that they can't see for themselves. So I built a tool that goes and finds it.

What it does

You hand it one company's website. It hands back a GTM playbook — who to target, the public data that proves they're in pain, and the messages to send — in about twelve minutes.

Here's a run, start to finish. Say you sell safety-compliance software, and your buyers are plant safety managers.

• It reads your site and works out what you sell and who feels the pain.

• It goes hunting for public records that prove a plant is in trouble right now — and lands on OSHA's enforcement data. Every serious workplace-safety violation a U.S. employer gets is public record, with an inspection number, a date, a violation type, and a dollar penalty.

• It builds a segment the list-sellers don't have: plants the government cited for a willful or repeat violation in the last ninety days — the exact thing your product prevents.

• It drafts the outreach — a message that names the inspection, the date, and the penalty, and hands the reader something useful about it without asking for anything back.

• It shows the math behind every number it used.

That's the shape. You give it a URL; it gives you a play grounded in a record the buyer can click.

A few it's already built

The safety example up top is illustrative. These are real. Point it at a real company and it does real work — hundreds of these are already public. Here are ten, each grounded in a public dataset you can go check yourself:

• Fiserv — FDIC enforcement actions, CFPB complaints, and FFIEC deposit data to find ZIP-level customer-underservice gaps.

• Everlaw — PACER federal court records to flag privilege-log gaps before opposing counsel does.

• BeyondTrust — the HHS breach portal to reach healthcare facilities right after an insider breach.

• Vantage Risk — EPA violations and OSHA serious-to-willful reclassification deadlines for oil & gas risk.

• ArrowStream — 130,000+ restaurant purchase orders and state health inspections to show distributors their pricing gaps.

• DoorLoop — HUD inspection scores and expiring housing contracts to find failing affordable-housing properties.

• Deenova — CMS infection metrics and state sterilization citations to surface hospital instrument-tracking failures.

• ComplyAuto — OSHA Establishment Search and FTC Safeguards breach data for dealerships nearing a willful violation.

• AGRIVI — the FDA Food Traceability List and USDA data to reach farms against FSMA deadlines.

• CHA Consulting — FTA grants and EPA water-permit data to find transit and water utilities with budget gaps.

Different industry every time. Same move: a public record nobody else bothered to read, turned into a reason to call.

Want one for your own company? Generate it at playbooks.blueprintgtm.com — or browse the rest by industry while you're there.

Why this works when "punchier copy" doesn't

Most people aim AI at the email — make it sharper, write ten variants. That's polishing the floor.

The records are where the edge is. Court filings, regulatory orders, permits, license actions, inspections, government data job by job — all public, all sitting there. No human can read all of it. AI can read thousands of those records, find the three that matter, and pull the exact number, date, and dollar figure that proves the pain.

When you know exactly who's in pain and can prove it with a record, the words barely matter — but you still have to write them.

I built it to sound plausible. Don’t believe AI’s bullshit.

The engine is built to produce very plausible output. So the messages it drafts look finished. They aren't.

The engine nails the targeting — the right segment, the real record, the proof. Then it drafts the outreach, and the draft reads like a robot reading the database back to you. Specific, competent, lifeless.

So the draft is a starting point. You take the angle to a real customer who lives in that pain and ask them if it lands. Then you write the note yourself, like someone who actually understands the situation.

The machine manufactures the playbooks. You still evaluate them and write the message. That last mile is yours.

You can run this engine yourself now

I've been a Clay advisor since 2020, and for years my team built these plays by hand for clients. We packaged the method into a tool.

Give it one company's website — yours, or an account you want to land. It runs the whole pass: reads the site, works out who they sell to, scans public records across fifty-plus sources, scores the segments against the same gates we use internally, and drafts two pain-qualified messages and two permissionless-gift messages — each with the math behind every number.

The first door is done-for-you. Go to playbooks.blueprintgtm.com, type in a company website, and a full playbook comes back in twelve to fifteen minutes. It's $49.99. One company, one time. No subscription, no account to babysit.

The second door is for people who want to run it again and again — and who want to see exactly how the engine decides what's real. That's below.

— Written by Claude Opus 4.8, Approved by Jordan

Who Gets This

Above this line: what the tool does, and why pointing AI at public records beats sharper copy. Below it: the full run, step by step, on a worked example — and what a finished play actually looks like.

• Free: what it does — the public records it pulls, how it turns them into a segment, and why the draft copy still needs you.

• $50/mo (most readers start here): the whole engine on one example — how it locks the problem, builds a niche with a data moat, lists the exact record fields it'll use, grades its own confidence, scores a message the way the buyer would, and the anatomy of a finished play with the worksheet behind the number.

• $2,499/yr: Every tool I ship. Edge Copilot is how you talk to all of it through Claude Code. Current tools: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor, LinkedIn Engagement, Domain & LinkedIn Finder, Dossier Builder, PDF Contact Finder, TAM Contact Harvester, Find a Rep, Blueprint Playbook. Whatever ships next is included. Plus all 3 courses + weekly office hours.

Read more

Somewhere there's a post that says there are only twelve real marketing channels.

I don't even remember where I saw it. But it stuck, because it can't be true. Twelve might be the menu. They are not the answer for any one buyer. So I sat down and built a tool to find the real answer — for any market — and recorded the whole thing.

The premise: point it at a market — lawyers, home services, dentists — and it hands back a ranked list of the best ways in. Not the twelve we all know. The specific channels where those buyers actually pay attention, what each costs, why it's the bet, and how to test it cheap.

Most channel advice starts from the channel. Meta, LinkedIn, SEO, a conference — pick one, go. That's backwards. You should start from your channel experiments of the past and market exploration of ways to reach your buyer.

Build the picture in concentric circles

The first thing I told it: don't start from the channel. Start from the buyer, and work in concentric circles.

Innermost — world knowledge. Before anything, go learn the buyer. If it's lawyers: where do they gather, which associations run their world, what do they have to do every year to keep their license. That grounds everything after it.

Outward — market wisdom. Someone has already tried to sell to these people. Find the case studies. Find the marketers who target this exact buyer and read what they did. There's wisdom in markets — if every competitor sponsors the same conference, that conference matters.

The other direction entirely — the buyer's own voice. Work backwards from what real buyers have said: where they first heard about a vendor, the words they use. I've mined recorded sales calls for exactly this before; it's some of the best signal there is, and almost nobody does it.

Three ways of looking at the same market, each strongest at a different job — and I had them argue with each other.

The part I couldn't stop thinking about: where are they forced to be?

While I was building this, I dropped the same question into ChatGPT and Claude and used them as sparring partners. I do this constantly — it's a cheap way to surface the thing you didn't think to ask.

And one of them said it. Internet data misses the channels that matter most — local reputation, referrals between attorneys, the places lawyers are required to show up.

That's when it clicked, on camera. Lawyers have to earn continuing-education credits every year. They pay dues to a state bar. They file through systems they can't opt out of. Nobody lists "continuing education" as a marketing channel. But every single lawyer has to be there.

So I made it a principle, not a legal trick: for any buyer, where are they legally or ethically compelled to show up? When your buyer is required to be in a room, that room is the best channel you've never bought. That's the alpha — underpriced, high-trust, and everyone else is looking past it.

Wide first, then deep

Here's the order I made it run.

First, breadth. There are maybe ten to fifty channels you should always evaluate — paid search, Meta, LinkedIn, Reddit, email, partnerships, associations, podcasts, newsletters, conferences, the lot. Pull them all, judge nothing yet. Then a second, smarter pass that hunts for the channels the checklist would never name — driven by questions about your specific buyer: where are they compelled to be, who do they trust, where do they go looking when something breaks.

Only then does it go deep — pressure-test the contenders, find the real audience size, the real cost, the real contact, and cut the long tail.

Most people skip the wide pass. They optimize the one channel they already picked. That's how you miss the cheap attention nobody else has found.

How it actually runs

Under the hood it's a swarm of Claude agents at once. One group studies how other people have solved channel discovery — before it ever looks at my own tools, so it isn't anchored on what I already have. Another group argues about how to build the buyer picture. Then one agent per channel, each hunting for hard proof: is this really where these buyers gather and trust? A second set of agents checks that work, a verifier signs off, and only the conclusions come back to the main agent — so it never drowns in detail.

And the score is not the AI's opinion. Each agent gathers the evidence; code turns it into the rank, from a fixed scorecard of eight things — how tightly the buyer clusters there, whether real buyers say that's how they found you, whether customers from that channel actually stick around, how contested it already is. Same evidence in, same number out, every time. It can't drift on a mood. It also won't trust a link until an agent has opened the page — the real group with its member count, the real sponsor page — not a homepage that looks right.

The real test: make it rediscover what I already knew

Here's the rule I set, don't bake in the legal answers. Bake in the thinking — "where are they compelled to be," "who do they trust" — then run it on lawyers and see if it finds the answers on its own. If it doesn't, the principle is wrong, not the lawyer.

So I ran it twice. Once knowing what I knew. And once cold — a blind pass with the buyer profile stripped of every answer I'd fed it.

It found them. On the cold pass it named the state bar, mandatory continuing education, the practice-management software lawyers live in, and the peer groups where they actually talk — on its own. The compelled-channel idea I'd only just had on camera, it rediscovered from first principles.

All in, it scored 330 channels and ranked them. 31 came back genuinely underpriced. 27 were openings the business wasn't using at all.

None of it came clean on the first run. Running too many of the heavy checking agents at once kept tripping a rate limit, so I throttled them. The first links it handed back looked right and were wrong — a "real" Facebook group that was the wrong group, a subreddit that resolved to a dating board — so I made it open the page and prove the link before trusting it. And it kept giving me bare names: a person, no title, no reason to believe them. Useless. So I made it find the actual role, a real contact, and a Monday-morning next step for every channel. A ranking isn't a deliverable until every line is something you can do.

Lawyers were just the guinea pig. Next I point it at a market that has nothing to do with law. If it holds up there, it graduates.

— Written by Claude Opus 4.8, Approved by Jordan

The whole build is below — about 26 minutes of me thinking out loud, using two AI models as sparring partners, and shaping the plan in plain English. Then the part every channel guide skips: exactly how the tool scores a channel, the eight tests it runs on each, and how to install it and point it at your own market.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

I'm not an engineer. I run an AI that writes code, builds lists, digs through public records — and before it does any of it, it shows me a plan and asks, basically, "good?" I say good. It goes.

That little "good?" is the most important moment in the whole thing. It's the contract. It's me signing.

And for a long time the plan I was signing looked like a parts catalog. A wall of file names, settings, and command lines. The engine bay, not the dashboard. I'd skim it, not really understand it, and say "good" anyway.

You've done this. We all do this. We rubber-stamp the thing we can't read because the machine seems confident and we're busy.

Rubber-stamping a plan you can't read is like signing a contract in a language you don't speak because the other side smiled. Most of the time it's fine. The one time it isn't, it costs you.

This month, it almost cost me about $700.

What is plan mode, and why does the plan matter more than the code?

Plan mode is the step where the AI shows you what it's about to do before it does it. For anyone who can't read code — most founders, most revenue leaders, most buyers — that plan is the whole surface you get to judge. Read the plan, catch the mistake. Can't read it, and you're trusting the machine on faith.

So the plan is the product you're actually approving. You'll never look at the code. The plan is where you either catch the problem or sign it.

Can you trust AI coding agents?

Not on faith. You can't trust the code if you can't read it, and most people can't. What you can trust is the plan the agent shows you first — but only when it's in plain English and its numbers add up. People are asking this out loud right now: "Can AI agents be trusted?" is a live question on Google as of June 2026 (DataForSEO). The honest answer is that you trust what you can check, and the plan is the only thing most buyers can check.

So I changed the plan. I taught my AI to write the thing it asks me to approve like a newspaper brief instead of a parts catalog. I call it Plain Plan Mode. Four things make it work:

• Plain English, ninth-grade. Short sentences. If a 12-year-old couldn't read it aloud and know exactly what they're approving, it gets rewritten until they can.

• A real "how," in plain words. It still has to tell me the method — which tools, wired together how — but it names a tool the way a newspaper would: "a web-research engine built for AI," not its insider code name. I approve the method, not a mystery.

• Five little symbols, each meaning one thing. What you get. What it costs. A warning. A question for you. Your move. Your eye learns them in one read and routes itself.

• An honesty rule on every number. This is the one that saved me.

What's the real risk of letting an AI build for you?

The dangerous mistake is the plausible one — a confident, clean, wrong number you approve because it looked right. You'd catch an obvious error. This kind wears a tidy headline and slides straight past you.

Here's the honesty rule in plain terms: if two numbers in the plan multiply into a third, they have to agree. Per-item price times the number of items has to equal the total. Sounds obvious. Machines break it constantly, because they write the headline and the line items in different breaths and never check them against each other.

While I was testing Plain Plan Mode, a sample plan headlined its cost as "$50 to $75." Cheap. Easy yes. But down in the same plan, the per-item price times the number of items came to about $700. Roughly ten times the headline. The AI had written both numbers itself — and never noticed they disagreed.

The rule caught it. The plan got bounced back and rewritten before it ever reached my "good?" On a real run, that's the gap between a fifty-dollar yes and a seven-hundred-dollar surprise on a card.

And these aren't toy jobs. Earlier this month I cleaned 1.34 million public franchise location records down to about 60,000 real multi-unit operators — the kind of list that's worth real money — where the final step is a small paid look-up on every single row. That's exactly the shape of plan where a quiet cost error hides: a cheap headline sitting on top of a big job. You'd approve it. I almost did.

How do you review AI work when you can't read code?

You stop trying to review the code and you make the plan reviewable instead. A plan you can read is a plan you can argue with. When the plan is in plain English, names its tools in plain words, and proves its own numbers add up, a non-engineer can do the one thing that actually matters: spot the thing that's wrong and say "wait."

That's the whole game. The AI got faster than any of us can check by hand. So you force it to show its work in a language you speak — and to prove its own math before it asks you to sign.

I built this for myself because I sign these contracts every day. Then I made it the default for everything I do, and shipped it. The before-and-after isn't subtle: the same job, once a wall of jargon I'd have waved through, now a half-page brief that catches its own lies.

The plan is the contract. Make the contract readable, and you stop signing things you can't see.

(If you want the deeper version of this idea — manufacture more information about a situation than the other side has, then hand it over plainly — it's the same instinct behind the Asymmetry Engine.)

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the plan style I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

An advisory board is supposed to do work. Open doors you can't open yourself. Give you air cover when you walk into a deal. Lend weight to your name in a market that doesn't know it yet.

Most boards get assembled from the people the founder can already see — three friendly customers, an investor's buddy, the advisor who said yes fastest. You put the headshots on a slide, hand over a little equity, and the board sits there. The people are fine. They just don't move your market, because the people who move a market are mostly people you've never met.

So the move is to go find them. Score an entire industry's influence graph from the top down, rank the people who actually shape what the market buys, and build the board from that list. I built the machine that does it. Here's the method on a real run, then the recipe.

Who actually shapes what your industry buys

The question that builds a real board is about the market. Who sits on the standards committee that writes the spec your product gets measured against. Who chairs the association whose endorsement opens a hundred doors. Whose column every buyer in the category reads on a Tuesday morning.

Pharma and medtech marketers have a name for these people: key opinion leaders, or KOLs — the handful in any market whose voice moves what everyone else buys. Most industries have KOLs without using the word. The usual KOL list ranks the obvious names: the big titles, the famous brands, the people you'd reach for off the top of your head. Score the whole market properly and the real ones surface. The real ones are exactly who belongs on your board.

You can know who they are, better than the market knows it about itself. That's the whole move.

The asymmetry, pointed at relationships

I write a lot about manufacturing more information about a buyer's situation than the buyer has, then handing it over as a gift. People usually apply that to outbound. It works just as well on the question of who to build a relationship with in the first place.

A market's influence graph is public — it's just scattered. Association board rosters. Technical standards committees. Conference keynote lists. Trade-press mastheads. Nonprofit tax filings that show who sits on which board and at what scale. Archived bios that reveal a role someone quietly scrubbed. None of it is hidden. It's annoying to assemble by hand, so assembling it is an edge. That's the thing I built.

Score the whole market, not your contacts

You score the whole market, not the slice you already know. The people you know are a biased sample — they're the ones who already talk to you. The influencers worth recruiting are mostly the ones you've never met.

So you go top-down. Take the whole geography of a market. For a US run, that's the 50 states plus DC. Region by region, you ask one open question: who are the most influential people here? You point a research agent at each region with real tools behind it — a web-research engine built for AI, a cited-answer research service, public nonprofit filings. Each agent comes back with a short, sourced list of the market-shapers in its patch. You merge them. Now you have a draft of the influence graph for an entire industry, built from authoritative sources instead of from your CRM.

Then you score it.

Influence is sparse

I ran this for a company that sells software into a regulated public-safety market. The named universe was about 16,000 people. I scored every one against eight dimensions of real influence: association leadership, government and standards advisory, vendor roles, speaking, authorship, credentials, the scale of their platform, and their reach among peers. Exactly 441 cleared a meaningful influence bar.

Less than 3%.

That number reshapes the whole approach. Ranking everyone flat wastes most of the budget on the 97% who don't move anything. So the work is a funnel: triage cheaply, then spend the expensive, careful research only on the slice that might clear the bar. And when you find the real influencers, there are far fewer of them than the market pretends — that scarcity is exactly what makes knowing precisely who they are worth so much.

Title is a separate thing from influence. A chief of a giant department who never speaks, never writes, and sits on no board moves the market less than a retired chief who chairs a national committee. The model scores the seat, the byline, the board, the dated and documented role. The size of the org on the business card counts for very little.

Capture: the best name is often already taken

A plain "most influential people" list will quietly ruin your board.

In that run, the single highest-influence person in the entire dataset was already on the payroll of a competing software vendor. A past national-association president. A textbook author. The kind of name that opens any door in the industry — and completely unavailable to you. Rank by raw influence and you'd spend months courting the one person guaranteed to say no, handing a competitor a look at your roadmap on the way.

The same pattern repeated across the top of the list: a standards-committee member who was a named spokesperson for one competitor, a state-association officer who turned up in a competitor-sponsored conference session. Great intelligence. Wrong board picks.

So influence alone is the wrong score. You need two more axes.

Influence × independence × recruitability

You rank each candidate by multiplying three numbers.

Influence. How much they actually shape the market, scored from evidence, not titles.

Independence. Whether they're already captured. You find every software and vendor tie a person has, then check it against your own list of competitors. Someone employed by, advising, or speaking for a rival is competitive intelligence, not a candidate.

Recruitability. Whether you can realistically win them. A retired past-president with time on their hands and no exclusive ties is a very different prospect from a sitting executive locked to a competitor.

Multiply, don't average — that's the point of the design. A near-zero on any one axis tanks the whole score. The captured legend with influence 0.93 and independence near zero multiplies down to nothing and drops off the board shortlist, landing on a separate competitive-intel list, which is exactly where that person belongs. The retired chief with strong influence, full independence, and time to give rises to the top.

What comes out the other end is two lists. A board shortlist — the independent, recruitable, genuinely influential people, each with the evidence for why they matter and the angle for how to approach them. And an intel list — the high-influence people your competitors already locked up, which is its own kind of gift.

One is a logo collage. The other is a board that does something.

Who Gets This

The method above is the free part. The build that produces those two lists is the paid part.

• Free: the method — score a market top-down, separate influence from title, and catch competitor-capture before you recruit.

• $50/mo (most readers start here): the build below — the exact pipeline, the per-stage tools, the rubric, and the cost discipline that keeps it cheap.

• $2,499/yr: Every tool I ship. Edge Copilot is how you talk to all of it through Claude Code. Current tools: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor, LinkedIn Engagement, Domain & LinkedIn Finder, Dossier Builder, PDF Contact Finder, TAM Contact Harvester, Find a Rep. Whatever ships next is included. Plus all 3 courses + weekly office hours.

Read more

The first number the data handed back was a fantasy. It said their webinars had created tens of millions in pipeline. More than the company books in a year. Every webinar looked like a hit. The report was useless. It was counting credit nobody earned.

So I built a webinar performance report that tells the truth. Then I pointed the same engine at my own sales calls to decide what to write next. This post is what it picked.

TL;DR

I built a four-tab webinar report from live Salesforce, ON24, and HubSpot data, in a day, in Claude Code. The hard part wasn't the dashboard — it was attribution. The naive way to credit a webinar (count every deal an attendee touched) over-counts by a mile. The honest way lives in a Salesforce object most teams never open: native Campaign Influence. The last tab answers "what should we run next" by mining real customer calls for demand and checking it against search volume — and I ran that engine on 300 of my own calls to choose this very topic.

The first number was a lie

Here's how almost every webinar report attributes pipeline. Take everyone who attended. Find every opportunity those people are attached to. Add up the pipeline. Call it "webinar-influenced."

That number is garbage, and it's garbage in a specific way.

A person attending your webinar and later showing up on a deal is not proof the webinar created the deal. Half the time the deal already existed. The person was already in a sales cycle, and they registered for a webinar on the side. More than a fifth of the deals this method "attributed" to a webinar were created *before* the attendee ever showed up. You can't influence a deal with a webinar the buyer hadn't attended yet. The median gap between the rest was about three months.

So the method double-counts in two directions at once. One deal gets credited to every webinar anyone on it ever touched. And deals that predate the webinar get scooped in anyway. Stack that across a hundred webinars and you get a pipeline number bigger than the company.

That's the report I was handed to improve. Fixing it meant finding where the truth actually lived — better arithmetic on the same bad data would have produced the same fantasy.

The rollup fields were dead

Salesforce has fields built for exactly this. On every campaign there's a count of opportunities, a count of won opportunities, a total amount. Open them up and you'd know what each webinar drove.

They were all zero. Every webinar campaign read zero opportunities, zero won, zero dollars. Across the whole org, only a handful of campaigns had anything in those fields at all, and the won-dollar rollup was zero everywhere.

A dead field is its own kind of signal. Something else was carrying the real attribution. I sent a second Claude session to find it while I kept building the dashboard. (Two agents, two branches, one report — more on that below.)

The truth was in Campaign Influence

The other session found it. Salesforce's Customizable Campaign Influence was switched on and fully populated — tens of thousands of influence rows, thousands of them tied to webinars. That was the system of record — not the dead rollups, not the contact-role guesswork.

It ships with two ways to credit a touch, and the difference turned out to be the whole ballgame:

• Sourced — the single-touch model. The webinar was the primary campaign on the deal. It gets full credit. This is the conservative, defensible "this webinar drove this deal" number.

• Influenced — the multi-touch model. The webinar was one of several campaigns that touched the deal, each sharing credit. Broader, still native, still honest.

Two numbers, both true, both pulled straight from Salesforce instead of invented on top of it. Sourced is what you defend to a board. Influenced is what you use to see a topic's full reach. The inflated contact-role number didn't disappear — I kept it, but relabeled it as what it actually is: engagement reach, not pipeline. Who showed up around a deal. Never the headline.

That relabel is the whole job. The same rows, told honestly.

The four tabs

Once attribution was honest, the report wrote itself. Four tabs, one dataset, all sortable and filterable, built to be wrong in places so the team could tell me where.

• Webinars — every webinar: registrants, who attended live vs. watched the recording, attendance rate, average minutes watched, email open and click rates, and the native sourced and influenced pipeline beside each one. One row per webinar. Click any column to sort.

• Topics & products — the same numbers rolled up by product line and by webinar type. This is where "fewer registrants, more conversions" jumps out — the small, sharp webinar that out-earns the big-tent one.

• What to run next — the demand engine. Covered below; it's the interesting one.

• Deals — the opportunity lens. Every deal in the last year with real revenue and at least one webinar attendee at the account, expandable to the people who attended and which webinars they sat through. Honest framing: this is reach around a deal, shown next to the sourced number so nobody confuses the two.

What to run next — and the part that's a little meta

The last tab is the one I care about most. It answers the question the team actually asked — what should we run next.

It works in two passes. First, customer demand: mine real sales and discovery calls for the problems people keep raising, in their own words, and rank topics by how often they come up. Second, market demand: take those topics and check what people actually search for. A topic that's high on both is a layup. A topic that's high in your calls but nobody searches is a different, better kind of opportunity — you can own it, because no one's writing about it.

Now the meta part. To prove the engine works without touching client data, I ran it on my own. Three hundred of my GTM sales calls and podcast episodes. A swarm of ten agents read the transcripts and clustered them into the themes revenue leaders raise with me over and over. Then I checked each theme against live search volume.

The two rankings don't match — and the mismatch is the product:

• Reverse-engineer your ICP / go narrow — Calls: ●●●●● · Monthly searches: 1,600 · Verdict: Run now

• Outbound messages they'd pay to receive — Calls: ●●●●● · Monthly searches: 1,600 · Verdict: Run now

• Build a TAM from public data (when the databases don't have your buyer) — Calls: ●●●● · Monthly searches: 10 · Verdict: Own it

• AI agents that research accounts at scale — Calls: ●●●● · Monthly searches: 1,600 · Verdict: Run now

• Score & prioritize the TAM (who to call first) — Calls: ●●● · Monthly searches: 210 · Verdict: Own it

• Prove outbound worked (attribution to pipeline) — Calls: ●● · Monthly searches: 880 · Verdict: Market-led

• AI SDRs — do they actually work — Calls: ●● · Monthly searches: 1,900 · Verdict: Market-led

• GTM engineering (without engineers) — Calls: ●● · Monthly searches: 2,400 · Verdict: Market-led

Look at the third row. "How do I build a list of my buyers when ZoomInfo doesn't have them" is the third most common pain in my calls — and almost nobody searches for it. Ten people a month. That's a topic with real demand and no competition — the people who have the pain don't know the words to Google. The thing your customers struggle with most is rarely the thing they search for. Search rewards the topics everyone already writes about. Your calls reward the ones only you can hear.

The engine put "prove outbound worked — attribution to pipeline" on the list too. Which is the build you just read about. So I'm writing it. The tool picked its own topic.

A note on what this wasn't

Running alongside this, separately, was a different job: the same client had pruned their webinar audience too hard, and we ran a recovery to find and re-qualify the right contacts to invite back. That's real work and it fed the same report's audience — but it's a different machine (contact discovery, not attribution), so I'm keeping it out of this story. It deserves its own.

— Written by Claude Opus 4.8, approved by Jordan.

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself — the prompts I actually typed are right here.

Or don't. Annual subscribers install the tool I built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

"Make the pricing page look like Linear's."

That's what I told Claude. Clean dark cards, one accent color, type doing the heavy lifting. Claude said sure, reached for its web tool, and pulled up linear.app/pricing. A few seconds later I had a pricing page. It was fine. It was also generic — three rounded cards, a purple-ish gradient, Inter everywhere. It rhymed with Linear the way a hotel-lobby cover band rhymes with the original.

Here's what happened under the hood. When you tell Claude to copy a page off the web, it fetches that page. A fetch returns the page's text — the words, the prices, the feature bullets. It does not return the pixels, and it does not return the CSS. Claude never saw Linear's design. It saw Linear's word list, then painted the rest from the average of every pricing page it has ever absorbed.

That average is the slop. It's the same reason AI-written copy sounds like everyone and AI-built UIs look like a template store. The model fills the gap with the most likely thing, and the most likely thing is, by definition, what everyone else already has.

Generic carries a real cost. People judge a page's visual appeal in about 50 milliseconds, before they've read a word (Lindgaard et al., 2006). Stanford asked 2,684 people what made a site credible, and the single most-cited factor was how it looked — 46.1% of the time, ahead of the content itself (Fogg, Stanford, 2003). McKinsey tracked 300 companies for five years; the top quartile on design grew revenue 32 percentage points faster than their peers (2018).

Design is the product's first argument. The average loses it.

And the slop is already shipping. 22% of designers now use AI to draft entire interfaces, and only 58% of them think it improves the quality of their work (Figma, 2025).

Capture, don't describe

The fix is one rule: capture, don't describe.

For every page worth stealing from, render it in a real headless browser and grab two things. A screenshot, so Claude can see the layout and the feel. And the actual computed CSS — the real fonts, the real hex colors, the real corner radii, the real shadow sitting on the real card. Then build from those exact values, not from a memory of what a pricing page looks like.

That's the difference between "vaguely inspired by Linear" and reproducing the craft. I wired it into a Claude Code skill and called it Steal This Design. Point it at the kind of page you're making, it finds the best real examples, renders each one headless, and pulls a build-ready sheet of the exact design values behind it.

The screenshots up top aren't mock-ups. That's fifteen live pricing pages — Linear, Stripe, Vercel, Attio, Figma, Notion, Clerk, Resend, Supabase, Render, Sentry, Webflow, Cal.com, PlanetScale, Liveblocks — each one captured the same way: a real browser, a real screenshot, and the real CSS underneath. Look at any tile and you can name the move worth stealing. Stripe puts two pricing models on one page without it turning into noise. Attio walks you "from zero to IPO" and gives the popular plan real visual weight. Linear just shows restraint.

The first version taught a class. I wanted a decision.

The first end-to-end run produced a beautiful design study and buried the decision at the very bottom.

Five pricing patterns, laid out in a grid, each one explained. Here's what tiered cards are good for. Here's when a usage model reads clean. Here's the comparison matrix. It was genuinely useful and it was the wrong shape, because the one thing I actually wanted — which one should I ship? — was the last thing on the page.

A study makes the reader do the deciding. I didn't want a syllabus. I wanted the call, up top, with the reasons under it.

It got worse when I looked closely. The page shipped a real bug — a "Most Popular" pill on the recommended card, sliced clean in half. Classic CSS trap: the badge was a little absolutely-positioned element nudged up past the top edge of its card, and the card was set to clip anything that spilled past its edges. So the browser dutifully chopped the badge. The kind of thing you'd never notice in code review and can't miss the second you actually look at the rendered page.

And the worst part I almost didn't catch at all. The step that extracts the real CSS — the entire point of the skill — had quietly been skipped on that run. The capture files held a URL and a title and nothing else. No fonts. No colors. No card structure. Which means that whole "study" was built from screenshots and the model's own priors. The skill had silently degraded back into exactly the slop it was supposed to kill, and it looked polished enough that I nearly shipped it.

I had a second AI tear it apart. Then I checked every word.

I handed the whole thing to a separate coding agent and asked it to be hostile — find everything wrong. It came back with six problems. The buried recommendation. The clipped badge. The skipped extraction. A couple of responsive breaks. Images that could ship broken.

Six real-sounding problems from a confident reviewer. The move most people make here is to fix all six on faith. I don't, because a reviewer that sounds certain is still guessing until you check it against the actual files. So I reproduced all six against the live page and the real capture output before touching a line. Every one of them was real this time — but the habit is the point. The agent that finds the bug and the agent that confirms the bug should never be the same agent, and you never apply a fix to a claim you haven't reproduced.

The rebuild: ship an opinion, behind a gate

So I changed what the skill makes. The default deliverable stopped being a gallery and became a decision page. The recommendation sits at the very top — I'd ship this one — with two or three reasons. Then the options, each with an honest verdict and the real tradeoff named. Then the runners-up, steelmanned — the real best case for each option I passed on, argued as hard as I argued for the winner. The fifteen captured pages get demoted to an appendix at the bottom, where evidence belongs.

You can open the actual page the skill built, live: the decision page from this run. Fifteen real pricing pages captured, each option judged, the call up top, every reference page sitting in the appendix as evidence. Click any tile to zoom.

Then I gave it a bouncer. Every page the skill produces has to clear an automated layout check before a human ever sees it — a real headless browser that loads the page at desktop, tablet, and phone widths and fails loud on the things that embarrass you. Horizontal scrollbars. Broken or zero-size images. A recommendation buried too far down the page. A phone layout that scrolls forever. And the exact badge-clip pattern that shipped the first time — it specifically hunts for a pill positioned past the edge of a container that's going to slice it. The page doesn't ship until that check comes back green.

Two more things came out of the rebuild. The page now inlines every screenshot directly into the file, so it physically cannot ship with a broken image — there's nothing external left to break. And the CSS-extraction step is mandatory now; if it can't get the real values for a reference, that reference gets dropped instead of silently waved through on screenshots alone. The skill can't quietly turn back into a screenshot collage, because I made the thing that used to fail silently fail loud.

How do you find more good examples without trusting the list?

I wanted at least ten known-good pages in every run, not three. Plain search doesn't get you there — search for "best pricing pages" and you get listicles about pricing pages, never the pages themselves.

The better move is Exa's find-similar. Feed it a handful of pages everyone agrees are great — Linear, Stripe, Vercel, Resend, Attio, Framer — and ask what's similar. It comes back with real first-party pricing pages, ranked by how many of your seeds point at each one. The pages the most seeds agree on rise to the top.

It also comes back with garbage, and that's worth saying plainly. Find-similar happily returns SEO aggregators — the "compare 40 tools' pricing" directory sites that are about products rather than the products themselves. The skill filters the obvious ones, and then a human curates the rest down to actual first-party pages. This is discover-and-curate. The list it hands you is a starting pile, not a verdict.

The chat widget that fought back

One last gotcha, because it's the kind of thing that eats an afternoon. Some sites mount a live-chat bubble that sits on top of the page — and a few of them defend it. Airtable's, for one. Hide it with CSS and a script on their side notices and re-asserts the styles a half-second later, inline and marked to override anything you do, so your screenshot still has a chat blob parked over the pricing card.

You don't win that fight by styling it away. You win by deleting the chat element out of the page entirely, in the same instant, right before the screenshot fires. Remove the node and there's nothing left to re-style. Small thing. But it's the difference between a clean capture and one with a sales bot photobombing the design you're trying to learn from.

The actual lesson

This is a design skill on its face. Underneath it's the same thing I say about everything else here.

Don't let the model fill from the average. The average is where everyone already lives — it's the generic pricing page, the templated email, the dashboard that looks like every other dashboard. The only way out is to feed it ground truth it couldn't have guessed: the real CSS off the real page, the real numbers from the real run, the real situation of the real buyer. AI raises the average for everyone at once. The only thing that beats the average is the specific thing you went and captured.

And make the agent commit. A pile of options is the model dodging the hard part. A forced recommendation plus a machine that refuses to ship a broken page — that's how you get craft out of an agent on purpose, again and again, instead of by luck.

— Written by Claude Opus 4.8, approved by Jordan.

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

A vertical-SaaS company that sells to the trades had about 1,200 customers and a new idea. Pay any customer $1,000 in account credit for every peer they refer who signs. Good program. One problem.

Nobody could say which customers actually carried weight in their industry. The CRM knew revenue, seat count, and renewal date. It didn't know which owner sat on a state association board. It didn't know which one hosted the podcast every other owner in the trade listened to. It didn't know which one got introduced on stage at the national conference.

The company already knew more about its buyers than it had ever looked at. Twelve hundred owner-operators, and the signal for "who can send us deals" was sitting in public — board rosters, conference agendas, podcast feeds, award lists. It had just never been pulled together.

So I built a skill that pulls it together. It's called referral-notability. Point it at a customer list. For every account, one Claude subagent finds the owner-operator, reads their full LinkedIn, and researches their real-world footprint — association seats, speaking, podcasts, press, awards, review scale. A fixed rubric turns all of that into one number: a 0–100 Referral Notability Score.

The score ranks the owner, not the logo

The number ranks the owner's connectedness, not the company's size. That's the part that changes how the list reads.

A 40-year-old, hundred-person institution whose owner keeps his head down ranks below a small shop whose owner chairs the state trade association. The big brand looks impressive on a logo wall. The small-shop owner can walk a peer over to you and vouch. An affiliate program needs the second list, not the first.

Sort a customer base by revenue and you get the org chart you already have. Sort it by who's connected and you get a different list entirely — one your competitors can't buy, because nobody sells "which of your customers other operators actually trust."

The biggest companies didn't top the list

I ran it on the full base. 1,182 accounts scored, 1,145 unique companies after dedup. Fifty-six of them cleared 55 — the affiliate-grade tier, the owners worth a personal ask. Nine cleared 80.

None of the top owners run the largest companies in the file. The number-one owner hosts the most-listened-to podcast in their industry, sits on a national trade-association board, and has won his city's top industry award many years running. Number two founded his state's trade association and still presides over it; he speaks at the national conference and turns up on local TV as the industry's explainer. Another, mid-list, holds an Inc. 5000 placement, a state trade-association board seat, and an operator-of-the-year honor at once. All of them are people other owners in the trade already trust. That's the trait the affiliate program was actually buying.

The CRM never had the owner's name

The CRM almost never named the owner. A company record, a billing contact, a renewal date — but rarely the person who founded the place. So the system never trusts the CRM for it. It goes and finds the owner for every account, and it resolved a named owner for 1,112 of the 1,145 companies. About 97%.

It looks the cheap way first. A LinkedIn data lookup that's already on the plan, then a two-tenths-of-a-cent web search, and only a pricier deep search when there's a real thread to chase. On an account with no digital footprint — a tiny shop, no press, a thin profile — it stops. You don't pay to dig a dry well. (The full cascade is in the recipe below.)

The bug that quietly ate data

The system writes each account's evidence to a file named after its CRM ID. Twenty-nine times, different companies had Salesforce IDs that collided on case alone — sPSNT versus sPSnT. macOS treats those as the same filename.

So one company silently overwrote another's score file. No error. No crash. Just data that quietly wasn't there. I caught it, re-keyed every file so case can't collide, and re-scored the affected accounts. The boring infrastructure detail is the one that eats your data — the filesystem you never think about decided two of your customers were the same company.

Why this keeps working

This is the move I keep coming back to. You almost always know more about your buyers than you've bothered to look at. The data to rank your own customers by influence is public, and it's free to read. Assembling it is the work nobody does — so the operator who does it ends up with a list no competitor can purchase.

Run it once and you stop guessing who to ask. You email the fifty-six owners the rest of the trade already listens to, not the fifty-six biggest invoices.

— Jordan

Written with Claude Opus 4.8

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

Two account executives. Same title. Same nine years. Same President's Club banner on the LinkedIn header. One of them will crush the role you're hiring for. The other washes out in a quarter. The résumé won't tell you which one.

That's the problem Matt Braley handed me. Matt thinks about sales hiring the way a good engineer thinks about a system: the same input behaves differently depending on the context it runs in. Here's the line of his I can't stop repeating:

"A rep closing $25K deals in four-week cycles isn't worse than one closing $500K deals in nine months — they're just aligned with different motions. Same résumé, opposite verdict, depending on the role."

Read that twice. It kills the way almost everyone scores candidates.

Most people rank reps by who looks impressive. That's the bug.

Open any sourcing tool and watch what it sorts on. Title. Years. Logo. A competitor flag. An A/B/C rating that's really just "how impressive is this person." It's a beauty contest, and it mis-hires in both directions.

It waves through the enterprise rep who's spent nine years closing seven-figure deals behind a category-leader's brand — and has never once opened a cold logo for a 60-person startup that lives or dies on new business. And it buries the SMB closer who'd be a monster in a fast, transactional motion, because their deals were "only" $8K.

Last month I built a sourcer that searched every company instead of sampling fifty. That fixed the who do we look at problem. It didn't fix the how do we rank them problem. I was still sorting by prestige. Matt's framework changed the sort key.

So I rebuilt the scorer around it. The tool is called Find a Rep.

The eight dimensions

Matt reads a candidate against the context they sold in — not whether they're good, but whether they sold the way this specific role needs. Eight dimensions:

• Company stage they sold from. Seed scrappiness or a late-stage brand that opens the door for you.

• Type of buyer. A CRO who signs is a different animal than a self-serve user or a procurement committee.

• Sales motion. New-logo outbound, product-led self-serve, or expansion of an existing book. Different muscles.

• Sales cycle length. Two weeks or nine months. The cadence doesn't transfer for free.

• Number of buyers in a deal. One decision-maker or a five-person committee. Multi-threading is learned.

• Cross-departmental complexity. Does the deal pull in RevOps, Finance, IT, Security?

• Deal size. $8K transactional or six- and seven-figure ACV. Patience and discounting instincts scale with the number.

• Industry. Horizontal, or a regulated vertical where getting deep into the workflows of an industry and learning the jargon matters.

Every dimension gets scored as a degree-of-fit — aligned, partial, or not — against the target you set for the role. Not a pass/fail gate. A rep can be a perfect 8-of-8 for one job and a 2-of-8 for the same title somewhere else.

What it found for █████

█████ is a go-to-market software company — they sell software that helps revenue teams sell better, into a Series A-to-C, 30-to-200-person world. They needed a new-logo account executive: someone who's been closing complex, six-figure, committee deals into revenue leaders. So I pointed Find a Rep at the whole market and let the eight dimensions do the sorting.

The funnel ran like this. We pulled every account executive at a 30-to-200-person U.S. software company — 15,489 people — with the Blitz API. We deduped their employers down to 6,960 companies and read each company's website, keeping only the 671 that actually sell go-to-market or sales technology to revenue leaders (670 the model found, plus one I added by hand). That left 1,563 AEs. We pulled the full LinkedIn history on 1,428 of them, ran a deterministic set of rules — at least four years closing as an AE with SDR time excluded, three-plus years in seat, four-to-eight years total, no job-hopping — and 135 survived. Every one of those 135 got scored on Matt's eight dimensions and ranked.

Total spend on the AI: eight to ten dollars.

Here's who came out on top — and why, by context, not by logo.

Alex Holler, Enterprise AE at Tackle.io. Alex sells cloud-marketplace sales tech to revenue and go-to-market leaders. His daily buyer is a revenue leader signing a six-figure, committee-driven deal — the exact buyer and deal shape █████ runs. He climbed a ladder at Dell and VMware with repeated promotions and carries a President's Club win. Eight of eight. The one thing to confirm: how much of his recent book was brand-new logos versus growing accounts.

August Buettner, Enterprise AE at HG Insights. August sells sales-intelligence data to revenue leaders — a close cousin to what █████ sells — in enterprise, multi-person, six-figure deals. He worked up from a business-development seat into the enterprise chair over about five years at one revenue-tech company. Eight of eight, and the kind of steady climb that says he can both close and stay.

Christopher Trebon, Senior Sales AE at Canidium. Christopher sells RevOps and sales-performance tooling — another tight cousin of █████'s product — to the person who owns how a sales team performs. Long, multi-step, committee deals. Twenty-plus years selling, promoted to the senior seat in two. Eight of eight.

None of those three would top a prestige sort. No FAANG logo. No unicorn. What they have is the motion — they already sell the buyer █████ sells to, in the deal shape █████ runs. That's the thing a résumé ranking can't see.

Degree-of-fit is the whole game

Eleven of the 135 scored a clean 8-of-8. But the real proof the framework works is the messy middle. Thirty-five candidates came through as "flex" — near-misses the rules would normally cut, kept on purpose because one soft dimension shouldn't bury an otherwise-perfect rep.

A rep whose only miss is cycle length — they close in three weeks, not the ninety-to-one-eighty days this role runs — isn't a bad rep. They're a phenomenal hire for a transactional motion and a partial fit for this one. Matt's line again: not worse, aligned with a different motion. A pass/fail gate throws that person in the trash. Degree-of-fit keeps them, scores them honestly, and tells you exactly which dimension to ask about in the screen.

That's the difference between a tool that ranks people and a tool that ranks fit.

So which would you rather hand your hiring manager — a list sorted by who has the shiniest logo, or a list sorted by who's already been selling your exact motion, with the one open question flagged on each name?

— Written by Claude Opus 4.8, approved by Jordan. Framework by Matt Braley. Matt is a former CRO who helped scale a company from $0 to $200M ARR and now advises high-growth Series A–C startups on building and scaling their revenue orgs.

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

Every contact tool charges you per domain. Hunter, Apollo, Clearbit, the whole shelf — you hand them a website, they hand you a lookup, you pay. Run a full market through one of them and the bill scales with the size of the market. That's backwards. Most of a market is sitting in plain HTML, free, if you bother to look before you pay.

So I built a thing that looks first. It's called Lynx. You feed it a list of company websites — a whole market, a hundred thousand rows if you have them — and it gets you the contact: an email, and the actual person attached to that email. The trick is it figures out which sites are free to read before it spends a cent on the ones that aren't.

This week I ran it on two real markets. 500 acupuncture clinics and schools. 150 law firms. Both at $0.00.

Classify before you pay

The core move is a fast triage. Before extracting anything, Lynx hits each homepage and sorts it into one of five buckets: the email's already sitting in the raw HTML (best case), the page is plain server-rendered text (easy), the page is an empty JavaScript shell (needs a render), the page is behind Cloudflare or a bot-wall (hard), or the domain is dead. You classify on what's actually in the response body — not the status code, because a Cloudflare challenge and an empty React shell both return a cheerful 200.

That sort is the whole economic argument. On acupuncture, 31% of sites had the email right there in the HTML and another 38% were plain static pages — call it 69% you can read for free. Another 20% were Cloudflare-protected and 6% needed JavaScript. The free buckets are the majority. You only ever pay for the residue.

Read the page, don't ask a robot to read the page

Once a page is in a free bucket, deterministic code does the extraction. Plain mailto: links. Cloudflare's obfuscated email trick — they hex-encode the address with a one-byte XOR key, which is fully reversible without running any of their JavaScript, so you decode it for free. Schema.org and JSON-LD blocks, which is structured author-declared markup that hands you name, title, and email in one shot. And team-card structure — the photo-name-title-email box every "Meet the Team" page is built out of.

Here's what each of those looks like on a real page from the run — and where it sits in the HTML.

Only the genuinely ambiguous pages — the ones where there are six people and four emails and no clean structure tying them together — get sent to a model. The majority never touch an LLM. That's the second half of why it's free: you're not paying per-token to read pages a regex can read.

The acupuncture run: 500 domains, 68% page-resolution, 456 contacts, $0.00. The lawyer run: 150 domains, 63% page-resolution, $0.00. Two unrelated markets, both landing within five points on the headline numbers. The method travels.

The name is the hard part

Getting an email is easy. Getting the person is the job. An info@ mailbox is worth a fraction of "the owner, an acupuncturist, at her own first-name address" — and most cheap tools blur that line. Lynx labels every email as a real person or a generic mailbox, and only person-tied emails count toward the number I actually care about.

On free routes alone, the named-contact rate ran around 24% on both markets. That's the honest floor — real, cold, no spend. Then I did something that cost almost nothing: I took the pages Lynx had already downloaded and ran them back through a cheap model — Gemini Flash-Lite — pointed only at the emails that didn't have a name yet. No re-crawling. Just re-reading what was already on disk.

On acupuncture that pulled the named-person rate from 37% to 50% of the contact list — 60 new people attached to emails that were previously anonymous. On lawyers it added six. The gap is itself a finding: law firms already put the attorney's name next to their email on the team page, so the deterministic pass already had them. Acupuncture clinics hide owners behind info@. Different market, different bottleneck, same engine.

The part I don't trust: the name↔email link

Here's where I get paranoid. A model that attaches names to emails will, given the chance, invent one. It'll see a first.last@ address, decide the owner is "First Last," and hand it to you with total confidence — even when that person appears nowhere on the page. It reverse-engineered the name straight out of the email address. That's a fabrication wearing a confidence score.

So every name the model attaches goes through a two-stage check before I believe it. First a dumb deterministic floor: the name's first and last word both have to literally appear in the page text, or it's rejected — that alone caught the reverse-engineered names. Then a second model, told to be hostile, gets the page and the pairing and one job: prove this is the wrong person. Default to "wrong" if you're unsure. Only pairings that survive both gates ship.

After I added those gates, the verified name↔email accuracy was 100% — fifty out of fifty on acupuncture, six out of six on lawyers. Before the gates it was 98%. The two percent it caught were exactly the fabrications, and two percent of a real list is the part that burns your domain reputation.

Where you actually pay

The free routes leave a residue: the Cloudflare-walled sites and the ones with no named owner anywhere on the page. That's the only slice that needs paid tools — a contacts API, a render service, an archived copy of the page from Common Crawl. It's built as a separate tier with a hard dollar cap, because the only safe way to run a paid escalation across a hundred thousand domains is to make overspend structurally impossible.

And I'll tell you what broke, because the breakages are the actual lesson. The paid tier's first live run found a billing bug in my own code — it was counting failed API calls as money spent. The contacts API I wired in turned out not to be subscribed to the one endpoint I needed, which I only learned by watching it return 401 on the exact call that mattered while every other endpoint worked fine. None of that showed up in a unit test. It showed up the instant real money and real domains touched it.

The real product is the calibration

This is the thing I keep relearning. The free run isn't just cheaper data collection — it's a cheap test that tells you what the expensive run will cost before you commit to it. The route split is the cost model. Lawyers carry more Cloudflare than acupuncture, so lawyers cost more to finish. You know that for a few cents, on a 500-row sample, before you spend a dollar on the full market.

And running it on real websites instead of test fixtures is what caught everything that mattered. Sentry error-tracking strings that parse as emails. The word "creative" decoding into an @ because "cre-AT-ive" has "at" in the middle. Section headers like "Beginning Spring 2027" getting read as a person's name. A DNS resolver that throttled my own laptop after fifty fast lookups and made a hundred live websites look dead — which would have quietly told me lawyers were a worse market than they are, if I hadn't gone and checked the "dead" ones by hand. Every one of those was caught for pennies, on a sample, before any of it scaled.

Lazy first. Crazy later. Read the free pages with free code, send only the hard ones to a model, and only pay for what's actually left.

How to run it

It's a Claude Code skill. Annual subscribers install it once:

/edge install tam-contact-harvester

Then point it at a CSV of company domains — it auto-detects the website column — and run the free pass:

python3 scripts/harvest.py --input your-market.csv --out run/

That's the $0 part: triage, deterministic extraction, the labeled contact list, and the page corpus saved to disk. When you want names on the anonymous emails, re-read the pages you already pulled — no re-crawl:

python3 scripts/enrich_names.py --run run/        # cheap model, names onto emails
python3 scripts/verify_names.py --run run-enriched/  # adversarial name↔email check

And only when you want to chase the Cloudflare-walled residue do you spend, with a hard cap you set:

python3 scripts/tier1.py --run run-enriched/ --budget 5 --source apify

Free by default. You decide when money enters.

— Jordan Written by Claude Opus 4.8, Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

A company that fixes parking lots wins about one and a half percent of its cold outreach. Today they pick who to call from federal industry codes. A code tells you what a business is. It doesn't tell you whether their lot is cracked.

So they're guessing. And the thing they're guessing at — the condition of the actual asset — was photographed from a plane years ago and is sitting in a free government database right now.

Flip it. Don't start with the company. Start with the lot.

Score the asset, not the industry

Here's the whole move. Pull every commercial parking lot in a metro from OpenStreetMap — they're already drawn as polygons. Crop a free aerial photo of each one. Ask a cheap AI: how beat-up is this pavement, zero to a hundred. Rank them. Then, only for the worst ones, find the owner.

The ideal customer was never an industry. It's a shape and a condition: a big lot, in bad shape, with someone inside who can sign for the repair. You can see the first two from space. You can buy the third.

So I pointed it at all of Dallas. OpenStreetMap had 1,355 commercial lots over 50,000 square feet already drawn. A free filter — public building footprints — threw out 236 of them as rooftops before I spent a cent on AI. The cheap model gated out another 332 as not-actually-a-lot. 787 got a real condition score. Total bill: about a dollar.

The spread: 52 Poor, 656 Fair, 61 Satisfactory, 18 freshly-sealed Good — fifty to ninety. Fifty-two scored 55 or worse. Those are the leads. Flag everything under 70 and you "find" 720 of them — every aging lot in the city, which is just noise.

The lots ran from a 3.8-acre corner strip to a 27-acre vehicle yard. Same pipeline, no tuning, no idea what it was about to look at.

Be honest about what a photo can show

Free aerial photos cannot see a single pothole. A pothole is smaller than one pixel. Anyone who tells you they're counting potholes from free satellite imagery is lying or confused.

What free photos can see is neglect. The whole-lot signature of a tired lot: faded paint lines, the sealcoat gone from rich black to grey to brown, big repair patches, dark stains where water pools, the rough web of alligator cracking. That's enough to sort every lot from "freshly maintained" to "clearly falling apart." A 2024 study hit 93% accuracy on a five-bucket condition rating from photos this coarse — while openly admitting it couldn't see individual cracks. It didn't need to.

Match the claim to the pixels. Rank on the free stuff. Buy a sharper photo only for the handful of lots you're about to bid.

And I didn't just trust the model. I laid Dallas's own 311 street-repair complaints over the scores. The lots it called bad averaged 8.3 complaints nearby; the good ones, 5.2. The city's own pothole calls line up with the photos — free corroboration I didn't have to ask anyone for.

The thing I didn't expect: a free 15cm map of America

Everyone knows about NAIP — the federal program that photographs the whole country at 60cm, free. I went in assuming that was the ceiling for free imagery.

It isn't. About 35 states fly their own aerial imagery and give it away far sharper than the feds — most at 15cm, several (Connecticut, Kentucky, Rhode Island, DC) at 7.5cm. That's four to eight times sharper than NAIP, free, sitting on state GIS servers most people have never opened.

That's the treasure map. And it's the line where this stops being a story about why and starts being a story about how — the exact states, the exact endpoints, the cheapest way to score them, and the legal trick that makes the whole thing shippable.

— Written by Claude Opus 4.8 (1M context), approved by Jordan.

Who Gets This

This one's free. Most of my build content isn't.

• Free: what you're reading — the inversion, why a photo beats an industry code, and the rule about matching the claim to the pixels.

• $50/mo (most readers start here): the rest of the build — the cheapest scoring cascade, the exact imagery sources, and the legal move that makes the whole thing shippable.

• $2,499/yr: Every tool I ship. Edge Copilot is how you talk to all of it through Claude Code. Current tools: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor, LinkedIn Engagement, Domain & LinkedIn Finder, Dossier Builder, PDF Contact Finder. Whatever ships next is included. Plus all 3 courses + weekly office hours.

→ Start at $50/mo (most readers start here) · Go annual — $2,499/yr

Read more

Ask ChatGPT, Claude, and Gemini the same research question and you will get three different answers.

Each engine indexes a different slice of the web and reasons through it with a different model. Each one catches things the others miss.

The places where all three agree just confirm what Wikipedia would tell you anyway. The places where exactly one engine found a claim — and that claim survives a hostile fact-check — are where the actually useful intel lives.

That set-difference between the three engines is the asymmetric edge.

Capturing it in practice has been almost impossible until now. Reading three deep-research reports and verifying every citation across them takes half a day for any human.

Triple Deep Research is the tool I built to do that work for you.

It takes one question, fans it across ChatGPT, Claude, and Gemini at the same time, and runs a wave of Claude agents that fact-checks every cited link in all three reports. What comes back is one synthesized report where every claim cites a stable identifier in the raw text — and where the disagreements that survived verification lead the report as the asymmetric edge.

What it does

You feed Triple one question.

Something like "What state-level rules passed in 2025 affect Medicare Advantage reimbursement?" Or "Which B2B SaaS companies shipped AI agent products in the last year and then publicly walked them back?"

The tool fans that question to all three engines at the same time. ChatGPT runs its deep research on its own slice of the web. Claude runs its deep research on its own index. Gemini runs its deep research on the Google corpus.

Three engines. Three models. Three separate cross-sections of the open web — all working the same question in parallel.

Once the reports come back, a wave of Claude agents takes them apart.

The first agent breaks every claim into its smallest factual unit and labels each one by how many engines surfaced it. Three more agents work in parallel — one per platform — and each opens every cited URL to decide whether the page actually supports the claim.

A fourth agent catches the date errors the engines tend to miss. A judge ranks every surviving claim by how much it actually shifts your thinking.

A final writer synthesizes everything into one report where every claim cites a stable identifier you can resolve back to the raw page text.

A run takes 15 to 55 minutes, gated by whichever engine is slowest.

The cost is nothing on the deep research itself. The work rides on the ChatGPT Plus, Claude Pro, and Gemini Advanced subscriptions you already pay for. The only marginal spend is about $3 in Claude agent tokens to run the fact-checker wave.

Why three engines, not one

The three engines do not see the same web.

ChatGPT runs on the Bing index. That gives it strong coverage of news and academic sources, and pulls back the well-edited material journalists and researchers tend to cite.

Claude runs on its own index. It is strongest on long-form blogs and has been sharpening fast on primary documents — court filings, government reports, things like that.

Gemini sits on the full Google index, which has the largest surface area of the three by a wide margin. It routinely reaches obscure corners of the web — niche forums, regional publications, vendor PDFs — that no other engine touches.

Running a question through one engine gives you one cross-section of the web's knowledge on that question. Running the same question through all three gives you the set-difference — the gold sitting between the cross-sections.

The all-three-agree claims tend to be the consensus you could have found in any general search. They are a useful baseline, but they are not insight.

The one-of-three claims — the things that only one engine surfaced — are where the asymmetric value lives. If, that is, you can verify them against primary sources and rule out the ones the engine just hallucinated.

The asymmetric value is the set-difference. Everything else is just an answer.

The proof point: 1 link → 60 citations

Two paths exist for reading a deep-research report off these platforms. One returns almost nothing. The other returns everything.

The naive path scrapes the page's visible HTML — the DOM — and extracts whatever text and links you can see. The problem: what you see is almost never what is actually there.

On Claude, a DOM scraper gets back 1 link out of the 427 sources the page itself shows next to the report. The report lives inside a Document artifact tile the DOM snapshot cannot reach.

On ChatGPT, a DOM scraper gets back 0 characters of the report. ChatGPT renders it inside a sandbox iframe the outer page is not allowed to read.

On Gemini, the citations come back as redirect URLs the DOM never resolves. You end up with a list of meaningless redirect handles instead of real source pages.

The path that actually works asks the platform for its own data, the same way the platform's own page asks for it.

Each engine ships an undocumented data feed that the page itself calls to load the report. From inside the page — meaning from inside a real browser tab the user is already signed into — you can call that same feed and the platform hands you the data back as plain text.

On Claude, that call pulls the full 31,213-character report and all 60 citations in 157 milliseconds.

On ChatGPT, the report comes back as plain text from the same conversation feed the website's own React app reads.

On Gemini, the redirect-only citation URLs resolve to their real destinations. You can fetch them from inside the real browser tab, and Cloudflare passes you through — because you actually are a real browser tab.

Same conversation. Same question. Different read path. One returns roughly 0% of the information. The other returns 100%.

Every library you'd reach for is broken

No off-the-shelf scraper handles all three platforms cleanly. None of these platforms want to be driven by anything that is not a real human in a real browser.

They have layers of defenses. Each layer was specifically designed to break the kind of script you would write to automate them.

ChatGPT runs a real-time signal-validation system inside the page. It watches for things a script would never do — patterns of clicks, keystrokes, and timings that a human produces but a bot does not. It silently flags any session that fails the test.

On top of that, every write to ChatGPT's interface hits a math puzzle the page itself computes before sending. A normal request cannot pass without running the page's own code.

On top of that, Cloudflare runs its bot challenge — the same test that decides whether to throw up a "verify you are human" page. The challenge token regenerates every few seconds.

Each of those three layers will reject a naive script the moment it tries.

Claude has a different problem.

The first time you drive a deep-research session in Claude, the page pops up a modal asking which "connectors" you want to allow — file system, GitHub, Drive, and the rest. The page refuses to run the research until the modal is dismissed.

A second modal then asks you to clarify the scope of your research before submitting. A scraper that does not handle those two modals dies at the door — and most do not.

Gemini wraps every response inside a serialized envelope format that Google uses internally. The envelope arrives in the network log as a chunked stream.

The chunks expire seconds after the network event fires. If you are not reading the response from inside the same page that received it, you do not get to read it at all.

The open-source libraries around all three are broken, as you would expect from that list.

The most popular Gemini scraper on GitHub has six open critical bugs nobody has fixed in months. ChatGPT exporters break every time Cloudflare rotates its challenge — which is every few seconds.

Claude scrapers cannot make it past the connector modals because they were built for the old chat surface, not the deep-research workflow that ships those modals.

You can spend a week patching one of those libraries every time a platform shifts its UI. Or you can stop fighting the platforms and let the browser do the writing for you.

The insight: browser owns writes, JSON owns reads

The trick is to stop pretending you are not a browser.

Use the user's real signed-in Chrome — the actual browser with the actual cookies and the actual login session — and drive that. Instead of building a bot that tries to look like a browser, take a browser that is already signed in and tell it what to do.

When you drive the real Chrome, every defense the platform built falls away on its own.

The math puzzle gets computed by the platform's own page code — the page is the thing computing it. The bot-challenge tokens come along for free, because they are generated inside the page session you are inside of.

The IP address Cloudflare sees is the user's real IP. The handshake is the user's real handshake. Cloudflare looks at all of it and sees a real signed-in browser doing what real signed-in browsers do. It lets the request through.

That is the write path. Every input goes through the real browser.

For the read path, you ask the same page for its data, from inside the page. Each platform has its own undocumented data feed the website itself calls to load the report.

From a real tab with real cookies, that feed returns the report as plain text.

No DOM scraping. No screenshot tricks. No envelope-unwrapping from outside the page.

Browser owns writes. JSON owns reads.

Type into the real browser, then ask the real browser for the data back.

One more piece matters: the extraction step is decoupled from the browser run.

The browser saves the raw page and the raw response to disk before the extractor touches anything. The extractor then reads from disk, not from the live browser.

If a platform ships a UI change next week and breaks the extractor, you re-run only the extractor against the raw page you already saved. You do not re-pay for another 30-minute deep-research run — which would cost both wall time and quota against your weekly limits across all three platforms.

How the fact-checker wave defends every claim

Once the three reports are on disk, a wave of Claude agents takes them apart and verifies every claim.

The waves run in a specific order, because each one builds on what the previous wave wrote. The asymmetric-edge claims surface at the top; anything that looks like a hallucination gets filtered out.

• Cross-Corroborate. One Sonnet agent reads all three reports and breaks every claim into its smallest factual unit — one fact, one subject, one source. Each unit then gets labeled by how many engines surfaced it: agreed by all three, agreed by two of three, found only in one engine, or contradicted between engines. That labeling is the substrate everything else depends on.

• Link & Fact Skeptic, three at the same time. One Sonnet agent runs per platform, with all three in parallel. Each agent opens every URL cited in its platform's report, reads the source page, and assigns a verdict from one of five buckets: supports the claim, partially supports it, contradicts it, dead link, or hallucinated cite. Every link gets saved — including the dead ones — so the receipts stay visible.

• Date Skeptic. One Sonnet agent works across all three reports looking for the date errors deep-research engines are notoriously bad at. It catches stale-recency claims (a "recent" thing that actually cites a 2019 source), event-misattribution (the right thing happened, but to a different company), and publication-drift (the cited page has been edited since the report was written, and the claim no longer matches what the page says).

• Usefulness Judge. One Opus agent reads everything the skeptics wrote and ranks every surviving claim on four axes — does it advance the goal you asked about, does it surface information the other engines missed, can you actually do something with it, and can you sort your buyer list by it. Claims that scored high on asymmetry (only one engine found them) get a bonus weighting if they also passed the fact-check, because those are the ones that represent the actual edge.

• Final Synthesizer. One Opus agent reads everything written above it — the original three reports, the corroboration labels, every skeptic's verdicts, the usefulness ranking — and writes the final report. Every claim cites back to a stable identifier like [claude-042] or [chatgpt-014] that resolves to the raw page text on disk. The verification appendix at the end lists every dead link, every hallucinated citation, every date flag, and every contradiction the skeptics raised. Receipts visible.

By the time a claim makes it into the final report, it has been atomized, labeled, fact-checked against its source, date-validated, ranked for usefulness, and tagged with its provenance.

The claims that survived AND came from only one engine lead the report — that is the asymmetric edge, made automatic.

Fail-fast partial Triple

One platform failing does not block the run.

If Gemini times out at submit, or ChatGPT hits a weekly Deep Research quota you are bumping up against, or Claude's connector modal takes too long to clear — that platform exits with a clear terminal status. The other two keep going.

The fact-checker wave then runs on whatever 1, 2, or 3 platforms succeeded.

The asymmetric-edge thesis still works with two of three engines. You just have less to compare against.

It even works with one of three. The fact-checker wave still runs and at least filters out the hallucinated cites.

Partial Triple is degraded, but it is still useful.

When NOT to invoke

Situations where Triple is the wrong call:

• Quick factual lookups. If your question is something like "What's the population of Boise?" — one engine is fine. Do not burn 45 minutes on it.

• Code search. Use Grep. Triple is not your file finder, and the deep-research engines were not built to scan your repo.

• Account-specific research. If you want to know what is happening inside a single account — the CRM history, the call notes, the billing trail — use the Dossier Builder skill instead. Triple is for the open web, not for the data you already own.

• Anything where wall-clock under five minutes matters. Triple is 15 to 55 minutes by the clock. If you need the answer right now, ask one engine and move on.

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

The short version

I built a new tool. It checks customer data before you try to build anything with it. If the data is broken, the tool stops you. If the data is fine, it hands the next tool a clean list of what to use and what to skip.

That's it. The rest of this post explains why it matters and how it works.

First: what's a customer dossier?

Think of it like a one-page report for a single customer. It pulls in everything you know about them — from your CRM, your billing system, your call recordings, your product analytics, your support tickets — and lines it up on a timeline. Then it tells you the truth about that account in plain English. Are they active? Are they about to churn? Who do they actually talk to?

I have a tool called Dossier Builder that makes these reports. Point it at a customer's data, and it gives you the dossier.

But Dossier Builder only works if the data going in is good. And the data is almost never good.

Why dossiers usually break

Three problems show up in almost every customer's data. Let me explain each one in plain English.

Problem 1: Data that doesn't actually match

Most companies have multiple systems. A CRM. A billing tool. A call recorder. These systems are supposed to talk to each other. The CRM has a customer ID. The billing tool has a customer ID. Match them up, and you can see one customer across both systems.

Except the matching is often wrong. The CRM ID column might point at customers that don't exist in the billing tool. Or the matching rule might be "same email address" — but two unrelated people have the same email at a big company.

At one customer I worked with, 282 customer records got matched to the wrong account because of a sloppy email rule. Nobody noticed. Every report built on top of that data was wrong.

Problem 2: Too many columns saying the same thing

Open a typical Salesforce account, and you'll find six columns that all claim to be "revenue." Annual Revenue. MRR. Monthly Revenue Summary. Reported Revenue. Subscription Revenue. Annual Revenue Range.

They don't agree with each other. Most of them haven't been updated in 18 months. None of them are labeled as the "real" one.

If Dossier Builder picks the wrong column, the dossier shows the wrong revenue. The CEO closes the report. You lose.

Problem 3: The same company shows up three times

One company can appear in your CRM under three names: the legal name, a brand name, and a "doing business as" name. Each one looks like a separate account. Each one shows half the activity. The real picture is split across all three.

Sometimes the data is even worse — a company gets listed as its own parent company, which makes no sense.

The fix: check the data first

The normal way people handle these problems: build the dossier, find the bugs, fix the data, rebuild. That wastes a whole day.

My new tool reverses the order. It runs first. It looks for all three problems. If it finds any, it writes down exactly what's broken and refuses to let Dossier Builder run until you either fix the data or tell the tool "I know, do it anyway."

I call it the Dossier Data Auditor.

The auditor and the builder talk to each other through a single file. The auditor writes the file. The builder reads it. No human has to copy anything by hand.

What it caught when I tested it

Before I let the auditor near any real customer data, I tested it against a fake dataset I made up. I deliberately put broken stuff in the fake data. Here's what it caught:

• 60% of the matches were wrong. A column that was supposed to connect two tables actually only worked 40% of the time. The auditor labeled this as a hard failure. Dossier Builder would have run on top of broken matches for every record.

• One company was listed as its own parent. The auditor caught the loop and flagged that one row for repair.

• A revenue column that should never be used got picked. I put a column called Monthly Revenue Summary in the data and marked it as do-not-use. The auditor read the rule, skipped that column, and picked the right one (MRR) instead.

Each catch is the kind of thing that would have broken a real dossier.

The rule that makes it trustworthy

The auditor does math first, then asks the AI to make a call. Never the other way around.

Why this matters: if you let an AI compute numbers directly, it's roughly right most of the time and wrong in unpredictable ways the rest of the time. You can't tell which is which.

So the auditor does it like this. Step one: a small Python script counts how many records in column A have a match in column B. It writes the answer to a file. The answer is a real number. You can check it by hand.

Step two: an AI reads that file. The AI's only job is to look at the number and call it pass, warning, soft fail, or hard fail. The AI is allowed to have an opinion. It is not allowed to invent the number.

This is the load-bearing rule. The math is on disk. The AI is making a judgment call. You can audit either one.

The order matters too

The auditor checks things in a strict sequence. Each step has to pass before the next one starts.

• 1. Domains first. Figure out the real website for each company. Is it the brand site or the corporate site? Both? Neither? Some companies own multiple domains. The auditor uses a stack of tools to ground-truth this.

• 2. Joins second. Check the matches between systems. Throw out matches that don't survive a real test.

• 3. Revenue third. Pick the canonical revenue column. Skip the do-not-use ones. Make sure the picked column actually has data in it.

• 4. Sanity last. Look for impossible combinations. Customers with positive revenue but zero calls in six months. Columns nobody has updated in years. Self-referencing parent companies.

You can't flip this order. You can't compare revenue across two systems if you don't trust the matches between them. You can't trust the matches if you don't know which website belongs to which company.

What it costs to run

The math part is free. No AI tokens, no API calls. Just Python running on your laptop.

The AI part — eleven small AI helpers, each reading a different number and making a call — runs about $8 to $15 per customer-data folder. A real dossier build costs many times that. So the audit pays for itself the first time it catches anything.

— Jordan

Written with Claude Opus 4.7

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

May 17, 2026 · Build log

Every CEO running a Claude rollout has the same question and no good way to answer it. Is our AI investment paying off? Who's actually shipping with these tools versus chatting with them? Which of the people not yet on the leaderboard should be there next quarter? The deployment report is how I answer that question for a client.

(If you read about the $67K bill that wasn't earlier today: that came out of this same skill. The deck this thing renders is what sat under the panic.)

Here's the public version of the deck I built for a healthcare org. Anonymized as Northwind Health, real client run, names swapped, KPIs ranged. Eleven sections. About a fifteen-minute read for the CEO.

→ Open the Northwind Health AI Deployment Report

Scroll it while reading the rest of this. The article walks through what each section does and how to point the skill at your own team.

The three inputs

Three things go in. One HTML page comes out in about thirty minutes.

One. An Anthropic chat-history export ZIP. Every Claude conversation your team had during the reporting window. Individuals export from claude.ai → Settings → Data privacy controls → Export. Org admins export from inside console.anthropic.com → Privacy → Export organization data — Anthropic has full instructions at privacy.claude.com on exporting org data. The ZIP arrives by email. Drop it in ~/Downloads/.

Two. Local clones of every git repo where your team ships Claude-assisted code. The skill walks every commit across every repo, attributes by email, separates partner commits from staff commits, narrates multi-repo cutovers in one line, surfaces the people writing real code from the people running chat experiments. For Northwind that meant two repos and four months of history.

Three. An Anthropic admin API key. Create one at console.anthropic.com → Settings → Admin API keys → Create new key. The format starts with sk-ant-admin-. Rotate it the second the run finishes — it stops being useful and shouldn't live anywhere long. Without it, the report tells the people-and-shipping story. With it, the report also tells the dollars-and-infrastructure story: total Anthropic spend, per-key concentration, dormant credentials, daily cost curve, whether prompt caching is on, whether the Claude Code OpenTelemetry exporter is wired up. Both stories together are what makes the deck CEO-grade.

Set the key in your shell, then run one command from the skill's root:

export ANTHROPIC_ADMIN_KEY=sk-ant-admin-...
bash run.sh ~/Downloads/data-<export-id>-batch-0000.zip --client <your-client> --publish

Thirty minutes later the deck lands at playbooks.blueprintgtm.com/<your-slug>, behind a JS password gate until you tell the team the code.

What's in the deck

Eleven sections, each answering a specific CEO question. I'll group them.

The first two answer "where are we." Section one carries anchor KPIs from the client's existing exec deck plus the headline gap underneath — for Northwind, 91 people use Claude regularly, 3 of them ship code. That gap is the story the rest of the deck unpacks. Section two charts the daily conversation curve and the top five contributors by volume: is usage compounding or flat, who's carrying the weight.

Section three is the money section. Daily Anthropic spend curve. Monthly totals. Per-key concentration. Dormant credentials. Prompt-caching status. Whether the Claude Code OpenTelemetry exporter is wired up (most teams: it isn't). For Northwind, the four-month bill was $2,564 across 9 API keys and 1 workspace, with a $671 spike on March 26 from a 5,090-account churn analysis run. Section three only renders when the admin API key was set at run time.

The first time I built this section I read the cost-report endpoint's amount field as USD. It's in cents. I missed the unit on the first pass and almost shipped a deck with the totals off by 100×. The full story is the companion piece to this article. The fix lives at scripts/cost_units.py — every cost-report read in the skill now routes through cents_to_usd(). If you fork this, do the same.

Sections four and five answer "who's shipping." Section four is a shipping-gap table: every chat-active user plotted against their commits, lines, and chat overlap, partners separated from staff, multi-repo cutovers narrated in one line. Section five is the leaderboard. Every active user gets a row — archetype pill, six-attribute radar, a verbatim conversation quote as evidence, and a two-sentence exec read of who they are. The six attributes — deep functional expertise, creative problem solver, organized and structured, driver, trusted peer, learns fast — each scored 1 to 5 against actual conversation evidence and commit subjects. The archetypes are descriptive, not evaluative: Builder, Frontier Explorer, Workflow Embedder, Methodical Operator, Coach, Power User.

Section six is the punchline of the people story. Functional AI Lead candidates. For departments that already have a federated AI lead, a featured "lead in action" card profiles them — what they built, what's working, what they should build next, what risk to manage. For departments that don't have one yet, a candidate pool: ranked names from the active users with rationale, risk, and a next-step recommendation. The CEO closes the deck with a short list of people to promote.

Sections seven through ten are the "what's repeatable" layer. Top projects — the ones where the team wrote knowledge files in, so a new hire can pick up the work. Theme map — what the team uses AI for, with top contributors per theme. Recurring use cases — the patterns where multiple people are repeating the same task, the obvious Tiger Team productization targets. Best prompts gallery — 12 exemplary prompts the team should already be sharing internally, each with a one-line "why this is good" rationale.

Section eleven is the action layer. 9 concrete moves the CEO should make in the next 60 days — 6 people-and-process moves plus 3 Anthropic-spend moves (the spend moves auto-inject when the admin API was set). Each move is one sentence. The CEO closes the tab with a punch list.

Every paragraph in the deck got polished by a second skill

Every LLM-generated prose block in the deck runs through a second pass before render. There's a skill called wtf baked in as pipeline stage 10_wtf_polish.py. It applies an editorial-frame discipline to every two-sentence user summary, every candidate rationale, every prompt-card rationale, every use-case description, the featured lead's profile, the CS advisory line. It kills the standard AI tells — delve, robust, leverage as a verb, em-dash plus negation, "X. Not Y." reversals, BLUF-at-the-end. It forces every bullet to translate engineering nouns into business outcomes the CEO actually cares about. Verbatim quotes, sample prompts, evidence citations, numbers, and names: never touched. Only the prose around them.

Why bake it in? The alternative is shipping a deck where every paragraph reads like it came out of an LLM, and the CEO closes the tab in 30 seconds. The wtf pass costs about $2 and 30 seconds per deck. There's no version of this skill that skips it.

Cost expectations and the discipline that catches mistakes

The full pipeline costs roughly $70 to $100 per client run. Sonnet handles the per-conversation passes and the rubric scoring (sync-parallel, ~$55). Opus handles candidate selection, the featured-lead profile, the use-case merge, and the wtf pass (~$15). Haiku handles an optional defensible-counts codebook assignment (~$5).

Every LLM stage routes through a pre-flight cost-guard at tools/llm-cost-guard/cost_guard.py. Under $100 estimated: print and proceed. $100 to $1,000: prompt for y interactively. Above $1,000: type the dollar amount as a --confirm-spend flag matching the estimate within $5. Above $10,000: type a second --i-mean-it flag. The tiers are hardcoded so a runaway can't sneak through.

The artifact

→ Browse the public Northwind Health deployment report

Scroll the whole thing. That's what the skill produces for any team that hands you a chat export, a few git repos, and twenty minutes for an admin key. The deck pictured above is what your team's looks like — point the skill at your inputs.

— Jordan

Written with Claude Opus 4.7

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr — https://edge.blueprintgtm.com/subscribe?utm_source=ote&utm_medium=tier-block&utm_content=annual · Start at $50/mo — https://edge.blueprintgtm.com/subscribe?utm_source=ote&utm_medium=tier-block&utm_content=monthly (most readers start here)

Read more

I asked Claude to write me an exec brief on customer churn. It produced 3,214 words. The recommendation was on page 4. The action layer didn't exist.

This is what every LLM does. Generates. Piles. Buries the point under "comprehensive analysis." A CRO opens it, gives it 30 seconds, can't find what to do, closes the tab.

I rebuilt that brief by hand. Took the same 3,214 words and cut them to 1,180. Moved the recommendation to sentence one. Added a "So what" block under every section — specific verb, specific artifact, by when. Picked one chart out of the eight the LLM produced. Killed the rest.

The result was a 30-second read. Same insight. Cleaner.

I did this for the third time this week and stopped. The pattern was always the same. I was doing the same five operations every time:

1. Find what's important

2. Cut what doesn't need to be there

3. Surface what the reader will actually do with this

4. Specify how they take action

5. Reorder the whole thing so the answer is first

So I built it.

The five questions

That's the Editorial Frame. Every section of the input gets scored 1–5 on each question. Default verdict is `cut`. You only `keep` a section when it earns it.

The questions map to the canon every exec-comms expert agrees on. Tufte's data-ink ratio answers question one — what's important. Doumont's signal-to-noise answers question two — what needs to be there. The military's BLUF doctrine answers three and four — what to do, how to do it. Minto's Pyramid answers five — how it's layered, with the answer first.

That's the whole methodology. Five questions. No frameworks-on-top-of-frameworks. No PowerPoint templates. Just the question every executive is silently asking when they open the document: what do I do, why, and by when?

The lint engine

The skill runs lint on its own output. Not the kind you run on code. The kind that catches LLM tells.

Twelve patterns the model loves and a CRO hates. Any hard hit blocks publish:

reversal cliffhanger      The X wasn't the Y. The X was the Z.
antithesis tic            It is not just X, it is Y.
throat-clearing opener    "In today's...", "As we all know..."
recap signature           "In summary", "To recap", "Key takeaways"
filler transitions        "Having said that", "With that being said"
rigid optimism close      Despite-its-challenges-X-faces-an-exciting-future.
imagine-a-world opener    "Imagine a world where..."
magic-adverb verbs        "quietly transforms", "fundamentally changes"
vague attribution         "studies suggest", "experts argue"
schema leaks              Internal vocabulary in customer-facing prose
inline code chips         Single-line backtick chips scattered through paragraphs
em-dash overuse           > 0.15 per sentence (GPT-4.1 uses 3.3× the human rate)

Plus the AI vocabulary — the words every LLM reaches for and no executive uses:

delve, leverage, robust, seamless, holistic, synergy, paradigm,
empower, harness, streamline, cutting-edge, best-in-class, ecosystem,
game-changer, unlock, elevate, disrupt, tapestry, landscape, notably,
moreover, furthermore, utilize, underscore, pivotal, transcend, navigate,
testament, realm

Any hard hit fires the block. One auto-retry with the lint output piped back into the rewriter. If it fails twice, the skill halts and surfaces the failing draft to me with the hit list. I either edit or override with a written reason. Never silently bypass.

The chart agent

Most LLMs produce charts the way they produce prose. Too many. Mostly decorative. Sometimes misleading.

I gave the chart job to a dedicated sub-agent that reads Tufte first. Twelve rules, applied in order. First match wins:

• Single number, no comparison → no chart (doesn't beat the sentence)

• Two numbers, simple ratio → no chart (bold the numbers in prose)

• Prose already carries the comparison ("37% vs 12%") → no chart

• Time series, 5 points or fewer → sparkline inline

• Categorical, 7 categories or fewer, ranked → horizontal bar, sorted descending

• Categorical, 8 to 25 categories → dot plot (Cleveland: position beats length beats angle beats area)

• Anything pie-shaped → bar chart. Always.

• A chart is required only when removing it loses information the prose can't carry

The agent has read Cleveland on perceptual encoding. Stephen Few on chartjunk. Bertin on visual variables. Cole Nussbaumer Knaflic on attention. Alberto Cairo on truthful visualization. Not as decoration. As constraints.

If charts are required, the skill upgrades the output to HTML automatically. A warning prints. The reader gets the brief styled like the playbooks at playbooks.blueprintgtm.com.

What it doesn't do

It doesn't generate AI hero images. Stock-illustration energy has no place on an exec brief.

It doesn't add words to feel "complete." Length isn't depth. The hard cap is 60% of the original word count. Output bigger than 65% gets re-fired with "cut harder."

It doesn't write what the reader already knows. Methodology sections are the first thing the editor agent flags as `cut`.

It doesn't mention itself in the output. The polished brief is the brief — not a meta-document about how the brief was produced. The reader has never heard of this skill and doesn't need to.

The customer voice problem

Generic exec briefs feel like they could apply to anyone. The fix is the customer's actual words.

My internal version pulls the last meeting transcript from my Sybill stash for whatever company the brief is about. The voice rewriter weaves the customer's specific concerns and vocabulary into the rewrite. The CRO reads it and thinks "this is about us, not a template."

Subscribers don't have my Sybill access. So the version shipped today takes a flag: `--transcript path/to/meeting-export.md`. Drop in any meeting file — Sybill export, Gong, Otter, Fathom, raw notes, anything text — and the skill ingests it as customer-voice context.

The output lands as a local file. The polished markdown copies to your clipboard automatically. Paste into a Google Doc, Substack, email, Slack. Whatever your delivery surface is, it's already on your clipboard.

What I learned

Most "AI bloat" isn't an AI problem. It's an editorial problem we never solved.

Humans have been writing bloated exec briefs since before LLMs existed. The 60-page consultant deck for a one-sentence recommendation. The "executive summary" that's longer than the substance below. The chart that exists because the slide needed three charts.

What LLMs did is industrialize it. The bloat got cheap. The volume went up. The editorial cost — the cost of a real human cutting the thing to what matters — stayed the same.

The skill is what happens when you make the editorial discipline mechanical. Five questions, applied every time. Lint that blocks the LLM tells. A chart agent that knows when not to make a chart.

The 30-second window is the only thing that matters to your reader. Build for it.

— Written by Claude Opus 4.7, Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

A Series B healthcare AI company asked me last week to find them their next SDR leader. They wanted real candidates, not the resumes a recruiting agency would slide across the table for $50K and a 90-day clock.

So I built the recruiter instead.

The first version was a Sunday-afternoon hack. I pointed Blitz API at every company in my filter, fired the LinkedIn employee-finder against each one, ran the resulting candidates through Claude to score them, scraped fresh profiles with RapidAPI on the survivors. By Monday morning the team had a ranked Google Sheet with emails, phones, and per-person narratives. The recruiting agency would still be reading the JD.

That afternoon I kept thinking the same sentence over and over: this is a tool, not a one-off. So I rebuilt it as a Claude Code skill anyone with the right two API keys can run.

Annual subscribers install it now: /edge install talent-sourcer.

Why most recruiting pipelines lose

The default move when you're sourcing is to pick the 50 most obvious companies and search inside those. You list a few competitors, you add a couple of category leaders, you hit Apollo, you scroll.

That's the same move that makes outbound terrible. You sampled the universe — and the sample is small, predictable, and identical to whatever every other recruiter is doing the same morning.

Here's the thing: Blitz is flat-rate. $399/mo for unlimited people search and unlimited company search. The only constraint is queries-per-second — five for most accounts, twenty→fifty for agency tier.

So the architecture changes. You don't sample. You search every company that fits the filter.

For the SDR leader role, that meant 9,000+ NYC companies in the headcount band. The pipeline pulled every plausible person from every one of them. About four hours of compute on the slow tier. Thirty minutes on the fast one.

This is the asymmetry engine applied to hiring. Manufacture more information about every plausible candidate than the recruiting agency has, then deliver the ranked shortlist as a permissionless gift to the hiring team. They didn't ask for it. They couldn't have. You did the work.

The competitor bonus

Most scoring agents look at the candidate in isolation. Skills, tenure, trajectory, location.

I added one more dimension.

If a candidate works at a direct competitor of the company hiring, they get an automatic ranking boost. The agent flags it explicitly in the output.

This is obvious once you say it. A competitor's SDR leader already knows the buyer. They know the industry's objections. They probably know your customers by name because they've lost to them — or won them. They bring market knowledge a generic enterprise sales hire would need eighteen months to acquire.

Recruiters know this intuitively but rarely build it into the search. The pipeline does.

Score the company first, then the person

Here's the move that turned the A-rated list from "interesting" to "good."

Most tools score people in isolation. They don't know what the candidate's employer actually does.

A "VP Sales" at a 50-person healthcare AI company is a different human from a "VP Sales" at Oracle. Same title, same headline, almost no overlap in actual work. The first runs a pod of three SDRs and writes the messaging themselves. The second manages four directors and lives in QBRs.

Before the scoring agents see any candidate, the pipeline enriches their employer. Blitz pulls the company data — headcount, industry, stage. A separate worker downloads the homepage. Thirty companies in parallel. The scoring agent reads both and grades the person inside their actual context.

You stop seeing a list of titles and start seeing a list of people doing comparable work to the role you're hiring for.

What the team gets

The output is two URLs. A three-tab Google Sheet with the ranked candidates, the company context, and the search filters. A Google Doc with an executive summary and per-candidate narratives for the top thirty. Both shared "anyone with link can view" so the hiring team can read it on their phone before standup.

A recruiting agency for an SDR leader role is twenty to fifty thousand dollars and three months. The pipeline is two API subscriptions and an afternoon. You read the same shortlist either way — except the pipeline tells you which two of those candidates currently work at your direct competitor.

That's the trade.

— Written by Claude Opus 4.7, Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

May 6, 2026 · Build log

Your ICP is lazy.

"50 to 1,000 employees in vertical X." That's not an ICP. That's an Apollo filter. You've described a list of companies the same way Apollo describes a list of companies, and you've told yourself you've done strategy.

The companies that write you the biggest checks and stay the longest don't share a headcount band. They share a situation. A specific operational thing that happened to them six to eighteen months before they bought, that almost nobody else on the filter is going through right now. That's the actual segment. Headcount and vertical are how Apollo organized the world. They're not how your customers feel pain.

So I spent the day building a skill that does ICP the other direction. You start from the outcomes you already have — your wins, your losses, your healthy accounts, your churns — and you reconstruct what those companies looked like before they bought. You hunt for signals you can pull from public data that distinguish good-fit from bad-fit. You ship a per-archetype scoring rubric instead of a one-line firmographic.

It's called `win-loss-rewind`. Annual subscribers can install it today. Below is the story of building it.

Outcomes first, hypotheses later

The old workflow: someone in marketing writes "we sell to mid-market HR teams in financial services," everyone nods, the SDRs go work the list, and three months later half the closed-wons are credit unions and the other half are insurance brokerages and nobody's HR team makes the buying decision. The ICP didn't predict anything. It just sounded reasonable.

The new workflow inverts it. You take the customers you actually have, label each one with the outcome that matters — won, lost, healthy, churned, expanded — and treat that as ground truth. Then you ask what those four buckets had in common before you ever spoke to them. Not what they look like now. What they looked like when they walked in.

This is the move Munger's been on his whole career. Invert, always invert. You don't ask "what makes a customer good?" — that's the question that gives you "mid-market vertical X." You ask "what was different about the customers who won versus the ones who didn't?" That question forces specificity. There's always a difference. Sometimes the difference isn't even something you'd have thought to look for.

Distrust your own data first

I almost shipped this thing without Phase 0 and it would've been useless.

Here's what kept happening on test data. The CRM record says "$50K ARR, healthy customer, expansion in flight." Cool. Then I run Firecrawl on their domain and LinkedIn enrichment on their org and discover the company has one employee, no working website, and the LinkedIn page hasn't been updated in two years. That's not a customer. That's a CRM record. Whoever logged the deal moved on, the account auto-renewed once, and now the system thinks they're a healthy expansion target.

You can't build an ICP discriminator on top of records like that. The training data is poisoning the answer.

So Phase 0 of the skill is just sitting on the data and not trusting it. It cross-references CRM labels against external reality — does the company exist on LinkedIn, does the website resolve, does the headcount match what the CRM thinks. Anything that fails gets quarantined. The operator gets a `data_confidence.md` to review and approve before the rest of the pipeline runs.

This step isn't glamorous and most teams skip it. It's also the step that determines whether the rest of the work means anything.

What the deliverable actually looks like

Skip ahead to what comes out the other end. Here's a real example from the fictional GRC SaaS test fixture I shipped with the skill — a compliance-automation product with two customer archetypes hidden in the data:

Archetype: Two-state legal-ops shop,
           no in-house engineer

Signal 1: State professional registrations
          in prior 18mo
  Source:     state SoS portal
  Threshold:  >= 2
  Weight:     0.55
  Lift:       4.1x train / 3.6x holdout

Signal 2: Compliance/GRC role posted
          in prior 6mo
  Source:     Firecrawl careers (keyword)
  Threshold:  present
  Weight:     0.45
  Lift:       3.5x train / 3.2x holdout

Combined fit_score
  = 0.55 * I(reg) + 0.45 * I(role)

"Looks like archetype" threshold:
  fit_score >= 0.60

That's the ICP. Two operational signals from public data. A weighted score. A threshold. A measured lift on training data and on a held-out 20% you didn't show the model.

Look at what's not in there. No headcount band. No vertical. No revenue range. None of the things you'd find on an Apollo filter. Because none of those things actually distinguish good-fit from bad-fit for this archetype. What distinguishes them is did this company recently expand into a second state and hire someone to own the compliance work that follows. That's the pain segment. Everything else is noise.

The other archetype in the same fixture comes out totally different — engineering-shops who built their own compliance code internally, then watched their compliance-tagged GitHub repos go quiet for nine months because the engineer who maintained them moved on. Same company-stage. Same revenue band. Completely different signal recipe.

You'd never write the ICP "compliance-tagged GitHub repos went quiet for nine months" by hand. You'd never think to. The skill writes it for you because it works backward from who actually won.

The vowel-name signal that died at holdout

Here's the moment I trust the work.

When the skill generates hypotheses about what distinguishes wins from losses, it generates a lot of them. Most are good. Some are nonsense. The hard part is figuring out which are which without a human reviewing every one.

In the test fixture, the hypothesis-generator coughed up something like "won customers tend to have company names starting with vowels." Apex, Atlas, Echo, Oak — four out of twelve wins, which on a small training set is a real-looking pattern. Train-set lift: about 2.4x.

It's also obviously horseshit. Company names don't predict buying behavior. The hard gates should kill it at Phase 5 because it doesn't prove pain — and they did, in this case. But suppose they hadn't. Suppose it slipped through.

Phase 6 is the safety net. You hold out 20% of your data from the start, never let any of the hypothesis-generation see it, and at the end you re-test every surviving hypothesis on the holdout. The vowel-name signal collapses to lift ≈ 1.0 on the holdout because it was a coincidence in the training set. Dead.

The real signals — state registrations, compliance roles — hold their lift on the holdout. Train 4.1, holdout 3.6. Train 3.5, holdout 3.2. They survive because they're not artifacts. They reflect actual operational pain.

This is the difference between an ICP you trust and an ICP you've fooled yourself into. You hold out 20%. You test on it. Anything that doesn't survive doesn't ship.

So what do I do with this

If you're staring at your own customer list right now and your ICP is some version of "mid-market vertical X," here's the move. Pull your wins, your losses, your healthy accounts, your churns. Get the outcome label honest — not what the CRM says, what actually happened. Then ask the question backward: what was different about the wins, six to eighteen months before close, in their public data?

Run that question with discipline. Hold out 20% of the data. Force every hypothesis through a "this proves pain, not just correlation" filter. Reject anything that uses headcount, industry, or revenue as the discriminator — those are inputs, not signals. The signals you want are the operational events that preceded the buying behavior.

That's the work. The skill automates it. But the discipline is what makes the answer real.

— Written by Claude Opus 4.7, approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

A 798-page state fire marshal directory.

That's the test case. Every fire department in New Jersey. Names, titles, departments, emails, phones. Locked inside a PDF nobody can export.

Multiply that by every state and every industry. State licensing boards. Federal agency rosters. Trade association member lists. Conference attendee PDFs. There are tens of thousands of contact-rich PDFs sitting on government and industry websites right now, and every one of them is treated like a dead document.

They're not dead. They're a TAM list nobody has bothered to extract.

So I built the tool that extracts them. Today. End to end.

The naive way fails

Hand a 30-row contact table to any vision model. Ask for clean JSON. You get 58% accuracy. Sometimes worse.

I've seen this before. I built `video-list-extractor` last month — same problem, video frames instead of PDF pages. The vision model's attention degrades across a long list. Gemini in particular invents organization names. Claude is better but still drops names, swaps emails, normalizes "Dr. Sarah Chen, MD" to "Sarah Chen."

The fix is not better prompting. The fix is structural: crop each row into its own image, and OCR them one at a time. Same model. Same prompt. 99% accuracy.

That's the insight that made `video-list-extractor` work. It applies to PDFs.

The smart move: don't OCR what you don't have to

Here's the part nobody talks about: most contact-bearing PDFs aren't scanned. They have a real text layer. pypdf can read them at zero LLM cost.

The state fire marshal directory? Native text. The 798-page NJ fire department roster? Native text. I ran my triage script on both. Score: 1.0. Route: text path.

I extracted 5,080 raw contact records from those two PDFs in under a minute. Total LLM cost: zero. The merge step deduped them down to 2,015 unique contacts.

A run that would have cost $25 on the naive vision-everything path cost essentially nothing.

The triage decision is the entire game. Text-rich PDFs go to a regex + pypdf path. Scanned PDFs go to the vision pipeline — render the page, crop each row, dispatch parallel OCR sub-agents (waves of 5, 14 batches, the same architecture that drives `video-list-extractor`). Most PDFs only need the cheap path. Only scanned ones earn the expensive one.

The pipeline

Eight phases. Each one is a script the orchestrator runs in sequence.

1. Pre-flight — validate Serper + Exa keys, ask the user what industry and what fields they want.

2. Discovery — five sub-agents in parallel hit federal databases, state registries, industry associations, Google dorking patterns, and open-data portals. They write candidate PDF URLs to JSON.

3. Download — stream each PDF with a 30 MB cap, save to `/tmp/pcf_pdfs/`.

4. Triage — score each PDF's text quality, route to text path or vision path.

5. Contact-page detection — for big PDFs, identify which pages actually have contacts. Skip the table-of-contents and intro pages.

6. Extract — text path runs pypdf + regex; vision path renders each page at 200 DPI, crops contact rows by ink-density projection, dedupes the crops, and dispatches OCR sub-agents.

7. Merge — combine text-path and vision-path outputs, dedupe across sources, write a clean CSV.

8. Audit — sample random pages, run independent verifier agents, check coverage. Target ≥97%.

That's it. No magic. The structure carries the accuracy.

What it cost to extract 2,015 fire department contacts

Two PDFs. ~820 pages combined. Both routed to the text path.

• Discovery: skipped (I had the URLs)

• Download: free

• Triage: free

• Page detection: free

• Text extraction: free

• Merge: free

• Total: $0.00

If the same 2,015 contacts had come from scanned PDFs through the vision path, the run would have cost roughly $4-6. Still cheap. But the triage saved every dollar.

That ratio is the whole product. A run where 90% of PDFs are text-extractable costs 5x less than one where 90% are scanned. Triage is the lever.

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

A software company asked me last quarter if I could find every landscaper and tree-care operator in the country.

They'd been buying lists from the usual aggregators for two years. The reps kept asking why the same companies showed up over and over. Why their best customers had never been on any of those lists in the first place.

So I ran my TAM research skill against the vertical. One pass.

38 sources surfaced. Foursquare alone had 97,043 unique landscapers and tree services with phones for 99.8% of them and websites for 64%. California's contractor licensing board had a free CSV download with every licensed landscaper in the state — 12,000 companies the aggregators had nothing on. Two trade associations had member directories totaling 5,400 of the exact companies that actually buy software.

And the one nobody thinks of: every state requires a pesticide-applicator license to spray weed and pest treatments commercially. Almost every professional landscaper holds one. So a "pesticide" registry — which sounds like the wrong vertical — is actually a 50-state public roster of the same landscape companies, maintained by law, free to download. That's the move you only spot once you stop searching for the company type by name and start asking what licenses the company is required to hold.

Combined, three of those sources got me to about 85% of the addressable market. For around $0 in data costs.

The aggregator they'd been paying $40K a year had captured maybe 60% of the same vertical, with no way to tell which 40% they were missing.

Why Most TAM Lists Miss the Market

When someone says "find me a list of X," the default move is to type "X" into ZoomInfo and ship whatever comes back.

That's not TAM research. That's giving up on 40% of your market and hoping the other 60% is enough.

Aggregators sell you the companies they happen to have. Government registries hold the companies that legally have to exist on a public list. Trade associations hold the ones that paid to be findable by buyers. Google Maps holds the ones that wanted local customers to walk in.

Those are different lists. They overlap maybe 50% with each other. Whichever one you start with becomes a ceiling on everything you do downstream.

The fix is to start with the question "where does the truth about this vertical actually live?" before you build the list. Most teams skip that step entirely.

What the Skill Actually Does

It runs five phases, in order, on any company type you point it at.

Phase zero is the kill switch. It validates every API key the run depends on before doing any work. Five keys, one fails, the whole thing stops. I built this in after a three-hour run died at minute 175 because Apify's token had rotated.

Phase one reads the client website silently. No questions to me yet. It pulls what they sell and to whom so the next phase can ask sharp questions instead of generic ones.

Phase two narrows. This is the only phase where it talks to me. Always to one company type. "Healthcare providers" is not a company type. "Ambulatory surgery centers" is. "Direct primary care clinics" is. The skill refuses to launch the discovery phase until the segment is narrow enough that a subagent can actually find every instance of it.

Phase three is five subagents in one shot. Federal registries. State licensing boards. Industry associations and niche directories. Google Maps and local business APIs. Open data and web datasets. Each one runs the same hour I run mine, just faster, and reports back in structured JSON with the same fields — what the source covers, how many records, websites included, cost, quirks.

Phase four scores everything. Same rubric across all 38-ish sources. Coverage 35% of the score. Websites included 30%. Data quality 20%. Cost 15%. Coverage and websites do most of the work because that's what determines whether you can actually run outbound off the list. The output is a ranked table plus a recommended two-or-three-source combination that gets you to maybe 85% of the market with minimal overlap.

The whole thing takes about 45 minutes and costs me $2 to $10 in API calls.

The Rubric Does the Hard Part

The thing that makes this work isn't the subagents. It's the rubric.

Without it, every research run becomes a personality contest where the most-cited source wins. With it, you can say "this licensed-contractor database covers 100% of the regulated population, has zero website fields, and is government-mandated, so it scores 70 — and Google Maps scores 74 because it has 80% coverage but every record has a website." Then you stop arguing.

The rubric also forces the obvious next move: combine the high-coverage no-website source with the medium-coverage high-website source, dedupe on phone number, and you've got more reachable companies than either source alone. That combination is what the recommendation table gives you.

Government data wins ties because the data quality is government-mandated. If a company is required by law to be on a list, the list is more complete than anything someone is selling. Most teams forget this.

Why I'm Releasing It Now

Every time I take on a new client, the first hour is some version of this same workflow. Pull their site. Narrow the segment. Fan out across federal, state, association, local, and open-data sources. Score what comes back. Pick the two or three sources that get me to coverage. Hand the build off.

Doing it five times burned the methodology in. Doing it twenty times made me write the skill. Doing it a hundred times made me realize that most teams have never seen the methodology at all — they're still typing the company type into ZoomInfo and hoping.

So it's going up.

— Written by Claude Opus 4.7 (1M context), Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more