In case you missed it, here's what I shared yesterday: 80 Percent of GTM Is the Same Across Companies.

Building your own GTM stack can be a terrible idea.

The subject is direct because the objections are real. Cheap code solves the first version. A company still has to operate everything that follows.

A 2026 paper on the build or buy decision puts operations, maintenance, enhancement and retirement at 60 to 80 percent of software lifecycle cost…basically said = building is cheap, maintaining is expensive.

I believe this to no longer be true. But this post is about challenging my own thoughts.

AI compresses the first version. Patching, monitoring, governance, model cost, security and retirement remain.

METR ran a randomised study on early 2025 AI tools with sixteen experienced developers on mature repositories. They took 19 percent longer with the tools. Afterwards they still believed they had worked faster. Different year, different tools, different repositories to the Uber result. Both can hold.

METR reran the study in late 2025 with the developers who came back for a second round. That group showed a speedup of 18 percent, with a confidence interval that runs from 38 percent faster to 9 percent slower. METR calls this very weak evidence and says it is changing the design of the study. Read plainly, the honest state of the research on AI assisted building speed is unsettled. Nobody outside the study should treat either number as proof. That uncertainty is exactly why the maintenance math above carries more weight than any productivity claim attached to the tools themselves.

I have watched this exact mistake happen from the inside. Twenty three years building GTM engines, the last two to three years specifically on GTM x AI engines, across more than 100 projects from seed stage to enterprise. The pattern repeats itself more than any other failure I see. A founder watches a demo, gets excited and green lights a full replacement of three systems before anyone proves that one workflow moves a number. Six months later the team is maintaining a homemade system that only the original builder understands and the motion that started the project never shipped. I have sat in that postmortem more than once. It is the reason I push every client toward one workflow with one visible outcome before they touch anything else.

This makes managed software a good choice for many workflows. Standard processes, heavy compliance and teams without engineering capacity all strengthen the buy case.

Owning a system makes maintenance visible. SaaS spreads work across integrations, field mappings, usage credits, renewals and workarounds. The right comparison includes every person cleaning data, investigating failures and keeping the workflow aligned with the business.

A cheap licence can support an expensive process. An expensive build can earn its place when it protects a valuable motion.

Klarna became shorthand for a broad replacement programme. I read that story as a warning about scope.

Rebuilding a suite creates a long list of dependencies before the team proves one useful motion. Every integration becomes a project. Every missing feature becomes an argument. The programme can spend months reproducing generic software.

I prefer one workflow with one visible outcome.

Vercel rebuilt inbound qualification with one part time GTM engineer in six weeks. That unit can be measured before the company chooses the next motion.

Company controlled infrastructure needs patching, access reviews, incident response and an owner who can be called when something breaks.

A container in your own cloud account removes the server room. It still needs a capable person.

One clever builder can create a shadow system that nobody else understands. Version control, written definitions, a second reviewer and an incident owner belong in the plan from the first workflow.

Source availability gives an exit only when someone can understand and run the code.

If your team has limited engineering time, keep the owned layer small. Choose the rules and orchestration that carry real company advantage. Keep buying the commodity parts.

The paper behind this series sets a rough threshold for when building earns its place. One GTM engineer, a named operator and a review practice, in either a B2B or a B2C business. Below that staffing level, the paper's own conclusion is to buy. Regulated work tilts further toward the vendor because certification does work a two person team cannot replicate in six weeks.

I have watched this exact trade happen with a client, without needing to name them here. The team chose the open route because it looked cheaper on a spreadsheet. They then spent far longer standing up the security review, the incident owner and the recovery plan than they spent on the build itself. That gap is the real cost of ownership and it rarely shows up in the pitch that gets a project approved.

If you need a GTM engineer, you can contact me here. We embed engineers inside the team so the business context stays beside the build.

A mature vendor can bring certifications, a security team, tested recovery and years of operating experience. That can decide the buy case in a regulated environment.

Company controlled infrastructure can help when data residency and access are the main risks. The answer depends on the data, the team's capability and the controls already in place.

The useful test asks who can protect the system better across its full life.

Open code carries its own supply chain risk. The xz backdoor in 2024 showed how one maintainer's access could expose a widely used package.

It also asks how quickly the team can recover. Who receives the alert. Who can stop the workflow. Who can restore the last good version. Who explains the incident to the people affected. Ownership needs clear answers before the first automated action runs.

Several infrastructure vendors withdrew open terms after building adoption. Elastic later restored an open option. Developer testimony collected after that reversal reported that trust had already moved to a fork.

Redis restored an open licence option in May 2025 after an earlier restriction and a community fork.

Open publication on its own guarantees very little. The protection sits in the licence terms, a practical fork right, active maintainers and operation the company controls. A fork helps only when someone maintains it and someone on your team can run it.

Broken trust can survive a later reversal. That is the honest version of the exit argument I have been making all week.

Model providers retire versions and APIs. A workflow tied directly to one provider can fail on that provider's timetable.

An abstraction layer helps the company move between models. It still needs maintenance and testing. Owning orchestration reduces dependency on one provider and creates responsibility for the adapter.

I buy commodity systems of record. I rent models, compute and enrichment. I own the company rules, data model and orchestration when those pieces create real advantage and the team can maintain them.

For some companies the owned layer should stay small. For others it will carry most of the revenue motion.

The first discovery should be allowed to end with a software purchase. That is a useful answer when ownership adds more burden than control.

Even with these risks, the teams getting this right share a common shape. No vendor lock-in on the workflows that matter. LLM agnostic by default, so a pricing change or a deprecated model does not stop the business. The flexibility to build as they go, adding one workflow at a time instead of committing to a full suite upfront. High efficiency because the owned layer stays thin and the commodity parts stay bought. They operate on the cutting edge, testing new capability inside a system they control instead of waiting on a vendor roadmap.

GTM OS packages the owned layer with deployment support around it. We are in closed alpha and building with a founding group. Read the current direction at https://www.heyarnoux.com/gtmos/ Request the demo or join the group at https://docs.heyarnoux.com/gtm-os-founding/

Next week I will show what we have built and how I would start inside a company.

David

Next week: We Are Open Sourcing the GTM System I Wanted to Buy

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.