Campaigns end. Infrastructure compounds. These are the things I built that kept generating pipeline, trust, and clean data on their own: a public lead magnet, an attribution portal leadership actually believed, the data scaffolding underneath everything, and the Claude Code operating system that runs it all.
What it is: a public "get your free scorecard" product. A prospect enters their domain, and the engine scans their website to figure out their positioning, uses custom fine-tuned prompts to generate the industry queries they should be winning in AI search, pulls authority and keyword data from Moz and SEMrush, and scores their AI search readiness across roughly 30 data points. It produces two things at once: a customized public scorecard with a tailor-made plan for the prospect, and an internal view with even more depth for the sales rep who picks up the conversation.
What it did: it generated $700K in pipeline in just a few weeks after launch. Prospects got a genuinely useful, personalized analysis instead of a gated PDF, and reps walked into calls already knowing where the company stood and what to pitch. The CEO handed me the engine half-finished; I tuned every prompt, defined what counts as client-ready, and wired the outputs into both frontends.
flowchart TD DOM[Company domain goes in] --> SCAN[Scan the website:
positioning, offer, industry] SCAN --> Q[Fine-tuned prompts generate
the queries they should
be winning in AI search] SCAN --> APIS[Pull authority + keyword data:
Moz, SEMrush,
live search results] Q --> SCORE[AI search readiness score
across ~30 data points] APIS --> SCORE SCORE --> PLAN[Tailor-made plan,
written per company] PLAN --> PUB[Customized public scorecard
the lead magnet] PLAN --> INT[Internal rep view:
same company, more depth] style PUB stroke:#8b5cf6 style INT stroke:#8b5cf6 style SCORE stroke:#10b981,stroke-width:2px
The engineering that let thousands of signups hit an expensive engine without crashing or double-billing it: the scorecard connector.
The MVP: I started with a portal that pulled the outbound tools and CRM into one place, matched campaign recipients to deal contacts by email address, and required a human to approve or deny each match before it counted. It gave us a fast, auditable answer to whether outbound influenced a deal while approved historical numbers stayed fixed.
The company model: when the whole company moved from last touch to linear multi-touch attribution, outbound activity had to become structured HubSpot history. OutboundSync recorded EmailBison email events and Lemlist email and LinkedIn sequence touches on the contact timeline so GTM engineering work could participate in the same attribution model as every other channel.
flowchart TD
subgraph SRC["Every outbound tool + the CRM"]
direction LR
AP[Apollo]
EB[EmailBison]
LL[Lemlist]
HS[CRM deals]
end
SRC --> N[Match campaigns to deals
by email address]
N --> EDGE[Possible matches:
campaign touched this deal?]
EDGE --> Q{Human review queue}
Q -->|Approve| ROLL[Counted in
the dashboards]
Q -->|Deny| X[Excluded]
ROLL --> AI[AI writes the story of
where each deal came from]
style Q stroke:#10b981,stroke-width:2px
The full evolution from the human-reviewed dashboard to company-wide linear multi-touch: how we made outbound visible in HubSpot.
What it is: conventions built into every workflow so the database compounds instead of decaying. Email verification results get written back to the CRM as standardized statuses. Every enrichment result is stamped with when it was fetched and from where, so no lookup is ever paid for twice. Competing legacy fields got consolidated to one source of truth. Every bulk write snapshots the current values to a rollback file first.
What it did: across tens of thousands of accounts and hundreds of thousands of contacts, data quality improved as a side effect of normal work. New campaigns started smarter than the last one, and nobody ever had to run a "data cleanup quarter."
flowchart TD RUN[Run a campaign] --> LEARN[Campaign produces data:
verified emails, bounces,
enriched profiles, replies] LEARN --> WRITE[Write it back:
validation status, timestamps,
enrichment source + date] WRITE --> CRM[(CRM + sales database
a little cleaner than before)] CRM --> NEXT[Next campaign starts smarter:
skips verified, excludes bounced,
uses cached profiles] NEXT --> RUN style CRM stroke:#10b981,stroke-width:2px
What it is: my Claude Code environment, built up over thousands of hours into something closer to an operating system than a chat window. It is the working layer across coding, CRM operations, research, writing, project management, personal admin, and the production systems on this site. A small referential index routes each task to the right business context, tool notes, procedures, and atomic memory files instead of loading everything at once. When something fails, the relevant reference gets corrected so the same mistake does not happen twice.
What it did: it's the reason one person could build and operate everything on this site. It also travels: the company-specific parts swap out, and the whole system can be installed at a new org in days.
flowchart TD
T[Task arrives] --> Q{Is there a checklist for this?}
Q -->|building an email list| P1[Run the safety checklist first]
Q -->|new tool| P2[Test it live before trusting the docs]
Q -->|no| L{What kind of task?}
L -->|CRM work| HS[Load the CRM knowledge]
L -->|outreach| OR[Load who we sell to + what works]
L -->|specific tool| AD[Read the tool notes first]
L -->|unclear| ASK[Ask before guessing]
AD --> RUN[Use a proven tool or build new]
RUN --> FAIL{Did it fail?}
FAIL -->|yes| HEAL[Fix it AND correct the notes]
FAIL -->|no| MEM[Save any lesson learned]
The actual architecture behind the rules, routed context, tool docs, commands, and referential memory: the Claude Code operating system.