My GitHub is github.com/mariellecamba-gtm. Most of the repos are private because they're wired into client infrastructure, but the architecture is worth describing. It's the clearest evidence of what "GTM engineer" means as opposed to "outbound operator."
Everything below was built with Claude Code and Cursor, and every one of them exists because I got tired of doing something manually.
1. Deliverability agents: one repo per client
Eight zero-dependency Node agents that monitor a single client's sending infrastructure on a schedule via GitHub Actions. Each run posts to GitHub Issues (which becomes the searchable history), commits a markdown report into the repo, and alerts Slack when something needs attention.
- campaign-reporter: daily morning snapshot of every campaign, with a Slack alert if performance is off-target.
- warmup-stats-collector: appends a warmup and reputation snapshot to a rolling monthly tracker issue.
- deliverability-healthcheck: trend detection for bounce spikes and reply or warmup decline; only opens an issue when something is actually unhealthy.
- campaign-trigger-checker: flags campaigns marked active that have sent zero emails today. This catches the silent failure mode where everything looks fine and nothing is sending.
- domain-blacklist-checker: weekly DNSBL check of every sending domain.
- domain-recommender: weekly answer to "which domains do we cancel, and how many do we buy?", written as an immutable issue plus a CSV.
- mailbox-isolator: removes low-reputation or blocked mailboxes from campaigns.
- mailbox-repair: re-enables warmup on broken mailboxes.
Two design decisions I'd defend anywhere. First, the two agents that mutate live systems default to dry run: scheduled runs only report what they would do, and making real changes requires a deliberate manual trigger. Second, with no API key configured the agents run in offline mode instead of erroring, so the whole thing is safe to smoke-test.
The client scoping is a hard safety filter: each repo carries a config file pinning it to one client ID, with campaign name-prefix and explicit-ID fallbacks, plus that client's own targets and thresholds. One repo, one client, no chance of cross-contamination. A scaffolding script spins up a new client repo from the template.
2. gtm-jobs-feed (public)
The one public repo, and a nice compact demonstration of the whole discipline: it's a complete outbound pipeline with no servers, no database, and no spreadsheet.
Every Monday, GitHub Actions searches for GTM Engineer and Go-To-Market Engineer roles across the US, EU, Australia, and New Zealand. It keeps only genuine matches posted in the last seven days, then dedupes twice: by job ID and by company, so a company can only ever generate one issue. The dedupe state is a JSON file the workflow commits back to the repo after each run, which means the repo is its own database.
For each new company it finds up to three decision-makers through a waterfall ICP lookup that is size-aware: at 200 employees or fewer it includes the CEO or founder alongside revenue and growth leaders; above 200 it skips the CEO and focuses on growth, GTM, and revenue roles, because at that size the CEO isn't the buyer. It then opens a labeled GitHub issue for the job with the contacts attached, and pushes those contacts into a LinkedIn connection campaign.
There's a cap on how many issues a single run can open, because an unbounded automation that touches an external system is a bad idea. The dedupe state was seeded from the legacy version (133 companies and 134 job IDs) so nothing already handled got re-filed. All credentials live in Actions secrets only; nothing sensitive is committed. It replaced an older Supabase edge function and Google Sheet setup, and the legacy code is archived in the repo for reference.
3. Best campaign of the day
A research tool disguised as a report. The stated goal is learning what makes one outbound campaign outperform another, and its first answer is the daily version of that question: which live campaigns had the best positive reply rate today?
It ranks the top five active client campaigns by positive replies received today divided by emails sent today, where "positive" is a specific set of reply categories rather than a loose definition. Details that make it trustworthy:
- A minimum send floor so a campaign with 1 positive out of 20 sends doesn't top the chart, but campaigns below the floor are listed separately rather than hidden.
- Multi-workspace merging, because clients on separate accounts are invisible to one another; each key is queried and the results merged into a single ranking.
- Loud failure. If one workspace can't be queried, the report prints a warning at the top saying the ranking is not trustworthy and explaining what's missing. A silently incomplete leaderboard is worse than no leaderboard.
- The actual copy, extracted. Each report includes the winning campaign's sequences verbatim (spintax, custom variables, conditionals) plus the emails rendered exactly as they went to the leads who replied positively, with variables filled in. That's the part that makes it a learning tool instead of a scoreboard.
- An honest methodology note stating that positives today can include replies to emails sent on earlier days, so this is a daily-activity rate rather than a same-cohort rate.
It runs at 9PM ET daily via GitHub Actions, handles daylight saving correctly, and commits each day's report back to the repo.
4. This website
A Flask app deployed on Railway. The case studies, campaigns, skills, blog, pricing, and this post are all served from it. Built with Cursor and Claude Code, which is a small point but a real one: I'd rather run my own site as code I can extend in an afternoon than pay for a page builder I can't script against.
The pattern across all of them
Look at what these have in common: automations that report rather than assume, mutations that default to dry-run, hard client isolation, secrets that only live in secret stores, loud failures instead of quiet ones, and history committed somewhere searchable. That's not GitHub-specific taste. It's the same discipline that keeps a client's suppression list intact and keeps 16,000 leads from silently vanishing from an upload.
The code is a byproduct. The point is running eight clients' outbound without anything quietly breaking.