In case you missed it, here's what I shared yesterday: The 'Build' Era of Go to Market Has Started.

Before any of that, the long version is now published as a position paper. It argues that the code deciding how a company goes to market should sit inside that company, while the systems of record, the models and the infrastructure stay rented. It carries the three year cost model, the charts behind it, public cases from Vercel, Uber and Backbase, with 55 references. Read it at The Case for Building Your Own Go to Market Engine.

I've been building GTM engines for 23 years. For the past 2 to 3 years I have focused on GTM x AI engines. I have built 27 of them with the developers we embed. I have been involved in more than 100 projects, from seed stage companies to enterprise.

Twenty three years is long enough to watch a few cycles turn. I started when GTM meant a spreadsheet and a phone. I built through the SaaS wave, the marketing automation wave and the account based wave. Each one promised to be the last platform anyone would need. None of them were. What changed two to three years ago is that I could finally build the missing piece myself instead of waiting for a vendor roadmap to catch up. That is the work now, building GTM OS, running fractional engagements through heyarnoux.com and placing embedded GTM engineers inside client teams. Seed stage founders and enterprise teams ask me the same question in different words. They want to know what to keep in house and what to rent. The age-old question (more like a puzzle) for RevOps today. Twenty seven builds later I have a real answer for both of them.

GTM has followed a SaaS first rule since Salesforce brought customer relationship management to the cloud in 1999. Whenever a team had to choose between building and buying, the answer was buy. Every time.

Building meant borrowing engineers from product. It meant joining a queue, finding a budget and waiting months for a first version. A tool could arrive after one meeting and a credit card.

The title is exaggerated. You will keep buying software. I will too. I think the old rule has expired for the code that decides how your go to market works.

I came to that view through the work.

This is an exciting place to work right now. Small teams can turn judgment into software while the problem is still fresh.

The motions keep coming back in the same order. SEO. GEO. ABM. Lead scoring. Outreach. Research. Reporting. Lifecycle. Ads. Approvals.

My rough estimate is that 80 percent of what I keep rebuilding follows a common shape. Put more plainly, most companies run the same motions and we build the same parts again and again.

That number is a hypothesis from my own builds. No published component level denominator settles it yet.

The rest makes the system belong to one company. Its taste. Its tone of voice. Its definitions. Its rules. Its approvers. Its data connections.

That rest carries the judgment. It decides what a qualified account means, who may contact it and which action needs a person to approve it.

AI cut the time and cost of a useful first version. The hard work now sits inside the company.

Uber reported in August 2026 that agents were attributed on more than 70 percent of its pull requests. Its cost per session fell 52 percent from a June peak while weekly agent requests grew 9.4 times between February and August.

The numbers on one public build make it concrete. Drew Bredvick wrote up Vercel's first GTM agent, an inbound qualification motion that a part time engineer replaced in six weeks according to Tomasz Tunguz's account. Drew puts the running cost at roughly 60,000 dollars a year in engineering time and API cost against more than 2 million dollars saved. Those figures come from a company with strong engineering practice, so they describe the good case.

A second public example points the same direction. Tim Rutten at Backbase built a system (which I helped architect and orchestrate) that scans roughly 3,000 mid to large banks every week for around 500 dollars at max in cost, with four to five scoring parameters tuned monthly. Quarterly business review preparation fell from two to three weeks to an automated process. Account planning dropped from weeks to about 65 minutes. Two different companies. Two different motions. Same pattern underneath. The engineering cost kept falling. The rules about which banks matter, which parameters to score and which review a team trusts stayed inside the company that built them.

The wider cost base is moving too. Sequoia reports six dollars of services spending for every dollar of software spending. That ratio gives owned automation a larger possible target than licence savings alone. It also raises the bar. A build has to replace a measured part of a motion, survive daily operation and hold the quality the team already had.

Someone still has to connect the data. Someone has to settle the definitions. Someone has to set the access rules, test the workflow and keep it running as the business changes.

That is why I think value has moved toward deployment. The code matters. The people who understand the business and put that code to work matter more.

The most useful GTM data sits in the CRM, billing system, product events, support history and daily conversations. The rules acting on that data should live somewhere the company can inspect and control.

I still rent CRMs, models, enrichment and cloud compute. I want the company rules, data model and orchestration under company control. Those pieces contain years of decisions that no vendor should be able to switch off.

That belief led us to GTM OS.

GTM OS packages the GTM motions our teams keep rebuilding and gives each company a place for its own rules and data. We are in closed alpha. You can read the direction at https://www.heyarnoux.com/gtmos/ Request the demo there or join the founding group at https://docs.heyarnoux.com/gtm-os-founding/

The teams pulling ahead right now share a pattern. They carry no vendor lock in. They stay LLM agnostic so a model swap never forces a system rebuild. They keep the flexibility to build as they go instead of waiting on a roadmap. They run lean and efficient. They sit on the cutting edge because they own the layer that changes fastest. That is the standard GTM OS is built to meet.

Over the next six days I will share the ten beliefs behind it, the engineering team forming inside marketing, the case for owning your infrastructure, the common 80 percent and the best arguments against the whole idea.

On Day 7 I will show you the system I wanted to buy.

David

Tomorrow: My Case for Owning Your GTM

By the way, if you need help building your GTM engine, reach out on the collab page. If you are ready to start building, I have GTM engineers ready to embed in your team.