u/Shawntenam

i'm Shawn. i started this sub in march.

for anyone newer here: i was a plumber in New York for ten years. no degree, i dropped out of community college in my second semester. i got my first SDR role in august 2023, went to a startup as the founding BDR a year later, and a year after that i was the first GTM engineer at a RevOps agency. this summer i launched Clearbox with a technical co-founder, after vibecoding the first version myself.

i don't have an engineering background. in february my GitHub was almost empty.

eight months later it's what i'd show a hiring manager before any resume. here's what's on it:

gtm-coding-agent: build your go-to-market engine with coding agents instead of a $2K/mo tool stack. documented chapter by chapter, with forkable starters, installable skills, and Python scripts. 150+ stars, 40+ forks. https://github.com/shawnla90/gtm-coding-agent

recursive-drift: a methodology for building AI agents that develop memory, voice, and personality over time. CLI-first, zero API keys, built for Claude Code. https://github.com/shawnla90/recursive-drift

context-handoff-engine: persistent context for Claude Code across sessions, terminals, and agents. the infrastructure layer behind recursive-drift. https://github.com/shawnla90/context-handoff-engine

website-with-soul: playbook and working starter template for building a website with depth and personality on a mostly free stack. https://github.com/shawnla90/website-with-soul

why i think this beats a resume for GTM engineer and forward deployed roles:

a PDF says what you claim you can do. a repo shows what you shipped, when you shipped it, and how you think. the README shows whether you can explain a system, and the commit history shows whether you finish things. anyone can clone it and check if it runs.

green squares can be gamed. what's harder to fake is a repo someone else can fork and run.

if you're starting from zero like i was, you don't need a big project. take one script you already run for work, like a list builder or an enrichment step. strip the client data, write a README that says what problem it solves, and push it. then do it again next week.

if you've got a public repo, link it below. i want to see what people in here are shipping.

February. Built a website for my dad’s plumbing business.

Had to shut it off for a while because he got too busy taking calls. Flipped it back on.

Last 28 days: 17,500 impressions. 312 clicks. Zero ad spend.

I’m a GTM engineer. People act surprised when I ship a site. Don’t be. If it has an API, we can build it.

If it’s an AI build, we got this. Websites are in the job description whether HR wrote it down or not.

The site lives in a repo. track it. You see which pages and which lines of copy pull impressions and clicks.

Then you take the winners and use them everywhere else: outbound, landing pages, ads.

Organic finds the language. Ads scale it. Same copy, different surface.

That’s the loop. Site → Search Console → messaging → budget.

Coders and engineers already know how to ship and instrument.

Do that on a real business in your free time and you walk into GTM meetings with proof, not opinions.

You can point at the numbers and say put spend here.

I was a plumber for ten years. Now I keep his phone ringing from a Mac mini.

Shawn Tenam. GTM engineer, Clearbox co-founder. SEO god on the weekends. 🏴‍☠️

Without a doubt, most of the opportunities that I've created for myself started with posting and commenting.

no partnership, no one asked me to. I used it, built with it, and shared what I built.

today I'm at the Apollo Next because of that.

if you want to be a top-tier GTM engineer, building isn't enough. share what you build, even the unpolished stuff. the tools you use every day are a good place to start.

yes, I'm Apollo-pilled. got the hat to prove it. I'll share what I learn from the conference.

what tools do you use that you'd happily rep without being asked?

so here is a workflow you can run tonight if you are already in. shipped as v0.11.0 of my gtm coding agent repo, link at the bottom.

what it does: takes a contact csv, hits reverse_linkedin_lookup on each linkedin url (still at the company? plus the graded business email when the graph has one), falls back to reverse_email_lookup, second pass by name + company domain accepting only a same-domain a/b, then writes a google sheet where the grade decides the channel. a/b email. c small segment.

d never emails, goes to a linkedin queue, then phone. moved goes back to sourcing.

Re-ran 200 apollo-verified gtm engineers last night: keyed on the email, 70 profiles and 60 sendable. keyed on the linkedin url, same people, 196 profiles, 136 graded (all a but one), 113 sendable, 54 to linkedin, 27 job changes caught. the not-found rows cost zero records.

the bigger point. if a tool has an api, you build the waterfall yourself and decide which source answers which question.

you do not need a clay seat for that, you need a repo.

everybody has the same tools and the same data. the edge is the founder's energy behind the tool, then trusting the data enough to build on it.

gtm as a repository: every campaign you run feeds back into the system. the model gets better with use. so does your gtm.

to run it: `python3 budget.py` (three free calls), then `bash run.sh list.csv --full`. keys from a local vault, never in the repo.

question for anyone else in the beta: are you keying on the email or the url? my numbers say the url and I want to know if that holds outside my icp.

release: github.com/shawnla90/gtm-coding-agent/releases/tag/v0.11.0

https://preview.redd.it/6f9udu3atmlh1.png?width=946&format=png&auto=webp&s=dc248e795bac5fc71ee4d8226e571febc0787149

three months into clearbox, sharing the whole build: what we run, what it produced, what it cost, and what changes now. engine dashboard screenshot attached so the numbers are not from memory.

the stack, and what each piece does:

- convex: the data layer. opportunities, offers, inbox state, and the api endpoint reads straight from it

- gemma-4-31b-it-nvfp4-turbo, the open-source local model: first-pass triage, is this thread even an opportunity. my co-founder lila quantized it to nvfp4 and put it on hugging face (LilaRest/gemma-4-31B-it-NVFP4-turbo), it is past 1.7 million downloads now, and we run it for clearbox on a rented rtx 5090

- openrouter: the heavier calls, routed to whichever model fits the job instead of one frontier api for everything

- vercel: the app and the site

- cloudflare: dns and the sending domains, spf/dkim/dmarc live there

- posthog: tracking everything from web traffic to UX

what it produced, may 30 to today:

- 162 signups

- pipeline from four channels: referrals, me reaching out to my own crowd, warm follow-ups to people who signed up, and cold sends off warmed inboxes. every channel produced at least one signup

- 120 onboardings, 119 trials completed

what it cost in inference, all providers:

- all-time: $447. last 30 days: $199

- by step: match $226 (is this thread an opportunity), review $169 (the deeper read on what passed), onboarding $53 (building the offer context once per account)

- per completed trial: $2.12. full-plan trial with a card on file $2.82, capped no-card trial $1.62. onboarding an account: $0.44

two things in those numbers that I would want to know as a builder:

the first is why the local model matters. match is the volume step, every new thread in every tracked subreddit hits it, so if that call goes to a paid api the bill scales with reddit's posting rate instead of your customer count. the local model on the 5090 sees everything at zero per token, the paid model only sees what survived. that is the whole reason the paid side stays small.

the second is that a free trial does not hurt you at this cost. two dollars of inference to find out whether an account converts is less than one ad click, and capping no-card trials at two subreddits is what keeps the tail at $1.62.

the gtm loop, so it is reproducible:

1. every signup lands in a sqlite table with what they set up and which opportunities they opened

2. a daily digest classifies each one (book a call / active / unreached / re-tap) and drafts a warm note

3. I send the notes by hand from my own inbox. nothing auto-sends to someone who signed up

4. cold goes through warmed inboxes on a separate sending domain, never the main one

what changes now: less building, more account work. converting the trials that are already getting value, upselling the capped ones, and writing the journey up as it goes.

disclosure: co-founder of clearbox, this is our build. happy to share the match prompt or the digest classifier if useful.

question for the builders here: what does a trial cost you in inference, and where do you draw the line for escalating to a bigger model?

I tried to run linkedin outreach myself instead of handing my account to a sender tool.

so i had, Claude, right up a small playwright script that drives my real session, sends connection requests with a personal note, and keeps a sqlite ledger of every request, accept, and reply.

ran it against 1,297 gtm engineers, 40 a day, weekdays only, three weeks.

numbers first.

the funnel:

• 601 connection requests sent
• 299 accepted (49.8%)
• 35 replies
• 6 booked calls, a couple trials, 4 paid sign ups

31 of those 35 replies came from people i never sent a follow-up message to. they accepted, read the 27-word note on the request, and replied to that. i had a full first-message-then-bump sequence built and it barely ran. the note did the work.

takeaway i'd bet on. if the note on your connection request can't earn a reply by itself, a follow-up sequence is amplifying nothing.

get the note right before you build the machine. mine named what i was building in the first six words, asked for a read instead of a meeting, and went to peers, not buyers.

now the gotchas, because there were real ones.

the ledger is the whole thing, not the script. one row per person, every cap is a sql count against it, so you can kill the process any time and restart safe. the script is replaceable, the ledger is the asset.

keep score with a separate read-only pass. the part that sends should not be the part that decides what worked. i had a second script that only reads the connections page and inbox, never clicks anything, and it found 22 accepts and every reply the sender itself missed.

and the bug that ended it: the sender wrote "sent" to the row only after the message went out.

crash in between and the message is delivered but the row still says pending, so it sends again next run. i watched it double-message someone. fix is to write "sending" before you act and confirm after, so a crash strands a row for review instead of re-sending.

why i stopped: the double send, plus a send rhythm no human produces (bursts then exactly 30-min gaps, exactly 40 a day), plus one verification wall from week one. that's the account asking you to stop, so i did.

to be clear, this is not me telling you to skip heyreach or tools like it. i use them. they exist so you don't have to babysit this and so the risk sits with a vendor instead of your account.

automating your own linkedin is against their terms and can get you restricted. that was my account and my call. it didn't get me banned. it could have. i'm sharing the numbers, the good and the broken, because both are useful.

happy to get into any part of the build in the comments.

Almost every day for the past three months I get some version of.... How do I actually get into this role.

And I always try and help and share my insights, but the best thing I can share with y'all is a free public repo. That actually pushes you to build something useful.

130+ stars, 22 chapters. focused on using coding agents to build real GTM systems instead of just talking about them.

If you’re trying to break in (or level up), here’s the only advice that actually moved the needle for me and a bunch of people who used it:

Take a weekend and just build.

Ignore the “don’t build what already exists” advice when you’re learning.

Rebuild the tool.
Break the API.
Write the ugly script.
Ship the dumb little app only you’ll ever use.

Then sit with why it failed and fix it.

Those are reps.
You get better at systems, debugging, APIs, and actually shipping GTM work instead of just consuming content about it.

The only wasted build is the one you learned nothing from.

That’s the real value. Not another course. Not another “framework.” Just deliberate practice that compounds.

I’m not dropping the link here — you can find it if you want it. If you can’t, DM me and I’ll point you to it. No promo. I just want more people in this space to stop waiting for permission and start building.

If you already know this stuff and usually scroll past posts like this, this one’s not for you.

So I don’t run this on every project. Depends on the size and how messy it is.

When the repo has real history (instruction files, SQLite, previous failed approaches, assets, handoffs, etc.), I stop trying to make one session carry the whole thing.

Claude Code stays in the terminal. It inspects the system, reads the instruction files, checks git and the last handoff, then writes a clean phased plan into a durable file.

Codex gets that file in the app and builds one phase at a time. File boundaries, verification steps, and the “do not touch” list are already there. I especially like it when I need browser control, live previews, or proof of the work.

The handoff is usually just:

GOAL
CURRENT STATE
SOURCE OF TRUTH
DECISIONS ALREADY MADE
PHASES AND FILE OWNERSHIP
VERIFICATION
DO NOT TOUCH

It's also super convenient because the remote control feature on the app works really well. (yes. You can do this with Claude Code also), it's great for keeping sessions running when you have to walk the dog. (in my case)

For smaller or cleaner work I just stay in one agent and feel it out.

Right now I’m mostly on Opus 4.6 (sometimes Fable 5) in Claude Code, and GPT-5.6 Sol at Extra High in Codex once the phase is locked.

I’ve seen other people doing versions of this Claude for context/planning, Codex for execution, file handoffs, cross-review.

so I’m posting because I want to know what the rest of you are actually running day-to-day.

Full split? One agent the whole way? Something else?

Lets see what’s working for people building real GTM systems.

A few weeks ago I had also built my own skill tree for my blog, so getting into MoltSets was fun because I could immediately compare how I was thinking about skills vs. how Adam was thinking about them.

I didn't just want to understand the library. I also wanted to understand the actual loop underneath it.

A product can easily give you data, but you still need people with skills to build those workflows that actually make sense.

Those skills help the next person get value faster, and eventually the users start creating the education and distribution around the product themselves.

I wanted to see if that idea actually held up on something messy inside Clearbox.

When someone signs up for Clearbox, we can join their posthog activity to their convex user and onboarding context.

Company domain? Easy.
Gmail or another free email? Professional identity trail basically disappears.

So I took 68 free-email signups and ran them through MoltSets.
54 returned an identity candidate.

13 resolved directly from the free-email address.

23 came back high or medium confidence after running them through
Clearbox’s own grader.

Everything else stayed in human review or unresolved. Which is actually what I wanted.

I don’t want enrichment that just confidently makes shit up because an agent found somebody with the same name.

The workflow has to earn the right to keep going.
Direct identity edge first. Only fall back to name search if there’s enough evidence.

I also built the data and cost model myself before letting an agent touch the workflow.

Because “free tokens” doesn’t really tell me anything.

Once I separated unlimited core data from the rolling request and record windows, then treated external tokens as their own pool for the expensive fallback work, I could actually understand what I was building around.

Four real usage meters instead of one vague credit number.

And the build gave me two actual skills:

Free-Mail Signup Resolution
Credit Guard & Token Economics

That’s when the MoltSets loop became real for me.
I went in to solve one Clearbox problem.

It produced a working resolver, a cost model, and something another builder could start from.

I’m packaging it into a public Notion guide with the flowchart, real redacted examples, all four usage meters, the guardrails, and both skills.

So keep following for the drop. Still iterating on it. Don't want y'all coming at me for any AI slop, so it's still on human review.

But feel free to DM me for early access! 😜

The mistake first...

I set the workspace up on Buzz (Block's open-source thing, humans and agents in the same channels). Built out the channels, wrote the canvas docs, seeded the first threads, posted the invite. People joined. Then it just sat there. Nobody posted anything except in #general.

I assumed the usual: people join stuff and never come back, that's the internet.

Went digging in the relay this weekend and pulled the membership roster per channel. Every channel I'd built had exactly one member. Me. Turns out when you accept a Buzz community invite, the desktop app auto-joins you to exactly two starter channels and nothing else. Every channel created after that has to be joined individually, and nobody knew they were there because they don't show up in your sidebar until you're in them.

So everyone who joined saw one empty room and reasonably concluded the place was dead. It wasn't dead, it was invisible. Fixed it by pulling the roster and adding everyone to every channel, which is a loop over buzz channels add-member. Wrote it as a script since it has to run for every new person who joins.

If you're running anything on Buzz, go check buzz channels members --channel <uuid> on a channel you made after launch. I'd bet money you have the same problem.

Now the direction change.

I keep getting asked how to become a GTM engineer. My answer is always the same three words: build in public. I still think that's right, but it's getting weaker, because text is now trivially fakeable. Anyone can generate a convincing thread about a pipeline they never built. I read ten of them a day. So can you.

Video is where that breaks down. You either screen-share the thing and explain why you picked the waterfall order you picked, or you can't. There's no prompt for having actually done it.

So I'm starting a show. GTM engineers walk through something they actually built, on screen, with the receipts. Not another interview about the future of AI in sales.

The what we should care about: I'm not just looking for people with audiences. I'm looking for people who built something real and have no idea how to show it. If that's you, that's the whole pitch. You bring the build, I handle recording and editing, and you leave with the episode plus a pack of captioned vertical clips to run on your own channels. No strings, no attribution games.

The workspace is the on-ramp. Post your builds there for a week or two, come on and walk through one. Not a gate, it's the prep. your posts end up being the episode outline.

Rebuilt the whole thing around that this weekend. Cut it from seven channels down to five, because seven channels for a handful of people is a ghost town by design. Rewrote the docs.

Invite's good for 30 days:

https://gtmelite.communities.buzz.xyz/invite/v2.Ob8-wOkY5qvDLRK2uuTra19aSzA5a8oj7hZNPVnXmY4

You need the Buzz desktop app for community features. Click the link, then go post what you're building.

And if you have a build you want on camera, just say so in the thread. First episodes are getting picked from whoever raises their hand.

Got invited on a podcast with my co-founder. The episode is still with their editors and won't hit YouTube for another two weeks. Old me would have waited for the link and then posted "excited to share" the day it dropped.

Instead I asked for the raw files and treated the transcript as the asset.

Whisper transcription with word-level timestamps. Then I had my coding agent read the transcript and find the story peaks. "Here's our take on automation" is a topic. "The AI told me API access takes 24 hours and forgot to mention the $10,000" is a story with a peak, and because the timestamps are word-level, the cuts land on words, not near them.

That got me 17 vertical clips with captions and hooks. Hosted them at public URLs, then used the Buffer API to stage drafts across TikTok, IG Reels, and YouTube Shorts. 33 drafts from one script. They stay drafts until I eyeball them, then it's one clip a day until the episode drops.

The daily LinkedIn layer runs off a Notion board my phone can operate. It tracks date, post text, video download, and status. Four minutes a morning with coffee.

Then the long-form pass over the same transcript produced a newsletter, a blog post, and this post. Every piece is a different altitude on the same hour of tape.

The podcast itself came from this exact motion. The host's team found my product through the content I was already posting. Nobody pitched anybody. The content did the outreach, then the recording became more content, which is presumably how the next one happens too.

One hour of recording became 17 clips, 11 daily posts, and 4 long-form pieces. About a month of cadence, and the episode itself is still in the queue as the finale.

Next time I would capture B-roll during the recording session. Screen captures of the actual tools we talked about would have doubled what the clips can show.

Anyone else mining recordings this way? Curious what your transcript-to-asset ratio looks like, because I think ours is still conservative.

ps. For all my builders out there who are trying to figure out a way to build in public, take these record yourself working, take podcasts, webinars, or whatever you can do to showcase your natural talents. That will set you apart from the rest and make sure you never have to drop a CV.

That's one of the main goals I want from any of you, any of y'all in this community: to really learn how to build in public to the point where you're so in demand that you never have to drop another CV.

If you're trying to figure out how to do these recordings and edits programmatically, you know where the scripts are. If you're new here, just DM me and I'll send them to you.

That's me signing out, Shawn Tenam, go-to-market engineer and co-founder of clearbox.

P.S. Special shout-out to the LeanScale team. Beyond putting together an incredible podcast and media experience, their founders genuinely care, and their team has some seriously sharp RevOps and go-to-market engineers. They understand GTM at a level most agencies simply do not. If you need a partner for RevOps or allbound growth who will actually care about the outcome, I could not recommend them enough.

Being a go-to-market engineer today isn’t just about knowing Clay, Claude, or your favorite workflow.

It’s about staying ahead of the curve and figuring out which new tools are actually worth your time before they become mainstream.

Every week there’s another “game-changing” AI product.

Instead of arguing about them on Reddit or waiting for YouTube reviews, why don’t we test them ourselves?

I’ve been experimenting with Buzz, Jack Dorsey’s new open-source workspace for humans and AI agents.

It feels like a mix of GitHub and Slack, but built around collaboration instead of just chat.

I’m thinking we create a shared cloud workspace where nobody owns it. We use it to evaluate new tools, share workflows, build together, and answer one simple question:

Is this worth adding to the GTM engineering toolkit, or does it belong on the Fraud Alert list?

The only prerequisite I’d ask is:

• You have a GitHub repo (or you’re actively building one).

• You’re interested in GTM engineering, AI workflows, automation, or building systems.

I genuinely don’t care if your repo has 0 stars or 10,000.

This isn’t about clout. It’s about builders learning from builders.

If that sounds like something you’d want to help shape from day one, let me know.

I’d love to get a small group together and see what we can build.

Been posting my coding-agent GTM workflows here for a while. The question every time is which data vendor I use. After four months of wiring different ones into pipelines: I start every run at Apollo, and the reason is the API plus a coding agent writing to a database I own.

This replaced a stack of tools I used to pay for.

I take a list of target companies - a screenshot from a market map, a conference exhibitor page, my own LinkedIn following - and hand it to Claude Code. It resolves domains, runs organizations/enrich?domain= for the org ID and firmographics, then mixed_people/api_search filtered by organization_ids for the people. That search is free. The redacted preview gives me title and person ID with the name obfuscated, so I qualify the whole set before spending a credit, then pull only the rows I want.

Every enriched row writes to a local SQLite database. SQLite is my own contact store, the CRM before the CRM. It holds every company, every contact, every enriched field, on my own machine. Apollo's API is what lets me build it, and I can push it to the cloud or a real CRM whenever I want. The expensive part of sourcing was never the data, it was the manual work of getting the right rows into something I own.

Numbers and mechanics.

• The search is free. Credits only go on the rows you pull.
• On flagged inventory, bulk_match returns verified work emails at around 99% for me, instant.
• Long runs go to a Codex session on a remote instead of my laptop. Start a few-thousand-row job, come back to a filled database.

On vendors, honestly. No source is perfect. But Apollo is the first layer. It is the whole data layer - the roster, the org record, the current-company signal, and the reveal in one place. Apollo is where you start. A lot of the tools people pay more for are reselling Apollo's data underneath anyway.

Two gotchas from building this.

organization_ids is the only reliable filter in mixed_people/api_search. A domain or company-name filter returns people unconnected to your targets. Enrich the company first, always.

bulk_match draws from the data/export credit pool and caps at ten per batch. Check your balance before a multi-segment run or it stalls mid-job.

Happy to share the Python for the screenshot-to-SQLite loop.

Building in the open at.....you know where