In case you missed it, here's what I shared last: Marketing Departments Are Becoming Engineering Departments.
As a GTM leader I think you should own your code, your infrastructure and your data. Here’s a demo version of what that would look like… feel free to look around:
Password: gtm-brain-x742
Now for some theory…
You would never outsource the code that makes your product yours. Distribution can matter just as much as product. The code deciding who gets called, what gets sent and what an account is worth deserves the same care.
The title is a big claim sure…but I’m referring to a specific scope…here it is in one simplified table:
By decision layer I mean the logic that decides who gets contacted, which use case applies, which ads run, which campaign level fires, what content gets written, which ABM plays go out, what gets sent and when to stop. Today that logic sits scattered across a handful of vendor tools, each holding a piece you can only see through their dashboard and only move if they let you.
Oh and they keep changing their pricing/rules/access/terms:
Twitter announced the end of free API access on 1 February 2023 with access due to end eight days later.
Reddit repriced its API at a level that would have cost the Apollo client about 20 million dollars a year at its reported volume. The client closed in June 2023.
Unity announced a runtime fee that changed the economics of software already built on its platform.
HashiCorp moved its core deployment tools off an open source licence in August 2023. OpenTofu carried the available source forward and reported 9.8 million downloads from GitHub releases in June 2025.
Elastic restricted its license in 2021 then restored an open option in August 2024. Trust had already moved to a fork by then. Redis followed the same pattern. It restricted its license then reversed course in May 2025 after an earlier restriction and a community fork. Valkey and OpenTofu both showed the same thing. Source code, tests and a deployment path let a community keep a working branch running while the vendor changed terms twice.
The products differ sure but the dependency is basically the same every time. A team builds an important motion on terms it cannot control. One decision upstream forces a rebuild.
The risk grows as agents take more actions. Losing a reporting screen causes inconvenience. Losing the system that scores the market, routes accounts and approves spend can stop work across the team.
The four things I want under company control
First, the code expressing the rules.
Second, the infrastructure running that code.
Third, the data model giving the rules meaning.
Fourth, the history of approvals, corrections and outcomes that improves the system.
Together they give the company a practical exit. An engineer can inspect the logic, replace a connector, move to another model and keep the operating knowledge. This matters during ordinary change too. A new territory, pricing model or sales process should lead to an edit the team can see. The rule belongs in a file with an owner and a history. That gives future operators a record of why the system behaves as it does.
That exit changes the vendor relationship too. The team can choose a provider for quality and service because migration is possible. The CRM, enrichment source, messaging provider, cloud service and frontier model can keep changing around the owned layer.
This is what I see in the GTM teams winning right now. No vendor lock-in. LLM-agnostic, so swapping the model behind a workflow is a config change. Free to build as they go, adding a rule or a connector without waiting on someone else's roadmap. Highly efficient, with nothing sitting idle behind a subscription they can't inspect. And on the cutting edge, because they can adopt a new model or method the same week it ships.
Don’t buy all this….build it.
And I’m seeing more and more and more teams for very serious companies working this way now.
The cloud objection (I hear this one a lot)
On premises software lost to cloud software for good reasons. Managed operations, fast releases and low starting costs beat owning hardware in a basement.
Running code in your own cloud account keeps the useful part of that model. A cloud provider handles the machines. Your team holds the keys, sets the access and knows where the data sits.
This still creates work. Someone patches the system, monitors jobs, reviews access and responds when a dependency changes. Ownership replaces one kind of risk with operational responsibility.
That is why I start with a narrow decision layer.
Keep the system of record. Keep managed email delivery. Keep model access. Put your definitions, scoring rules, routing, approvals and orchestration in a layer your chosen engineer can read and move.
There is a middle category too. Some of what you are renting today is actually a vendor doing your thinking for you, a scoring tool, a sequencing tool, a workflow tool that encodes your rules inside someone else's product. Once you own your decision layer, that specific job goes away. You do not replace 6sense or Outreach or Clay with another vendor. You replace what they were doing with your own code.
What stays rented
Enrichment, deliverability, the ad platforms and the machines themselves stay rented too. A provider running a utility at scale will do it better than your team.
Managed infrastructure already supports the owned part. Kubernetes reached 82 percent production use among container users in the 2025 CNCF survey announcement. That population is organisations already running containers, so it is a narrow base. Within that group, deploying onto a company cloud account can use an operating layer the enterprise already has.
Workload shape decides where the line falls. One company moved steady compute off a public cloud after an annual bill above 3.2 million dollars. It bought about 700,000 dollars of hardware in 2024 and reported roughly 2 million dollars in annual savings. The same move would fail on volatile demand with no operating team.
The provider owns service operation. Your own layer applies the budget rules, the lifecycle triggers and the model routing through logged gates. The adapter between them is the contract.
AI native means committing to the architecture
I collaborated on a project that led Tim Rutten to write about going fully AI native. His argument matches what I see in the work. Adding an agent to a broken chain preserves the broken chain.
The deeper work redraws the process around data, rules, machines and people. You can read Tim Rutten's piece here.
The account gives a real number. He runs the weekly scan against 3000 mid-to-large banks for around 500 dollars a week at max. The scoring model behind it is roughly 70 to 80 percent deterministic, with 4 to 5 parameters he tunes by hand each month. His director of revenue operations rebuilt the reporting stack in three months. Nobody checks Salesforce anymore. What stood out to me in his account was the word inspectable. His team can open the scoring logic and read exactly why an account got the score it got.
I recognized it because it's the same choice I make with every engineer I place. 23 years building GTM engines taught me the tools change constantly and the rules rarely do. The last 2 to 3 years I have focused specifically on GTM x AI engines, across more than 100 projects from seed stage to enterprise. I keep watching the same failure mode repeat. A team adopts a smart vendor tool. The tool quietly encodes months of tribal knowledge about how deals actually get won. The day that vendor changes terms or shuts a feature down, the team loses the knowledge along with the tool. 27 of the engines I have helped build now run their decision layer in code the client owns. That number is not an accident. It is the whole point of how I run the studio.
That is also why owning a few scripts provides a weak exit. The code, infrastructure and data need to move together. A public repository hosted entirely by one vendor can leave the same dependency in place.
My practical test is simple. If a provider disappears next month, can your chosen engineer keep the motion running?
Commodity tools can fail this test and the business will cope. The layer deciding account priority, spend, messages and approvals should pass it.
Next, I will explain why most of the motions can be plug and play while the company rules stay local.
David
Next: 80 Percent of GTM Is the Same Across Companies
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.
