You've got a list of company names — tens of thousands of them — and you need a domain for every one. Vendors sell you that for fifty cents a row. On a 100,000-company list, that's fifty grand to look up something the internet already knows.

I built a Claude Code skill that does it for about a twentieth of a cent each. Free where the answer is already sitting in a table I own or in Google's Knowledge Graph. A rounding-error search where it isn't. A cheap model only on the names that are genuinely ambiguous. And it checks every domain against what the site says about itself — so it never hands you a confident wrong answer. The whole list lands for about fifty bucks.

The wall every list hits

Every enrichment job starts the same way. You have names. You need domains. Nothing downstream works until you have them — no contacts, no firmographics, no message.

So you reach for one of three things. You pay a per-row vendor — ZoomInfo, Clearbit — fifty cents a row while the meter runs. You Google each name programmatically and take the top result. Or you hand the whole list to an LLM and ask it for domains.

All three have the same hole: none of them check whether the answer is right. The vendor hands you a domain, the search hands you a domain, the model hands you a domain — and at a hundred thousand rows, you're not checking by hand.

At scale, the data is all over the board

Ten companies, you eyeball it. A hundred thousand, and there's no clean rule that holds.

Sometimes the domain is the name. "Anderson Plumbing Heating and Air" lives at andersonplumbingheatingandair.com — the whole mouthful, the "and" included.

Sometimes the domain looks nothing like the name:

• Boston Medical Center → bmc.org. An acronym. A .org. Nothing in the name points to it.

• Sandy Springs Internal Medicine → ssim.com. Four words collapsed to four letters.

• Mass General Brigham → massgeneralbrigham.org, not massgeneral.org, not .com.

This is where the shortcuts break. Google "Boston Medical Center" and the top hit might be a directory, a LinkedIn page, or a different Boston clinic with a similar name. Ask an LLM and it'll hand you bostonmedicalcenter.com with total confidence — a domain that doesn't exist. The hard part was never the obvious names. It's the tail, where the domain shares nothing with the name, and the top result is wrong as often as it's right.

What the tool actually does: a waterfall

No single source resolves a messy list. So you stack them cheapest-first and stop the moment one is confirmed.

• Free first — two sources cost nothing. Google's Knowledge Graph hands back the official site for any company it already knows, free, a hundred thousand lookups a day. And a local table — twelve million US businesses scraped from Google Maps once — carries the small-business tail, phone included. A big slice of your list clears right here.

• A rounding-error search, for the rest. When the owned table misses, one cheap search call returns the candidate — the same Google lookup you'd do by hand, except every hit has to pass verification before it counts.

• A cheap model, only on the genuinely ambiguous. Parent versus subsidiary. A rebrand. A name forty small businesses share. Most rows never reach it.

• Flag, don't guess. When nothing can confirm the domain, the tool returns needs review instead of a confident wrong answer.

Every tier above costs less than the one below it, and most of your list clears in the first two. That's the spend rule the whole thing runs on: as free as is wise. Free when it's right and fast. A fraction of a cent when that's what makes it sure. Never a flat vendor fee for work the website will confirm.

The advice that wastes everyone's time

There's a tip that gets repeated every time domain resolution comes up: "verify it with the SSL certificate — the cert names the company."

It's a coin flip at best. I pulled the live certificate on twelve well-known companies. Five named themselves. Seven didn't. And there's no pattern you can use:

• Name themselves: Apple, IBM, Stripe, Datadog, Snowflake.

• Say nothing: Anthropic, Notion, Ramp, Shopify, DoorDash, Klarna, Gong.

Old guard and modern SaaS sit on both sides — you can't predict it. Their certs are issued by Let's Encrypt, Google, and Amazon, free authorities that never write a company name into the cert.

Now check the businesses actually on your list. The ones from earlier — bmc.org, ssim.com, the plumber — every one runs a free certificate with no name in it. For the tail, the cert is silent. It tells you who issued it, not who owns it.

So how do you know you've got the right domain? You ask the page. Its title says the company name. Its Open Graph tags say the company name. Its structured data — the block sites publish for Google — often lists the company's own LinkedIn and Wikipedia pages. The site tells you who it is. You verify against that, not against a certificate that's blank two-thirds of the time.

The discipline: a wrong domain is worse than a blank

This is the part most tools get wrong. They'd rather return something than nothing.

But a wrong domain doesn't just waste a row. It poisons everything downstream — you enrich the wrong company, you find the wrong contacts, you send a stranger a message about a problem they don't have. A blank you can fix later. A confident wrong answer you ship.

So when the page can't confirm it, the tool says so. "Summit Roofing," no city, a dozen live candidates and nothing that proves which — needs review. It doesn't pick one and hope. That refusal is the feature.

Own the data, don't rent each lookup

The free tier — the twelve-million-business local table — isn't mine. Eric Nowosolski (GrowthEngineX) scrapes Google Maps and ships it open-source. Credit where it's due.

Own the data once, stop renting each lookup. The phone that disambiguates "Riverside Dental in Portland" from the one in Kansas is just sitting in the row. You don't pay a vendor per call for a fact you can hold locally.

The cost, honestly

It's not magic, and the tail is real. On a hard test slice, the confident majority resolved clean and cheap; the rest got flagged for a human instead of guessed. I measured the bill: about $0.0005 a name — fifty dollars for a hundred thousand. The free Knowledge Graph carries the companies Google already knows, the owned table carries the small-business tail, a rounding-error search picks up the rest, and a cheap model settles the genuine ambiguity.

That fifty assumes you're buying search at volume — run a small one-off list at retail pricing and it's closer to a hundred. Either way: your vendor charges fifty cents a row for the same list, skips the verification step, and bills you fifty thousand dollars for a list you can't trust. Fifty dollars for one you can, or fifty thousand for one you can't.

It was never really about domains. The same move — take the cheapest source that actually knows, verify what the thing declares about itself, refuse to assert what you can't confirm — resolves LinkedIn URLs, parent companies, rebrands. Verify, don't buy.

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

My friend Matt Braley was at Chili-palooza last week with me.

He texted me. He wanted to see Claude.

Most people, when they say that, they want a demo. Watch me type a prompt. Watch the cursor blink. Watch a paragraph of marketing copy appear. Then they nod. Then they go home and don't change anything.

That's not what I do anymore.

I told Matt to come over. We sat down. I opened my laptop. I said, "What do you actually need."

He's a CRO. He sells big-deal vertical SaaS, and he advises a portfolio of AI companies. He was at a conference and wanted to follow up with people. He wanted leads — not in general, leads scored against him.

Sixty minutes later he walked out with one Google Sheet. Three tabs. Every tab was a working list he could call on Monday, all three graded against the same one-page rubric of who Matt actually is.

This is what showing Claude looks like now.

The three tabs

First, the rubric. Before any of the three tabs, we built one file: matt_profile.md. I pasted in his LinkedIn, then ran three sub-agents in parallel to enrich what was missing — his AI advisor portfolio, his investor network from Stage 2 Capital, his exit history at EngageSmart. The output was a one-page profile of who Matt is, who he's already talking to, and what kind of person it would be a waste of his time to meet.

Every score on every tab grades against that file. Same rubric, three populations. That's the only reason any of this means anything.

Every attendee at the conference, scraped and enriched

Matt sent a screenshot. Some WhatsApp group from the conference had dropped a link: ████████████████████████████.lovable.app. Chili-palooza had built a Lovable app that listed every attendee — name, company, title, LinkedIn URL, all alphabetized A through Z.

Claude OCR'd the URL out of the screenshot. Loaded the Lovable app. Walked every letter section A–Z. Pulled 138 attendees into a CSV with name, title, company, and LinkedIn.

Then enrichment. For every attendee Claude pulled the full LinkedIn profile via RapidAPI — work history, location, headline, photo. Then the company side: what the company does, headcount, funding stage. Then FullEnrich for cell phone and personal email on every row.

That's one tab. 138 humans, every one of them with a phone, an email, a LinkedIn, a company description, and a photo. Matt didn't make this. He didn't pay for this. Chili-palooza handed him an A–Z directory and we turned it into a contactable spreadsheet in about fifteen minutes.

Every Series A–D vertical SaaS startup that raised in the last year

This tab has nothing to do with the conference. This tab is about the rest of Matt's year.

I host 501 public go-to-market playbooks at playbooks.blueprintgtm.com. Every one is a real vertical SaaS deal I've worked or modeled — the company, the segment, the pain, the data signal. Three years of pattern library.

I asked Claude: take all 501. Filter to the ones where the company itself raised Series A through D in the last twelve months — that's Matt's investing band. Find the CEO, the founder, the CRO, the president. Find their email. Find their phone. Score every one of them against Matt's same rubric.

It's an eight-stage pipeline. Each stage writes a checkpointed CSV so I can re-run any step. Stage 1 loads the 501. Stage 2 hits Exa for funding news on every domain and uses GPT-4o-mini to extract the round and date — 501 in, 54 out. Stage 3 resolves each surviving domain to LinkedIn via Blitz. Stage 4 runs Blitz's waterfall to find every CEO, Founder, CRO, and President — 169 contacts stacked across the 54 companies. Stage 5 enriches each contact's LinkedIn profile via RapidAPI. Stage 6 finds email and cell phone for all 169 — Blitz first, FullEnrich on the misses. Stage 7 grades every one with Sonnet 4.6 against Matt's rubric — fit score, fit band, the talking point. Stage 8 writes a tab on the same Google Sheet.

Matt's not getting a list. He's getting an ordered queue. The top is the call he should make Monday morning. The bottom is the people he should skip. Every row already has the talking point. He doesn't have to think about it. He has to dial.

Every conference attendee scored against Matt — five swarm agents, six minutes

Back to the 138 attendees. Out of 138 people, who should Matt actually walk up to.

This is where I stopped touching the keyboard and let agents do it. Blueprint Swarm: five Opus sub-agents in parallel, each one given Matt's profile and a chunk of the attendee list. The job for each sub-agent — read this attendee's LinkedIn, read Matt's rubric, score the fit 1–10, label it high/medium/low, write the reason, write a one-line conversation starter Matt could literally say to them at the bar.

Five agents, 138 attendees. About six minutes wall-clock.

Output: 33 high, 65 medium, 40 low. Every row had a paragraph of reasoning and a tailored opener. "Curious how you're thinking about attribution for AI-driven outbound at Upside — at EliseAI we're wrestling with how to credit pipeline when an agent is doing 80% of the touches. Where does Upside draw the line?" That kind of opener. Specific to that human, written by an agent that had read both their LinkedIn and Matt's bio.

Then Claude built a mobile-responsive HTML leadbook out of it. Photos, filters by tier, click-to-call, click-to-email, the conversation starter visible right on the card. Modeled after a leadbook I'd built for a previous client. Published it live with the publish-html skill so Matt could open it on his phone walking into the next session.

That's the third tab — same data, ranked, with the talking point.

What this is not

This is not a demo.

A demo is when you show someone the tool and they leave with a story. "Jordan showed me Claude. It was cool."

This is when you show someone the tool and they leave with the work. "Jordan and I built three lists. I'm calling forty of these people on Monday."

The difference is whether the thing you made survives the meeting.

Most demos don't. The screen goes dark. The slides go away. Nothing changes on Monday. ← OPUS LOVES THIS FUCKING PATTERN!

What we did survives because Matt has it on his laptop. He has the GitHub repo — I invited his braley-ai handle so he owns the code. He has the Google Sheet shared to his email. He has a published HTML leadbook on his phone. He has a license to re-run the whole pipeline next time he goes to a conference.

The asset doesn't depend on me being in the room.

The hour

I want to be specific about the hour.

We didn't write any code by hand. I didn't pull up a notebook. We didn't open a Python file together.

I told Claude what we were doing. Claude scraped the Lovable app. Claude built the enrichment pipeline. Claude spun up the swarm. Claude wrote the HTML leadbook. Claude built the eight-stage playbook pipeline. Claude pushed every output to the same Google Sheet and to a published page.

I sat next to Matt the whole time and narrated. "OK now we're scraping the directory. Now we're enriching contact data. Now the swarm is reading his profile. Now we're scoring 138 people against him in parallel."

Matt didn't need to learn anything. He needed to see the shape of it.

That's what showing Claude is. You sit next to someone. You tell the agent what you both want. The agent builds the thing. The other person watches the shape of the work and goes, "Oh. That's how this is supposed to feel."

Why I'm writing this down

Because most of you, when somebody asks to see your tool, you still do a demo.

Stop.

Ask them what they need. Build it while they watch.

If you can't build it in an hour, your tool isn't ready. If you can build it in an hour and you're still doing slide decks, your job isn't selling — it's stalling.

The shift is small and total. Demos are about you. Builds are about them. One ends with a thank-you email. The other ends with three tabs, a published leadbook, and 169 vertical SaaS CEOs already scored against your rubric.

Matt's calling forty people on Monday. He didn't see Claude. He used it.

That's the only version of "showing Claude" I do anymore.

What Annual Adds

This one was free. Paid gets the build. Annual gives you the tools that run it.

• Every tool I ship. Edge Copilot installs to your Claude Code — talk to all my knowledge, every method, every data source. Current: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor. Whatever ships next is included.

• All 3 courses: GTM Engineer, Pain-Qualified Segments, The Inversion.

• Weekly office hours.

Run /edge install agent-swarm once your license key arrives — the swarm I used to score Matt's 138 attendees drops into your Claude Code in one command.

License key hits your email.

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

Every post you've read on this Substack was touched by six separate systems before it reached your inbox. Not one of them is Substack's editor.

I didn't plan it this way. It started with a session capture hook — a script that fires at the end of every Claude Code session and logs what I built. That was March. By May I had 40+ scripts, 5 sub-skills, a 458-entry knowledge corpus, and a publishing pipeline that bypasses Substack's own tools because they can't render images correctly.

The whole thing runs for about fifty cents a post.

This is what's behind the curtain.

The six systems

1. Session capture. A hook fires every time I close a Claude Code session — any session, any project, anywhere on my machine. It reads the transcript, extracts what tools I used, what files I touched, what topics I worked on. Tags everything to a taxonomy. Appends to a daily log. When enough sessions pile up on the same topic, the queue tells me I have material for a post.

I don't decide what to write about. The capture system tells me.

2. Voice enforcement. Three files govern everything that sounds like me. A style guide extracted from 20+ transcript recordings. An anti-patterns list with 18 categories of words and patterns I never use — "game-changer," "leverage," "dive into," "unlock," all dead on arrival. And a translation map that catches internal jargon before it leaks into prose.

Every draft runs through automated grep checks before it gets near Substack. If it catches "methodology" or a bare CLI flag in narrative text, the draft blocks. No exceptions.

3. Headline optimization. Every title scores on six axes: Specificity, Action Promise, Pattern Interrupt, Identity Signal, Curiosity Gap, Readability. The system generates 3-4 alternatives with subtitles and SEO titles, then runs demand research through Serper and Exa — what people actually search for, what questions they ask, how saturated the topic is on Substack.

Cost: four cents per research run. The 33-character rule is enforced automatically. Gmail mobile truncates there. If the first 33 characters of your title don't stand alone, you've already lost the open.

4. Image generation. Every post gets images — no exceptions. One per 200-300 words. Half are AI-generated via Gemini (concept illustrations in the calligraphy aesthetic you see on every hero). Half are programmatic — HTML templates screenshotted through headless Chrome. Quote cards, stat cards, framework diagrams.

I built the programmatic pipeline because Gemini can't reliably produce stat cards with correct numbers. Turns out an HTML template with Playwright is more reliable than a diffusion model for data visualization. Who knew.

5. Publishing pipeline. Substack's MCP tool can't render images. Its markdown-to-ProseMirror conversion puts image types in the wrong field and leaves critical attributes null. Images show up as raw text.

So I reverse-engineered the ProseMirror JSON schema and built a direct API publisher. It converts markdown to the exact node structure Substack expects. Uploads images to Substack's CDN, builds the JSON document, PUTs it directly to the API.

The auth is self-refreshing. A wrapper script pulls the session cookie from Chrome on every launch. No credentials stored on disk. No rotation. Sign in once in your browser, the pipeline handles the rest.

6. Knowledge corpus. 458 entries organized in four layers — Resources, Ideas, Context, Evidence. Nine kinds of page. Every entry carries structured metadata with tier gating, bitemporal validity, and a closed vocabulary of 13 relationship types.

This is what Edge Copilot reads when subscribers ask it questions. The corpus is the brain. The Substack is the mouth.

The numbers

• 40+ scripts — Python, TypeScript, shell

• 5 sub-skills — content generation, headline optimization, image generation, session capture, Slack recaps

• 458 wiki entries — the Corpus behind Edge Copilot

• $0.50 per post — Whisper transcription + Gemini images + headline research

• $0.04 per headline research run — Serper autocomplete + Exa semantic search

• 6 API keys — Anthropic, OpenAI, Google AI, Serper, Exa, Substack (cookie-based)

— Written by Claude Opus 4.6, Approved by Jordan

Below is how every piece connects — the architecture, the pipeline order, the APIs, the costs. Enough to understand the system. Not enough to clone it.

If you're a fellow Substack creator and want the actual repo, DM me on LinkedIn. This isn't part of the annual subscription. It's a separate conversation.

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

Read more

April 7, 2026 · Build log

A vertical SaaS company has 1,200 churned accounts sitting in their CRM. Dead customers. Money that walked out the door. The CRO wants to know one thing before the board meeting: could we have seen any of this coming?

Not from internal usage data. Not from NPS scores. From the stuff anyone can pull up in a browser — public company registrations, Google profiles, BBB filings, LinkedIn, socials.

If the answer is yes, the churn problem isn't a churn problem. It's a qualification problem that got missed at the top of funnel.

So I pointed a swarm of research agents at it. All parallel. Each agent taking a single account and running it against the same five hypotheses — is this the right type of operator, is there a specific pain the product actually solves, are the stakeholders multi-seat or a one-person show, is there a real decision-maker on the deal, and does the company's age and operating footprint match the customers who stay. Validate or invalidate each one with public evidence. Write the findings as structured records. Move on.

Here's the tension. If I'm wrong — if churn really is random or driven by stuff you can only see post-sale — then this whole exercise is theater. The board gets a pretty report. Nothing changes. Sales keeps selling the wrong people and the bucket keeps leaking.

If I'm right, the sales team has been qualifying on vibes for years and nobody noticed.

The swarm came back. 19% of the churned accounts weren't even the right kind of operator. Not close. Wrong business registration category, wrong service model, the kind of miss you can spot in under a minute of browser research. That's sales closing deals they shouldn't have pitched.

Six signals survived the cut. Specific pain present. Multi-stakeholder engagement on the deal. Side-job operators versus full-time. Decision-maker absent from the call history. Deal velocity. Company age. Two signals I wanted to matter didn't — public review volume barely moved the churn rate, and whether they were switching from a named competitor barely moved it either. Cut them both. If it's not predictive, it doesn't belong in front of a board.

Then the report broke.

I'd handed the synthesis to Claude Opus in the afternoon. Clean HTML, charts, the whole thing. Opened it up in the evening and four signal bars were showing 0.0%. Opus was emitting percentages in a format the renderer didn't understand. Classic. I stopped trusting the synthesis layer and pulled the bar values directly from the raw per-account CSV. Bars came back.

The second problem was worse. The report listed churned account names in a recovery section with no way to actually act on them. A name in a PDF doesn't help a CS rep on Monday morning. So I embedded the underlying tables straight into the HTML as base64-encoded CSVs. One per archetype. One per closed-lost reason. One per risk tier. Every bucket with a count got a download button next to it. Each row carries the ICP score, the signals in plain English — switching from a named competitor, multi-stakeholder engagement — and the risk factors. Not codes. Not internal gate IDs. Words a human can read.

Last pass was the language audit. Opus had been helpful and creative, which is to say it had editorialized all over the thing. "ARR destroyed." "Ghost company." Names for the gating logic that read like internal Slack jokes. None of that goes in front of a board. I wrote a sanitizer that runs at render time. "Destroyed" becomes "lost to churn." Internal nicknames become plain descriptions of what the check actually does. If a board member has to ask what a word means, I've already lost them.

Shipped to a password-protected URL an hour before the meeting. The conservative-gate scenario pressure-tests next. If the model holds up when a skeptical CFO tries to poke holes in it, the sales team gets a new qualification checklist on Monday and 19% of their pipeline stops existing.

That's the right outcome. Smaller pipeline. Better close rate. Customers who actually stay. The board's job this week is to figure out if they believe it.

The lesson I keep relearning: a synthesis layer is a narrator. Narrators embellish. When the output is going to an executive audience, pull the numbers from the source, never from the narrator's summary.

— 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

April 5, 2026 · Build log

The repo looked like a junk drawer.

A dozen directories at the root with no organizing principle. Duplicate skill folders. A dead worker project sitting there like a ghost. Loose PNG files. A stray interview-prep HTML file parked next to the Vercel configs. I'd been meaning to clean it up for weeks.

You know the feeling. It's the codebase equivalent of that drawer in your kitchen with the batteries, the takeout menus, and one rubber band. You keep opening it. You keep closing it. You keep not dealing with it.

Today I dealt with it.

I kicked off three research agents in parallel — one auditing structure, one auditing Vercel deployments, one auditing symlinks. They came back with a full inventory. The plan wrote itself. Two buckets for skills — enrichment and blueprint. Four new top-level directories for tools, knowledge, infrastructure, and assets. One rule for the products with brand names: those stay at the root, where they belong.

Then I executed the moves in logical chunks.

Here's where it got ugly.

One of the subdirectories had a hidden Git directory tucked inside it. Which means it wasn't tracking as part of the monorepo at all. It was a repo hiding inside a repo, pretending to be a folder. I stripped it, added it back as a Git subtree, and wired the symlink so Claude Code could find the skill. That took three tries. The first two, I had the subtree pointing at the wrong ref. Git does not care about your feelings when you do this.

The marketing site problem hit right after the push. When I'd committed the marketing site nested inside the Blueprint Cloud project, the Next.js compiler decided the marketing pages were Blueprint Cloud routes. Vercel build broke. Red everywhere.

The fix: untrack it, move it to the repo root as a first-class product directory next to the other brand-name products, and guard it in gitignore so nobody nests it again. Then I updated the project docs so the next person — probably me, in three weeks, with no memory of today — knows why it lives there and why it's manual-deploy-only.

That was session one. Session two was this thing. On the Edge.

The design question was simple and hard: how do you make a Substack sound like me and not like a polished pundit blog? I've read those. You've read those. They all sound the same because they all start with "In today's rapidly evolving landscape" and end with three bullet points nobody will remember.

The answer was to start at the capture layer, not the writing layer.

I built a Claude Code hook that fires every time a session ends. It reads the transcript, tags the work against a taxonomy tree I'd mapped out, and writes the session into a daily log. A queue file holds readiness scores so I can see which topics are warming up. Then the principles file — no fabrication, clients are sacred, information ink. A section and topic tree. An anti-patterns file pulled straight from transcript analysis, so the thing knows what I'd never say. Kyle Norton got his own page (I ripped all he has ever said — and gave it to him so he could use it.)

The notification rule: stay quiet unless five sessions pile up on the same topic, or eight total. I do not need another tool pinging me.

Then came the unlock. And it came from one message.

I'd written a first draft that morning about pain segments. It read fine. It sounded like me. It was also completely made up — a composite campaign with invented numbers, the kind of thing that sounds real but isn't. I was about to ship it.

Then I got a note from Jacob: "Last week I ran two campaigns. Same ICP. One got 1.2% positive replies. The other got 11.4%."

Real numbers. Real campaigns. And my draft had nothing to do with either one.

I deleted it.

That's the rule now, baked into the capture layer: never invent the scenario. Write from what actually happened or don't write. The next pain-segment post goes out when there's a real session to anchor it to. Not before.

A Substack that invents the example proves you're a writer. A Substack that only writes what actually happened proves you're a practitioner. Those are different products. Only one is worth reading.

— 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

March 26, 2026 · Build log

"Wait, wait, wait. You have zero call transcripts."

That was me, mid-session, staring at a finished churn analysis. Three years of customer data. 2,400-plus accounts classified. Churn patterns, active health, deal counts, all split by tier. The agents had run. The report script had opened. Every dossier looked complete.

Then I scrolled. Five customer voice snippets per account. No transcripts. None.

The whole thing was CRM metadata wearing a costume.

Here's the thing. We had 72,000-plus call recordings sitting in the database. Over 500 megabytes of actual human conversations. Churned customers explaining why they left. Champions describing botched onboardings. The reason we pulled those recordings in the first place. And the agents had ignored all of it, because the dossiers they were reading from had five snippets stapled on top of CRM fields and called it a day.

It's like hiring a detective, handing them the suspect's LinkedIn, and asking them to solve the murder.

So I killed it. Started over.

A parallel session had been doing the right thing in the background — enriching every dossier with the actual call transcripts. While that ran, I wrote four new agent definitions: a churn forensics pass, an active health pass, a churn classifier, and an auditor that sits on top of the whole thing. Plus a batch preparation script and a status monitor. Nothing fancy. Just the plumbing to fan work out across a lot of agents and catch them when they lie.

Before I launched eight hundred-plus agents, I tested three accounts by hand.

One rich account with sixteen transcripts. Confidence score came back at 0.92. Eighteen verbatim quotes. A full story about a champion who got burned by onboarding. That's what good looks like.

One metadata-only account. Confidence: 0.35. The auditor correctly flagged it as a data quality disaster — 167 timeline entries misattributed from other accounts. The agent didn't try to make something up. It said "this is broken" and moved on.

One thin account with almost nothing. Confidence: 0.15. Output: "Unknown / Insufficient Data." No fabrication. No hallucinated insight. Just silence, which is exactly what I wanted.

All three passed. Ship it.

The final swarm: over eight hundred agents across two tracks. Churn forensics on one slice of accounts. Active health on another. Originally I'd assigned the thinnest accounts to Haiku to save money. I was wrong about that. A thin account deserves the best read of whatever scraps exist, not the cheapest. A thin dossier is harder to read well, not easier. I reassigned everything to Opus and launched in waves of ten.

If I'd shipped that first version to the client, the deck would have read clean. Charts, percentages, churn reasons ranked by frequency. It would have been convincing. And every conclusion would have been built on structured field data from a CRM nobody trusts, instead of the seventy-thousand-plus recordings of customers actually telling us what happened.

That's the failure mode with agent work. The output looks done. The files exist. The JSON is valid. The dashboard renders. You have to actually read what went in.

One quick aside from later that night. I pulled up the agent-swarm skill and spent thirty minutes writing plain-English copy for it — ten numbered steps, a three-sentence pitch. Not for a report. Just so I could explain to someone why fanning out across parallel Opus agents with a mandatory auditor beats one giant context window trying to hold everything. The short version: you test on three before you fan out to eight hundred, and the auditor catches the fabrications before they hit your output.

Next up: wait for the remaining batches to land, run synthesis across the full account list, and read the damn transcripts this time.

— 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

March 24, 2026 · Build log

Every vertical I've built this year started the same dumb way. Fire departments. Chiropractic software buyers. 3PL logistics. Each time I'd sit down and hunt for data sources by hand. Score them in my head. Pick an anchor. Hope I picked right.

Three builds. Three different patterns. Zero shared code.

My pipeline had six phases on paper. Five of them worked. The sixth — the one at the very front, source discovery — was an empty file and some comments in a doc. The most important decision in the entire system was getting made on vibes.

I didn't want to just build it. I wanted to see the hole from the outside first.

So I asked Claude to explain the whole pipeline back to me in plain English. The six-phase arc. The dual-file schema — canonical for salespeople, enriched for everything else. The sub-agents. Then the question that mattered: what's not built?

Phase 0. No scorer. No registry. No build planner. Nothing.

Here's what bugged me. I had done source discovery. Three times. It just lived in my head and in three different codebases that didn't talk to each other. The fire department work ran through ten phases and about eighty-nine scripts, all anchored to a national incident registry. The chiropractic build used Google Maps plus a federal provider registry with address-based fuzzy matching. The logistics work needed multi-attempt domain resolution — fuzzy first, then Serper, then Exa, then OpenWebNinja — because single-pass resolution shits the bed on messy company names.

Same shape every time. A scored anchor source, a universal entry point, a plan. I just kept rebuilding it from scratch like an idiot.

I sent three agents in parallel to read the three old builds and tell me what they had in common. Patterns came back fast. Every successful build had the same implicit structure — I'd just never externalized it.

So I built Phase 0 that afternoon. A schema module for the constants — source categories, access methods, pipeline phases. A source-discoverer sub-agent. A scorer with a four-criteria rubric: coverage, website presence, data quality, cost. Plus a registry, a field mapper, a build planner, a research adapter, and an init.

Four verification tests. All four passed on the first real run.

The national fire incident registry scored 70 and ranked first — which is exactly right, because that's the anchor I'd actually used when I built that vertical by hand. The scorer matched my intuition on the one build I knew cold. That's the only way you trust a scorer the first time you turn it on: you make it explain a build you already understand, and you check whether it agrees with you.

Here's the part that actually mattered, and I almost missed it.

My first instinct was to treat Phase 0 as a one-time thing — the step you run when you start a new vertical. That's wrong. This needs to run for everything. Every re-run. Every refresh. Every time the data landscape shifts under a vertical I already built. Data sources disappear. New ones show up. Costs change. Coverage changes. If Phase 0 is only the kickoff, you've frozen the pipeline to whatever was true the day you launched it.

The source registry isn't a kickoff step. It's the universal front door. Updated all four architecture docs to say so before I closed the laptop.

Next up: Phase 1 ingestion. Pull the winning anchor into the canonical companies file and kick off the enrichment waterfall. But that's tomorrow.

The thing I keep re-learning: the build that matters is usually the one that turns a pattern you keep repeating into a thing that repeats itself.

— 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

Last year I ran the same question against two SaaS vendors: who uses this thing?

Jira: 80+ confirmed customer tenants. Three hours. $0.

Jane App, a patient-portal EHR: 34,677 practice domains across sixteen platforms. One afternoon. $148 all in.

Different cost. Different tools. Different technique entirely. And if I'd tried Jira's technique on Jane App, I'd have gotten zero. Vice versa.

That's the most expensive lesson in vendor-customer discovery, so learn it off my dime: silver bullets are vendor-architecture-dependent. Before you write a scraper, you have to diagnose what kind of vendor you're hunting.

Family A — the embed trick. EHR vendors ship JavaScript and iframes that practices paste into their own websites. The embed is the product. Jane App's value to a practice is the booking widget that lives on yourclinic.com/book — the practice doesn't move to janeapp.com, they integrate Jane's code into their site.

That means every Jane App customer's website contains Jane's code in its HTML source. Every one. PublicWWW indexes 516 million pages of HTML. Query: "cdn.janeapp.com". Get back every site that loads Jane's script. Thirty queries across sixteen EHR platforms cost $148 and returned 34,677 domains at 80%+ precision.

Family B — the tenant trick. Jira Cloud doesn't embed in customer sites. Every Jira customer gets their own subdomain: acme.atlassian.net, beta-corp.atlassian.net, fifty thousand of them. PublicWWW finds zero of those tenants. It finds Atlassian's own marketing site and some blog posts that link to acme.atlassian.net. Not customers.

What works: Common Crawl has crawled the web 121 times. Each crawl writes a CDX index listing every URL it hit. Query all 121 indices for **.atlassian.net*. You get a noisy list of candidate subdomains.

Then the dagger. Atlassian returns a specific HTTP header on 404s for tenants that don't exist: atl-missing-tcs: true. For tenants that DO exist, that header is absent. Run a HEAD probe against each candidate. Binary 1/0 confirmation. No false positives, no false negatives. Three hours, 80+ confirmed tenants. $0.

Family C — the logo wall. Most enterprise B2B vendors display customer logos on a /customers or /case-studies page. Near-100% precision because the vendor's legal team approved every logo. Crawl the page once, extract names from alt-tags, resolve to domains. Marketing teams can't help themselves.

Here's the asymmetry. PublicWWW query for "atlassian.net" returns Atlassian's own marketing pages. Not customers. Customers don't embed Atlassian's HTML — they ARE Atlassian, at a subdomain Atlassian itself hosts. Family B HEAD probes against Jane App sweep for **.janeapp.com* subdomains Jane doesn't use. Generic 404 with no signature header. Zero. Family C scrape on a vendor without a customer page — zero.

The scraper isn't broken. The scraper is matched to the wrong architecture. The fix isn't more queries, better regex, or a more expensive tool. The fix is diagnosis first.

That's the whole lesson. Three families. Ask which one applies before you write anything. Yes to "does it embed in customer HTML?" → Family A. Yes to "does it host customers at subdomains with a tell?" → Family B. Yes to "does it publish a customer page?" → Family C. No to all three → you need a swarm, not a silver bullet.

Diagnose first. Scrape second.

— Written by Claude Opus 4.7, Approved by Jordan

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

Or don't. Annual subscribers don't build it. They type the vendor name into Claude Code and the tool shows up.

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

Read more

April 13, 2026 · Build log

Here's the thing nobody tells you about shipping an AI product: the problem isn't the model. The problem is memory.

Every time a subscriber typed /edge into their terminal, Claude was starting from scratch. No sense of what I'd written. No sense of what I'd built. No sense of the years of actual work sitting on my desktop. Just a menu of six commands and a shrug.

That's a search bar with extra steps. That's not me in your terminal.

So I read a Karpathy gist yesterday about LLM-maintained wikis. Raw sources stay immutable. The model keeps a set of structured pages. A schema file governs the rules. Read it twice. Thought: that's the thing. Not a vector store. Not a RAG pipeline. A wiki with a contract.

Then one idea compounded four times before I slept.

First compound: the schema. Before writing a single page, I needed to know what a page even was. I pushed four research agents at the problem in parallel — one mapping how other people have solved it (Obsidian, MemGPT, Graphiti), one grounded in my actual transcripts and articles, one pressure-testing what a single pattern page should look like, one arguing about how tools should live alongside concepts.

They came back with the taxonomy I wanted. I named it RICE — Resources, Ideas, Context, Evidence. Nine kinds of entries. Thirteen ways they connect. Three tiers — free, paid, annual — baked into the page itself, not bolted on at the API. Pages never get deleted, only invalidated. That last rule matters more than it sounds: the wiki gets to be wrong on purpose, because wrong-and-visible teaches better than missing.

Second compound: it had to actually work end to end. I walked the full subscriber flow — register, email, install, verify, lookup — and hit two bugs that would have burned everyone. The subscriber sync was regenerating user IDs on every run, which meant every license key died every time the cron fired. Silent, recurring, catastrophic. The fix was obvious once I saw it. The lesson wasn't: anything that runs on a schedule and touches identity should be a read-then-update, never a blind write. I've shipped that bug three times in different products this year. Locking it in as a pattern now.

Third compound: the voice layer caught me leaking. A parallel session flagged that I was letting internal vocabulary into subscriber prose — schema words like "entities" and "primitives" and numbered section IDs. Words that mean something to me and nothing to a reader. If your internal nouns reach the reader, you've built a database, not a product.

So I wrote a translation map. Every internal noun gets a reader-facing substitute. "Entity" becomes "page." A grep check runs before publish. Three places the leak gets caught before anyone sees it. This is the boring work that separates a thing I built for myself from a thing someone else can use.

Fourth compound: fill it, then change the interaction. I ran a six-pass sweep across my active work — verticals, data sources, tools, patterns, people — and wrote the whole thing into the wiki. That part was mechanical.

The part that wasn't mechanical: the old /edge was a menu. You picked a command. You got a thing. The new /edge is presence. You type anything — a question, a project, a half-formed idea — and the skill reads what you're working on, finds the closest page in what I've written, pulls the content into Claude's context, applies it to your situation, quotes me directly, ends with one sharpening question.

Pull. Reason. Apply. Not "here's a link to an article." More like — what would I say if I were reading over your shoulder right now.

There's also a watch mode. Flip it on and the skill fires on every tool call you make, checks what you're doing against the wiki, writes a one-line hint into your status bar if you're touching something I've already solved. Ambient, not interruptive. The terminal itself becomes the reminder.

I rate-limited it hard. 50 full-page fetches per subscriber per day. Auto-kill at 100 requests in 10 minutes, because somebody was always going to try to scrape it. These limits aren't about cost — they're about forcing the skill to be selective. If you can pull everything, you pull everything, and then nothing is signal. The cap makes the skill choose.

Here's the shift that matters, at least to me: subscribers aren't searching anymore. They're being remembered to.

Search is a question you ask. Memory is a voice that shows up when you need it. Those are different products. One gives you a list of blue links. The other pulls an opinion into the room you're already in.

Every RAG pipeline I've seen tries to make search feel like memory by stapling a chat interface on top. It doesn't work. The model is still retrieving strings and hoping they're relevant. The subscriber is still the one doing the reasoning.

A wiki with a contract inverts it. The model maintains the pages. The pages know what tier they are. The skill knows when to surface them. The subscriber just works, and the right context shows up on its own.

That's what I'd been trying to build for months and couldn't name. A gist from Karpathy named it in one read.

— 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

April 1, 2026 · Build log

Opened Claude Code and found a Supabase service key hardcoded as a fallback in 3 Python files inside a client repo. Not in an env file — in the source code, committed, visible to every collaborator on the project. Anyone with read access could upload anything to my Supabase storage. The fix took about 20 minutes: strip the hardcoded values, commit, push. But the key was still in git history. So I had Supabase disable the legacy JWT keys entirely and issued new ones. Then updated ~/.env locally, Vercel env vars, and Modal secrets. One incident, five places to patch. Lesson: fallback values in source code are just hardcoded secrets with extra steps.

While that was in flight, I ran a playbook audit on playbooks.blueprintgtm.com. The domain search index had grown to 615 entries, and a chunk of them were junk — 28 "Not a Match" rejection pages, empty stubs with "No messages generated" in the play sections, and auto-generated test entries. Pulled all 615 through a content checker, removed 106 bad entries, brought the index down to 509. Also found 2 empty stubs in the showcase catalog — both had the framework scaffolding but zero plays — and removed them. Catalog went from 503 to 501.

The longer session was a technology detection build for a vertical SaaS client. The problem: a database of ~32K records had only 6.3% coverage on which technology each account was running. I knew the data was there — 55,097 scraped web pages sitting on disk from an earlier crawl. The original keyword scan had missed most of it because the fingerprints were too shallow. So I wrote enrich_tech_scan_scraped.py: a regex scanner that runs 22 vendor fingerprint configs against every local file. Each vendor config has primary keywords, secondary keywords, URL patterns, and known customer page structures. No API calls, no cost, just pattern matching against what we already had.

The real win came from a different script — an async subdomain prober. One vendor's customer portals all follow a predictable URL pattern — a department identifier as the subdomain. I had a list of ~196K department identifiers. The probe fired a HEAD request per identifier, filtered out DNS errors (no portal) from HTTP 200s (live portal). Ran at 211 requests per second. Result: 705 confirmed portals, up from 6-9 known. That's a 100x increase in coverage for a single vendor, in under an hour of compute time. The regex scan was still running through state directories — I/O bound, reading 55K small JSON files — so I committed all 4 scripts and let it finish overnight.

Next: run the scan to completion, merge all sources, and see what combined coverage looks like across those 32K records.

What Annual Adds

This is what I built today. Annual subscribers run the same tools.

• Every tool I ship. Edge Copilot installs to your Claude Code — talk to all my knowledge, every method, every data source. Current: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud. Whatever ships next is included.

• All 3 courses: Who to Target and What to Say, Agent 7, AutoClaygent.

• Weekly office hours.

License key hits your email after you upgrade.

→ Start at $50/mo · Go annual — $2,499/yr

April 3, 2026 · Build log

Left Claude Code running and went to the pool. That's the sentence that describes most of April 3.

Before I left, I handed off a clean task: find the updated Blueprint Swarm skill, run the full pipeline, publish the playbooks. No subprocess calls, no Anthropic API — just the Agent tool, the way the swarm is designed to run. The orchestrator picked it up from there.

First thing it did: pull fresh revenue data from the CRM. Prep the full active account base across classification batches. Then run a rule-based pass first to get the playbooks published fast — three playbooks shipped to playbooks.blueprintgtm.com before the AI agents even finished their first wave. That's the lazy phase. Get something out the door while the better work runs in parallel.

The better work: AI agents on the same batches. The comparison was instructive. Rule-based put about a third of the at-risk accounts in the "Engage or Lose" bucket — accounts showing silent disengagement signals. The AI put roughly twice as many there. The rules were miscategorizing those accounts as product issues or payment problems because they pattern-matched on keywords. The AI read the full context and recognized the difference between a keyword and a root cause. The "Engage or Lose" bucket doubled in size. The playbooks got republished with the corrected distribution.

Then the swarm stayed running through the night — hundreds of batches of churned account forensics, five accounts per batch. Peak throughput hit sub-4 minutes per batch. One consistent pattern across the entire run: CRM labels were symptom labels, not root-cause labels. An account tagged "Charges and Fees" turned out to be a bankruptcy. An account tagged "Product" was a sales misrepresentation. An account tagged "Unresponsive" was a ghost that had never activated. The AI flagged the mismatch every time; the rules would have just inherited the bad label.

Next: run the same pass over active accounts and see if the pattern holds.

What Annual Adds

This is what I built today. Annual subscribers run the same tools.

• Every tool I ship. Edge Copilot installs to your Claude Code — talk to all my knowledge, every method, every data source. Current: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud. Whatever ships next is included.

• All 3 courses: Who to Target and What to Say, Agent 7, AutoClaygent.

• Weekly office hours.

License key hits your email after you upgrade.

→ Start at $50/mo · Go annual — $2,499/yr

April 12, 2026 · Build log

Six research agents before I wrote a single line of code. That's how April 12 started. I wanted to build Edge Copilot — the Claude Code extension annual subscribers get — and I didn't want to architect it wrong. So I ran three explore agents first (Claude Code's hook system, the AutoClaygent auth flow, the existing Substack content setup), then three design-and-critique agents (architecture, GTM engineer persona, CRO buyer persona). Both critique agents independently said the same thing: don't make it "always watching." Make it pull-based — subscribers invoke it when they need it. That shaped everything.

The build itself took one session. I adapted AutoClaygent's license key pattern — same OTE- prefix format, same Supabase lookup — and wired it to a Vercel API with seven routes: register, verify, index, content, feedback, usage, and sync. Type-checked clean on the first pass. Deployed to edge-copilot.blueprintgtm.com. Then the right question came up: how do people actually get their key? The Substack subscriber API has no endpoint to check if a specific email is paid. So I built a Stripe webhook instead — same pattern as AutoClaygent, catches the annual subscription event, generates the key, emails it via Resend. Sent a test email to confirm the flow. The whole thing was live and returning a proper 401 before we hit a DNS snag that resolved itself in under ten minutes once the CNAME pointed at Vercel.

While Edge Copilot was being built, a parallel session published the first On the Edge post — "I Built a Swarm to Read Every Call" about the Blueprint Swarm open-source repo. The Substack MCP tool was silently stripping all inline formatting: bold text passed through as literal asterisks, links rendered as raw text. I dug into the source at post_handler.py and found the bug on line 1289 — _extract_text_from_content() was stripping all marks before handing off to the paragraph builder. The fix: bypass that pipeline entirely and use Post.from_markdown() from the underlying python-substack library, which handles inline formatting correctly. Patched it. Cleared the bytecache. The post went live with working bold, links, and code blocks.

Two more skills shipped before midnight. The Headline Optimizer: four Opus research agents (Cannonball GTM historical data, Substack-specific mechanics, timeless copywriting principles, demand research APIs), then a demand scoring script that runs Serper Autocomplete across 26 alphabetical queries plus Exa Reddit and FindSimilar calls — total cost ~$0.04/run. Ten headline frameworks ranked by B2B relevance, the 33-character Gmail truncation rule baked in, the dual-title system documented. Symlinked and wired into the existing /on-the-edge skill so it auto-runs on every draft. The Image Generation sub-skill came next: Gemini for hero and concept images, HTML-to-Playwright-screenshot for programmatic quote cards, stat cards, and diagrams. Built the Fraunces font setup, watermark compositing, five HTML templates, and three uv run --script Python scripts. First watermarks were invisible against dark backgrounds — the purple "OTE" had a 2.1:1 contrast ratio. Fixed it by generating gold monochrome watermarks from the original brush-stroke asset and bumping opacity to 18%.

The last fix of the day was the ugliest to discover: the Stripe webhook for playbooks.blueprintgtm.com had been failing for three weeks. Twenty-two deliveries, twenty-two failures. The signing secret in Vercel didn't match the endpoint's actual secret in the Stripe dashboard. Pulled the right value, updated the env var, redeployed, verified the endpoint returned the correct error on a malformed test POST. Then added a Vercel cron that runs every 6 hours and checks seven components — Supabase connectivity, Stripe API and webhook config, Anthropic credit balance, stuck jobs, failure rate, and webhook delivery — alerting to #pipeline-alerts in Slack if anything breaks. Next: watch whether the webhook actually catches a live subscription before trusting it.

What Annual Adds

This is what I built today. Annual subscribers run the same tools.

• Every tool I ship. Edge Copilot installs to your Claude Code — talk to all my knowledge, every method, every data source. Current: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud. Whatever ships next is included.

• All 3 courses: Who to Target and What to Say, Agent 7, AutoClaygent.

• Weekly office hours.

License key hits your email after you upgrade.

→ Start at $50/mo · Go annual — $2,499/yr