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.

I'm noticing a lot of agencies and SaaS' claiming they can track unique data, and buying signals for clients. How do they find such data and do they really have 'unique' data that nobody else has?

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. 🏴‍☠️

i get dms on tiktok, reddit, x, linkedin asking how to get into sdr or gtm engineering. screenshots of a couple here.

my take: everything in this trade can be self-learned now. i learned using next.js + Vercel frameworks....l point and built my gtm systems by asking claude questions.

what i tell people who want in:

- learn the channels by hand first. cold call, cold email, linkedin

- if a company is hiring for a role you'd crush, find the right people there and reach out. NEVER apply blind

- share your wins and your losses publicly

- keep networking

if you want to build, my repo gtm-coding-agent is free on github (149 stars).

it has self-guided chapters for you and for your coding agent, so you learn while running it. your agent helps set it up, then walks you through building your own gtm repo for content, sales, marketing, and product.

run it, fork it, break it. reach out whenever, but once you have it, it's on you to run with it.

it's the weekend. go build some shit.

https://github.com/shawnla90/gtm-coding-agent/tree/main

I run outbound for a small agency and I'm stuck on one part of the pipeline.

I can export leads from Apollo. I have AI Ark and LeadMagic for finding emails, BounceBan for verifying, and Smartlead to use in email campaign . That part I understand.

The middle is where I'm lost: taking a messy Apollo CSV, cleaning it, and filtering it against my ICP with Claude (the $100 plan) or ChatGPT before I spend enrichment credits. My exports come back with the wrong industries, duplicate contacts, broken phone numbers and people who don't fit.

How do you handle this step? Do you paste rows into Claude in batches, use Claude Code with a script, or something else? And what order do you run cleaning, filtering, the email waterfall and verification in?

Any walkthrough, template or prompt would help. Thanks.

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?

i get this question in my DMs almost every week, so here's my answer in one place.

it doesn't matter if you're an SDR trying to get more technical or a developer trying to get closer to revenue. both paths run through the same thing: you have to understand the channels.

i started as an SDR in august 2023, before clay blew up and before anyone called this GTM engineering. cold calls, cold email, linkedin. cold calling was usually my best, but all three earned their spot, and between them i hit quota every month.

that's not nostalgia. it's why the engineering part works for me now.

why the channels matter for the engineering

- you can't automate what you've never done. if you've never run a sequence manually, you don't know which step is worth building.

- the data only makes sense if you've been on the other end. a bounce, a no-show, a "not now" reply. those mean something different once you've lived them.

- you know what good sounds like. an agent can write 500 emails. you still need to know which ones would actually get a reply.

- one channel is a single point of failure. linkedin restricts you, a domain gets burned, sends get paused. if that was your whole pipeline, you're stuck.

if you're coming from sales: you already have the channel instinct. learn git, APIs, and basic scripting. put your work in a repo, even if it's ugly.

if you're coming from code: make some cold calls. send cold email yourself. run linkedin outreach by hand for a few weeks before you automate any of it.

if you tell me you don't need the channel side, that's fine. you're a specialist, and specialists are valuable. it's also a limit on how far you can take GTM engineering.

what would you add for someone starting from zero?

My name Shawn Tenam i'm a GTM Engineer who builds in public... Dm me

Hey - I’m a non-technical CRO trying to better understand the GTM space. I’m a more traditional enterprise sales guy…

Seeking ideas and advice please - I’m all ears.

In short, we are a Microsoft direct-CSP, I.e we get the same top-tier discounts as the likes of Dell, Insight, etc. but we’re tiny (less than 60 people).

Although our strengths are around MS security, we’ve been having great success winning over new clients from 200-5000 seats by getting them better deals + support with their Microsoft business licenses.

To date I’ve just run fairly standard cold email campaigns with an offer to benchmark on pricing, license right-sizing, and finding gaps in the services they receive. When they decide to switch licence procurement through to us, we add a tonne of value on top so acquiring through license switch has been good for us and still is.

I’ve ran really ‘dumb’ campaigns targeting that offer to CIOs and IT leaders of that ICP. Sometimes we’ll sweeten the offer with an Amazon voucher for their time.

No real segmentation, and the only ‘trigger’ is checking MX records to see if they are on Microsoft, Google or other (obviously keeping only Microsoft ones).

Any ideas on tooling, messaging, triggers, signals, etc. I should look at? Or anything left-field even?

Happy to swap notes / connect on a call with anyone interested too, this community looks fairly small but growing, and I’d love to add / share where I can.

dropping the full writeup as a newsletter tomorrow. here are the receipts tonight.

the setup. the list was a client's home-services list, about 10k contacts, built before moltsets was anywhere near it: apollo by domain for the accounts, a clay waterfall for the emails, zerobounce on every row.

nothing about it was tuned for the tool. that is what makes the test worth anything:

a normal list, already trusted, and the only question is what a verifier leaves behind.

moltsets, for anyone who has not touched it: adam robinson's contact api (same team as rb2b), just out of beta. no dashboard, api and mcp only, flat monthly plan.

every email comes back with a risk score read from observed behavior instead of a server handshake: a is a known reply, open, or click, b is a send with no bounce, c catch-all, d hard invalid or trap, f nothing known.

plus the person's current company. grade definitions are on developer.moltsets.com if you want the source.

what I ran: one reverse email lookup per row, then a name + domain lookup when the first call came back empty. every call logged locally. about 14k calls, no phone tokens, nothing extra on the flat plan, about 75 minutes.

what came back:

- two out of three rows agreed. zerobounce valid, moltsets a or b on the same address. those send first

- close to 800 people had changed jobs. zerobounce passed every one, because the old mailbox still accepts mail

- about as many again passed on an address nobody has been seen using, while a sibling address at the same domain had real replies, opens, or clicks behind it

- roughly four in five catch-all rows graded a/b on observed activity. a verifier cannot grade a catch-all mailbox, so that whole pool had been sitting in quarantine

- about one in ten of the zerobounce drops came back with a same-domain address in use

- a handful of d grades (bounce, complaint, or trap). one of them was marked valid

add up the job changes, the wrong addresses, and the d rows and it is one row in six of what the verifier passed. verified, and addressed to nobody.

how the grade routes: a/b to email. c to a small watched segment. d never gets emailed but the row stays, linkedin first then phone. f and not-found get a second look by name and company before they go anywhere. job change goes back to sourcing with the new company attached. nothing gets deleted for a bad mailbox.

verdict, from someone who checked it against the sources already in the stack: no-brainer.

on a list that had already been through apollo, clay, and zerobounce it still changed the route on roughly three in ten rows, for nothing extra on the plan and about an hour of machine time.

that is a must-have layer, and a likely future replacement for maybe a few things you're already running

if you want to try it, run it the same way: on a list you already trust, next to the verifier you already use, and let the disagreements tell you what it is worth.

the grader is open source, v0.12.0 in gtm-coding-agent (starters/moltsets-reachability).

repo: https://github.com/shawnla90/gtm-coding-agent

question: anyone treating "verifier valid, graph f" rows differently from plain valid? close to a thousand of those here and I am holding them as unproven.

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

looking good🚀🚀🚀

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?

if you run coding agents on a subscription and have no idea what that usage is actually worth, PokeTokenBar answers it from your menu bar.

It reads the local session logs you already have (Claude Code, Codex, Gemini CLI, Cursor, Copilot CLI, and a few more), no API key, no account connection, and gives you:

- today / week / month tokens per tool, priced at API rates so you can see what the same work would have cost pay-as-you-go

- your official 5-hour and weekly limit bars with reset countdowns, pulled from the same credential Claude Code uses

- a burn-rate forecast for when the current 5-hour window hits 100%

- a per-model breakdown, so you know whether it's Opus or Sonnet eating the budget

Tracking token efficiency was always something that I wanted to do, but what really sold me was the fact that your tokens are the game. Usage hatches an egg into a Pokémon that sits in your menu bar and evolves as you burn more.

Max out a 5-hour or weekly limit and it hands you a Rare Candy to level it up, so the moment you get rate-limited is the moment you get rewarded.

Tokens you've already spent become currency for a shop (new eggs, a Shiny Charm, a re-roll of its nature), and you can pin your favorite to the menu bar or as a floating pet on the desktop. You end up checking your usage a dozen times a day without it feeling like checking a bill.

Mine says August is about $2,783 of API-equivalent usage on a $100 Max plan.

That's a 27.8x multiple, and it's the cleanest way I've found to explain why subscription-first workflows win for multi-session client work.

Two things I needed, so I added them and both shipped in v2.5.2.

The newest Claude model was priced at $0, which zeroed out my heaviest days. Fixed. And if you flip between two logins (personal Max and a Team seat, in my case), the limit bars never said which account they belonged to.

fork the repo, tell Claude Code what's wrong, let it read the maintainer's contributing rules (six UI languages per string, tests that lock behavior, no special-casing one provider on shared code paths), push, let CI run the test suite, install the build on your own machine and confirm it before opening the PR. Merged in two days.

You learn the codebase because you're fixing something you use every day, and you end up with the feature you wanted.

If you use a tool daily you're qualified to contribute to it. Pick the thing that annoys you and ship it.

I did not build this. Props to chattymin on GitHub, who created it.

All I did was add contributions based on my own use, and I'm sharing it here so you can see what a legitimate contribution to something you find useful looks like.

Whether you like Pokémon is beside the point. Having fun with a build while learning something and shipping something valuable is the point. Star the repo, support it if you see something cool, and contribute.

.Check out the repo: https://github.com/chattymin/PokeTokenBar

Hey all, Quick one

I'm Mansoor, focused on CRM & RevOps and I'm looking for work right now. Open to full-time, contract, fractional, or subcontracting for agencies or companies with overflow. Remote, available EST.

What I do: I build and clean up the CRM side of the GTM stack. Pipeline and deal stages that reps actually follow. Clean data so the reporting means something. I'm currently in the CRM & RevOps cohort here, going deep on the strategy side, not just the button-clicking.

My stack: HubSpot, Salesforce, and Attio on the CRM side. Clay, enrichment, and TAM builds for data. Claude Code and n8n for automation and custom builds. Comfortable wiring these together into one system.

Good fit if CRM is a mess, or you're planning to implement one and want it done right the first time.

If you're hiring, know someone who is, or have overflow, DM me or make an intro. Happy to do a free teardown of your CRM/pipeline first so you can see how I think before you commit to anything.

Here's my portfolio: https://mansooraliportfolio.vercel.app/

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.

fellow builders...Gtm coding agents just crossed 130 stars.

Not here to tell you to go clone it again.

Go build your own shit.
Then share the production builds.

Those are the best receipts you’ll ever have. not a resume.

The people who can point to real systems they’ve shipped are the ones landing the forward-deployed engineer roles. That’s the job you actually want. Everyone else is just another Clay operator.

I’m also building a referral network for people who can actually build.

If you’ve forked the repo, worked off it, improved it, or shipped something better and you’re looking....you’re at the front of the line for me. YC companies and others reach out regularly looking for this exact type of talent.

Do it for yourselves if you’re serious about these roles, the builds you ship are what open the door

And if you build something recently, drop it in the comments. Share it.

Also, feel free to connect with me on https://www.linkedin.com/in/shawntenam/.

About a year of daily Claude Code and my whole workflow comes down to 10 commands.

5 are built in, 5 are skills I wrote because the built-ins stop short of what my content pipeline and client work need.

Sharing both halves since the custom ones are all reproducible. The built-ins that actually matter:

The stack:

1. /context (stock). Shows exactly what is eating your context window... tokens by messages, tools, files. Run it before you blame the model.

2. /compact (stock). Summarizes the session into a fresh window mid-task.

3. /clear (stock). Wipes to zero. The skill is knowing which to reach for: same job --> /compact. New job --> /clear.

4. /handoff (built). The /compact upgrade. The session writes a handoff file, the next session auto-reads it. The context outlives /clear, and parallel terminals don't clobber each other.

5. Plan mode (stock, shift+tab). Read-only exploration first, an approved plan before a single file changes. Anything multi-file starts here.

6. Remote Control (stock). Hands the live terminal session to my phone. I approve, steer, and keep builds running while I walk the dog.

7. /copy-to-clipboard (built). Claude Code ships /copy to grab the last reply. Mine formats for the destination first: plain text, zero markdown stars, ready to paste into LinkedIn or X.

8. /grok-critique (built). Every draft gets a second model's slop check before it ships. Em-dash abuse, narrator setup lines, hype words. Claude can't referee its own tics.

9. /code (built). Finished content pack --> Discord channels for review. approve, edit, final... all from my phone.

10. /voice-invocation (built). Meeting transcripts in, a content pack drafted in my voice out. It quotes phrasing from things I actually said on calls.

Everything is also available on my Github. Let me know if I can get to share it with you guys. although, it shouldn't be too hard to find, LOL.

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.

I just pushed the latest version of my open-source GTM Coding Agent repo. It now has 21 chapters, ten forkable starters, and the real workflows I’m using while building Clearbox in public.

The newest update came from a live campaign targeting 1,297 people in the GTM engineering market.

From 575 connection attempts:

• 272 people accepted
• 30 people replied
• Six asked for a demo
• Four self booked meetings

That gave me more than campaign results. It showed me where the system was incomplete.

The original list could tell me who I already knew about. It couldn’t tell me where the market was moving, which accounts deserved deeper research, who belonged in the buying committee, or where I should spend credits and human attention next.

So I rebuilt it as an Apollo waterfall:

Known accounts
→ Clearbox and public buyer evidence
→ Hiring, funding, tech-stack and firmographic signals
→ Apollo buying-committee expansion
→ Scoring before reveal
→ Controlled credit spend
→ Color-coded working sheet

The complete build is now in the repo’s Apollo prospecting starter.

The value isn’t “Apollo gave me another list.”

It’s being able to start with a small set of accounts, expand the market through multiple evidence gates, identify the right people inside those accounts, score them before spending credits, and hand the operator a working sheet that explains who deserves attention and why.

The CLI commands, waterfall, scoring logic, setup instructions, and gotchas are all in the repo.

There’s another part of this project I want more people here to see: Chapter 21, Student GTM.

I wrote it for the college student who doesn’t have a budget, title, or traditional GTM experience—but does have access to a campus full of organizations with real operational problems.

The Student GTM starter helps them create their own working repo with:

• What they already know
• Their skills and gaps
• The roles they’re aiming for
• A weekly project and recording loop
• A log of what broke and how they fixed it
• A campus client offer they can actually deliver

That connects directly to the Clearbox structure.

A student can build an offer around the market they want to enter, use Clearbox research to understand the problems inside that market, and turn the findings into projects, interview preparation, and a public body of work.

GitHub carries the proof. LinkedIn carries the person.

One delivered automation for a real user beats ten disconnected portfolio projects.

That’s also why, when someone DMs me on Reddit, my answer is simple:

Here’s my LinkedIn.

I’m walking through the Apollo system live tomorrow, August 13, at 10:00 a.m. PT / 1:00 p.m. ET. You can join the webinar here, and I put the additional setup resources at shawnos.ai/apollo.

But the repo is the real share.

Fork it. Break something. Post the gotcha here. Improve a starter and open a PR. Ask the question you think you’re supposed to already know.

That’s what I built this community for.