Sales problems,
software solutions.

The first lead I ever generated was in 2016, running a recording studio: an Instagram ad turned into a stranger paying me to record, then a dozen sessions together. I've been chasing that exact high, an ad becoming a real person with money, ever since.

Years later in SaaS, revenue ops handed me an outbound list: an Apollo filter for software companies over $10M in revenue, no shared trigger, no thesis, nothing connecting any two accounts on it. Somebody didn't care and lobbed a dead cat over the fence into my lawn. That was the first time I opened Clay, on a seat I paid for myself as an SDR, parsing the list account by account for who was actually showing growth signals and who was worth going after. I've spent the years since trying to replicate that feeling: turning a pile of nothing into a list where every row has a reason behind it.

Everywhere I've looked, revenue teams run on tribal knowledge and duct tape. The list got built the way it got built because that's how Sarah built it before she left. The CRM field means something nobody remembers. The sequence is still sending because nobody turned it off. People do things in genuinely dumb ways, not because they're dumb, but because nobody ever went back and asked why the process works the way it does.

GTM is tribal. It doesn't have to be.

That Clay habit never really stopped. Thousands of hours across a few years, well before "AI" was a job title. So when the models got good enough to write real code, something clicked: I didn't need to become an engineer. I needed to point the engineering at the problems I'd been living inside for years.

That's my whole definition of GTM engineering, and I think it's better understood as a set of principles than a defined role. The core principle: apply software solutions to sales problems. Not "go buy a tool." Ask where code, workflows, AI, and automation create real leverage in the revenue function, then build exactly that.

The jobs-to-be-done knowledge is what matters. Not the syntax.

There's a trap in this work I call the dopamine-hit workflow. Building a CRUD app with a sleek frontend by prompting Cursor is genuinely cool. It feels productive. But does it close deals? Does it drive pipeline? Almost certainly not. I've lived the bottlenecks at every stage of the funnel, so I build for the outcome, not the build. Every system in this portfolio exists because a revenue problem was bleeding: replies getting dropped, attribution being argued in Slack threads, job-change signals rotting in a dashboard nobody opened.

And I hold my own work to a harder standard than "it demos well." My systems have preflight checks before anything touches a sequencer. Human gates where taste matters. Reconcile crons because webhooks lie. Rollback files before bulk CRM writes. The boring parts are the parts that make it production instead of a party trick.

I'm not building automations. I'm building an employee.

An automation runs a script and breaks when someone renames a field. An employee interprets a request, checks the context, asks when it isn't sure, and gets more useful every week. That's what my Claude Code environment actually is: an operating system for AI agents. Identity and judgment rules always loaded, domain knowledge that loads when the task calls for it, API docs that heal themselves when a call fails, and a memory that compounds every gotcha so no lesson gets paid for twice.

This is also where I think the whole industry is going. The future of SaaS is headless: you log in once to get the API key, and you never touch the UI again. Agents, context, APIs. Complete API parity, machine-readable docs, bulk operations. Vendors who competed on pretty dashboards just lost their competitive advantage, because if I never open the UI, I don't care how smooth the onboarding flow is.

Push that logic all the way out and it gets stranger. I think there's a future where go-to-market teams basically live in Cursor, prompting workflows all day, and the CRM itself is vibe-coded, purpose-built for that one team's motion instead of duct-taped onto whatever Salesforce assumes about your business. What survives are the handful of APIs nobody bothers rebuilding: a unipile for inbox and LinkedIn access, a sending tool like EmailBison for deliverability infrastructure that took years to get right. Everything else gets custom-built from the ground up because the coding tools got cheap and good enough to make that saner than configuring software that's 80% wrong for your motion. I'm not saying every team should be doing this today. I'm saying that's the direction the tooling is dragging all of us, and I'd rather build for that future than defend the dashboards it's about to make obsolete.

My entire body of work is collapsing the GTM stack into a single chat window.

The value was never in clicking the buttons. It was in understanding which buttons to click, and that understanding is getting commoditized fast. What doesn't get commoditized is the judgment: knowing which signals matter, which contacts to never email, which numbers leadership can actually trust. So that's what I encode. The gates, the exclusion rules, the human pauses. Judgment as infrastructure.

One more thing I believe about the people side: curiosity beats credentials. When I evaluate anyone for this kind of work, and when anyone evaluates me, the question is the same: what have you built? Not certifications, not tenure. The gap between "here's what I've tried" and "I haven't touched any of this" is not a training gap. It's a curiosity gap, and you can't teach curiosity.

Give me the keys and the agency.
I'll bring the factory.