GTM engineer · signal detection and lead routing

I build the systems and workflows that help your company find revenue.

A company posts a role, loses a leader, or describes the problem in a comment. A list tells you who could buy. A signal tells you who has a reason now.

The systems I build catch those signals and check them against your ICP, so your rep opens the account with the source, the date and the exact quote already attached.

Open to a second opinion on where your pipeline stalls?

Pick a time

Ten systems I built for other teams. Open one to see what it would do for yours.

01Signal radarfind companies ready to buyInternal · Partner In Publishing · 2026Shipped
Enrichment & Intelligence · AI Engineering
Claude CodeTrigify MCPApolloSkill design
The challenge

Prospects announce their problems in public every day, and almost nobody reads it at scale. Doing that well takes two things: searches built to the engine’s real limits, and a system that will not assert what it cannot source. The radar is built around both.

What I built
  • An AI engine that scans social platforms for intent signals and screens prospects against ICP
  • Mapped the search engine’s undocumented ceilings by testing them. Six keywords per LinkedIn search across OR, AND and NOT combined, silently trimmed past that. So every search is designed at exactly six
  • A learning log with a promotion gate. Observations enter as hypotheses. Only repeated evidence or an explicit decision graduates into a skill file, and a human approves the promotion. Superseded entries stay in place for provenance instead of getting deleted
Alternative considered

One Claude Code build for everyone. Adoption is a real constraint, so there are two builds: Claude Code for the people who will learn it, Claude Cowork for the people who will not.

Result

Five scans run off one folder. Social radar pulls what the market is arguing about this week against a person’s pillars and voice. Prospecting and pain scans surface companies signaling a problem today, directly or in passing. Account deep dive builds a pre-call dossier on the person and the company so nobody dials in cold. Event scan takes an exhibitor list and matches it against the ICP and the segmentation framework. Every run drops a tagged JSON file, which becomes a spreadsheet, waterfalls through Apollo to a verified sendable address, and lands in an Instantly campaign.

Constraints named up front

Scheduled scans carry a cleanup step and a named credit ceiling, so the cost of a run is bounded before it starts.

02Open-role detection engineintent-only outreachOwn initiative · Partner In Publishing · 2026Shipped
Enrichment & Intelligence · No-code
ApolloClaySignal detectionClassification design
The challenge

Cold outreach to a static list goes to people with no dated reason to reply. Meanwhile a company hiring a VP of Marketing is announcing a gap in public, dated, with the pain still fresh, and nobody is reading it.

What I built
  • A collection spec. Five personas, three title buckets: the decision maker, the adjacent function, and the champion one level down
  • Individual contributor roles get captured but flagged as not-a-contact. Four analyst openings show where a company is putting its money, and none of them is a person to email
  • A sixty-day recency filter, because a stale posting is a false positive dressed as a signal, plus an exclusion list so editorial, HR, finance, legal and engineering roles never reach the output
  • Accounts on the do-not-contact list stay in the scan tagged signal-only, because leadership still wants to see them hiring even when nobody is allowed to touch them
Alternative considered

A scraper that collects every posting. I wrote a collection spec instead, so the personas, title buckets and exclusions are decided before anything is collected.

Result

Outbound aimed only at accounts with a live, dated, verifiable reason to buy.

Constraints named up front

The spec labels which columns are source data and which are judgment. Title, URL, date and location are scraped. Bucket and persona are analysis. Anyone building a forecast on it knows which is which. Searches are built on how leaders actually describe a gap rather than on the literal phrase.

03Lead routing + AI enrichmentrouted in 5 minutesClient delivery · Reference-database publisher · 2026Measured
RevOps · Enrichment & Intelligence
ZapierMailchimpGravity FormsGPT-4o-miniGoogle Sheets
The challenge

The client is a reference-database publisher serving academic libraries. A prospect filled out the form and nothing happened. Hundreds of submissions had accumulated with no owner, no acknowledgment and no routing. Traffic was fine. The handoff was broken.

What I built
  • A 260-row market-by-territory routing table. Moving a territory is a spreadsheet edit, and it does not need me
  • Domain enrichment on the inbound email at under five cents a month, so the rep opens the notification already knowing what institution they are talking to
  • A deliberately plain acknowledgment email. No promotion, no cross-sell, nothing. International prospects mean GDPR, and the cheapest way to comply is to have nothing to argue about
  • A setup guide written so a marketing team can maintain the whole thing with Ctrl+F and no developer
Alternative considered

Branching logic. It would have worked, and then died the first time a rep left or a territory moved.

Result

Live and routing within five minutes of submission. Each rep receives the leads for their own markets, with the enrichment already attached.

Constraints named up front

When the enrichment cannot identify an institution, the notification says so rather than guessing. It works from a model’s training data rather than a live database, and the handoff doc states that. It reads company domains, so a personal address returns a stated unknown. Notification throughput has a named ceiling, ten per hour on the current plan, written into the handoff doc so the team knows the limit before a campaign runs.

04Account segmentation frameworkchecked against closed-won dataInternal · Partner In Publishing · 2026Measured
Analytics · Enrichment & Intelligence
HubSpotApolloDeal attributionProvenance tagging
What it is

A segmentation framework for an EdTech services market. It sorts the addressable market into buckets by who the account is and how it buys, and it carries deal tier separately, on the deal rather than on the bucket. Bucket answers which motion to run. Tier answers what the deal is worth. The two move independently, and the framework is built to treat them that way.

What it does
  • Sorts the market into buckets by segment and buying motion. Each bucket carries its own motion, its own target, and its own evidence base rather than inheriting one from the tier above it
  • Prices tier at the deal
  • Tags every claim with where it came from: HubSpot, Apollo, the framework itself, or inference. There are no unmarked assertions anywhere in the document
  • Logs the 146 domains Apollo failed to return, so a coverage gap can never be read as an empty market
  • States a target only where the deals exist to support one. Where they do not, the bucket carries a validate-the-motion note instead of a number
Alternative considered

Putting tier on the bucket. Tier 1 economics appear in every bucket, so a bucket-level tier hides more than it explains.

How it was validated

Checked against the CRM. Sixteen months of closed-won data, with roughly four in five of the companies pulled from HubSpot classified as in-ICP. The median deal in the largest bucket was about a tenth of what the market describes as typical for that segment. The deal values themselves stay private. Every target in the framework traces back to a deal that actually closed, and every bucket that cannot do that says so on the page.

Constraints named up front

A target appears only where closed-won deals support one. Where the data is thin, the bucket carries a validate-the-motion note, so no number in the framework is doing more work than its evidence can hold.

05Company-wide AI enablementobserved behaviorInternal · Partner In Publishing · 2026Observed
Enablement · AI Engineering
Claude EnterpriseTraining designKnowledge systems
The challenge

A few people were using ChatGPT for what amounted to autocomplete. The tooling was licensed. Nobody operated on it. That is where most AI spend stalls: the company owns the technology and does not change how it works.

What I built
  • Built the dashboards, then used them in live client calls until people asked how
  • An answer engine over the internal documentation, six field manuals deep, so the knowledge base could be asked a question instead of searched
  • Individual workspaces per leader, training on projects and prompting, and a bootcamp
Alternative considered

Opening with training. I showed people the work first, and the training came once they asked how.

Result

The team moved onto Claude and works in projects now. Copywriting, research, client prep.

Constraints named up front

Outcome described from observed behavior rather than instrumented measurement.

06ABM platform, built from zero0 → live outboundInternal · Partner In Publishing · 2026Shipped
Outbound · RevOps · Lifecycle Marketing
ClayInstantlyHubSpotLemlistDeliverabilityICP design
The challenge

Almost all new business came from referrals. There was no outbound infrastructure of any kind and no repeatable way to reach a target account. Building the engine was the reason I was hired.

What I built
  • Five numbered workstreams under a coded naming convention: segmentation, engagement model, data integration, workflow design, and a ninety-day roadmap. Twenty-one documents that reference each other
  • Nine engagement playbooks covering cold email, inbound, LinkedIn, paid media, and warm go-to-network, plus a tactics summary and a platform limits reference
  • An asset dependency index carrying an owner, a timeline, a monthly volume, and a named capacity constraint on every single asset, before any of them were built
  • Cold email infrastructure, ICP matrix, lead scoring, lifecycle stages, and routing rules underneath all of it
Alternative considered

Sending at the aggressive limits from the start. The limits reference labels that column Risky.

Result

A referral-dependent agency had a documented outbound operating system with a training layer where before it had nothing.

Constraints named up front

Every asset ships with a named ceiling. Warmup cannot be rushed, forty to fifty emails per inbox per day while it runs. No links in the first email, ever, because links kill deliverability. The limits reference labels its aggressive column Risky, so nobody picks it by accident. The constraint I named most often across the whole index is copywriting capacity. The bottleneck on an automation platform is the people who write.

07Nurture and lifecycle architectureentry, exit and suppression rulesPrior role · Fullbay · 2022 to 2025Shipped
Lifecycle Marketing · RevOps
Marketo EngageLead scoringLifecycle designCRM sync
The challenge

Campaigns ran across seven departments, and each one had to reach the right contact without colliding with the others. That is a rules problem before it is a copy problem: who enters a program, who is held back, and who leaves when sales picks the conversation up.

What I built
  • Nurture and lifecycle architecture built with sales, onboarding and RevOps: entry criteria, exit criteria, suppression rules, and lead scoring inside the marketing platform
  • A sales-to-marketing cooldown program: who enters, what they receive, and what makes them leave. Ownership rules from AEs and BDRs translated into platform logic
  • Segment-specific onboarding email assets, with the CRM field and sync dependencies mapped before build
  • Twenty to thirty campaigns a month across seven departments
Alternative considered

A single nurture for everyone. Entry and exit rules per segment cost more to build, and they stop the wrong people receiving the wrong sequence.

Result

Lifecycle machinery a team can operate. Every program states what fires it, what holds someone back, and where a contact goes when sales takes over.

Constraints named up front

Campaign reporting is bounded by what the platform’s native attribution can see. The reporting requirements are documented rather than worked around.

08Client intelligence dashboard generatorfive-minute readClient delivery · Reference-database publisher · 2026Shipped
Internal Tools · AI Engineering
ClaudeJSXPrompt architectureTranscript analysis
The challenge

Project context lived in call recordings nobody rewatched. People walked into client calls having forgotten what was agreed three weeks earlier, and the only alternative was reading two hours of transcript, which meant it never happened.

What I built
  • A three-stage generator: analysis, orchestration, render. Any transcript in, an eight-tab intelligence dashboard out
  • The analysis stage treats the transcript as the only authority. No outside knowledge, no industry generalizations, nothing not grounded in the recording itself
  • The render stage transfers that analysis verbatim. It is forbidden from summarizing, abbreviating, or paraphrasing, because a second pass over an analysis is exactly where detail goes missing and nobody notices
  • Shipped with a Read First guide, locked templates, a style reference so instances do not drift apart, and stated prerequisites down to which model to run it on
Alternative considered

A one-off dashboard for this project. I built a generator instead, so any transcript produces the same eight tabs.

Result

Eight tabs: summary, insights, workstreams, flags and risks, a relationship map with working styles, call intelligence, the full analysis, and action items by owner. Built to be read in five minutes before you dial in.

Constraints named up front

It needs a real transcript and a specific model. Both are stated in the Read First guide as prerequisites. The render stage is forbidden from summarizing or paraphrasing, so detail cannot go missing between stages.

09Executive content enginesource line on every postClient + internal · Online university, Partner In Publishing · 2026Shipped
Internal Tools · Enrichment & Intelligence
Claude CodeTrigifyVoice analysisPrompt architecture
The challenge

Executive LinkedIn content only works when it is timely and unmistakably in the person’s own voice. Producing that by hand takes the better part of an hour per post, so it quietly stops happening. The team had been trained on a vendor’s methodology for doing it at scale. What it needed was someone to industrialize that method into a system people would actually run.

What I built
  • Automated the hardest step: consolidated everything from the vendor training into two simple prompts that drive the content creation process for executive LinkedIn posts
  • Created the weekly calendar and post refinement prompts around internal content guidelines. An external signal can supply a topic. It can never supply the person’s experience, tactics, numbers, or clients. Every post carries two lines: what it was developed from, and what it is grounded in
  • Moved data validation from the middle of the refinement sequence to a gate at the front, then added a re-check at the end
  • Wired it to the signal scanning system I built so the pipeline could run on live external signal instead of only on transcripts, then wrote the training framework and operator quickstart so a new cohort could run all of it without me
Alternative considered

Keeping data validation in the middle of the refinement sequence, where it started. A check there passes, and then hook iteration and compression drift the claim away from its source while nobody is looking.

Result

The engine finds the angle from what the market is actually arguing about this week, runs the deep research sitting behind it, and consolidates the premise into the executive’s own voice. What reaches their screen is a draft carrying a point of view they already hold, on a subject that is live right now. They read it, confirm the premise sounds like them, and ship. That gap between timely and generic is the whole difference between thought leadership and a post.

Constraints named up front

The method is not mine. A vendor designed it and I industrialized it. Voice analysis requires an existing post archive, and the system states that requirement up front. If the source material supports two posts rather than four, the calendar delivers two and says why, rather than filling the gap.

10AI speed-to-lead architecturedesigned, costed, never shippedPrior role · Fullbay · 2022 to 2025Designed, not shipped
Enrichment & Intelligence · RevOps (designed, never shipped)
R2B2SalesforceClayExa
The challenge

About three in four website visitors were anonymous. Response ran twenty-four to forty-eight hours while a rep spent thirty minutes on manual research per lead. In heavy-duty truck repair, where one opportunity clears ten thousand dollars, the first responder wins and everyone else is doing unpaid research.

What I designed
  • A four-tool architecture: person-level visitor identification, CRM status check, multi-source enrichment, and live web intelligence on the visitor’s own company. Anonymous to personalized outreach in three to five minutes
  • Costed at roughly $300 a month, itemized per tool, because an architecture without a price is a wish
  • Compliance designed in from the start. US-only scope to avoid GDPR by construction, CCPA handling, platform rate limits respected, automatic suppression for existing customers and open opportunities, and an audit trail
  • A two-week pilot plan with a stated risk-mitigation approach
Alternative considered

Rolling it out to every team at once. The plan starts with one team and expands after it validates.

Result

Projected 2.5x visitor identification, 90% faster response, and a 15 to 25% conversion lift against a sub-five-minute SLA. It was conceptualized, not shipped, so those are projections rather than measured results. They are the numbers I put in front of executives to ask for the build.

Constraints named up front

The architecture is scoped to identifiable traffic and to the US market by design, which avoids GDPR by construction and sets the market it covers.