In case you missed it, here's what I shared yesterday: Why You'll Never Buy SaaS Again.

Yesterday I said the SaaS first rule had expired. Today I want to put the whole argument in one place.

These are views I believe in more and more. Some need nuance. All ten come from building inside real teams.

AI can produce useful software in days or weeks. One part time GTM engineer rebuilt Vercel's inbound qualification in six weeks. A GTM team can test an owned workflow while a traditional purchase is still moving through meetings.

Tim Rutten's team at Backbase shows the same collapse at a bigger scale. Full disclosure I help architect and run the creation of their GTM OS. His 35 person marketing group supports a business above 350 million dollars in ARR. A weekly scan of 3,000 mid to large banks now costs around 500 dollars at max. Account planning fell from weeks to about 65 minutes. Quarterly business review prep went from two to three weeks to automated.

I have watched this timeline compress for 23 years of building GTM engines. The last two to three years have been different. I have built 27 GTM x AI engines through the embedded engineers my studio places, across more than 100 projects that ran from seed stage startups to enterprise teams. Six weeks for a rebuild used to sound aggressive. Now it is closer to normal.

The first version is a smaller part of the job. The real work connects data, settles definitions, sets access, decides approvals and maintains the system as the business changes.

This is actually the heavier lifting, and it sounds harder than it actually is:

Large annual licences were easier to accept when custom software needed a large engineering team. Building costs fell much faster than many software bills. Every large renewal deserves a fresh look when the workflow contains company specific logic.

Salesforce announced an average list price increase of 6 percent for selected enterprise products from August 2025. Jason Lemkin reported that his Salesforce bill rose 80 percent year over year while his seat count fell, according to a secondary account.

Useful GTM data lives in the CRM, billing records, product events, support history and team conversations. Each copy creates another permission and another place to fail. I prefer software that acts inside an environment the company controls.

A company should be able to read the software that scores accounts, routes leads and sends messages. Code in your repo can be inspected, changed and kept. That matters when prices rise, tiers disappear or a service closes.

Uber paired about 30 AI proficient engineers with domain experts and formed 16 pods across 16 functions in two months. Marketing quality assurance went from two weeks to under an hour. GTM engineer and revenue operations postings rose 205 percent between two comparable nine month windows in 2024 and 2025, across 1,000 analysed roles.

LangChain's GTM agent points the same direction. Lead to qualified opportunity conversion rose 250 percent between December 2025 and March 2026. Pipeline dollars tripled over the same period. The numbers are self reported with no control group. That is a real limit worth naming. Still, the pattern shows up again in a second company building its own revenue motion instead of buying one off a shelf.

I see this happen constantly across the consulting work, building GTM OS and placing engineers inside client teams. A marketing lead used to hand a brief to an agency or wait on a vendor roadmap. Now a domain expert sits with an embedded engineer for a sprint and ships the workflow themselves. Working inside more than 100 of these projects taught me the pattern. The people who used to write requirements documents are now the ones reviewing pull requests.

I also wrote about this here: https://www.heyarnoux.com/marketing-becoming-engineering-function/

This one is also a good read: https://www.thestateofbrand.com/news/marketing-engineering-org-chart

Good service work produces methods, checks and templates. Cheap code turns the repeated parts into running systems. The people stay close because every company has its own data, definitions, politics and judgment.

BTW, have a quick read here: https://sequoiacap.com/article/services-the-new-software

I expect leading models to become more interchangeable for daily GTM work. Model labs are moving closer to applications as raw model access becomes less distinctive. I rent model capability and keep company rules in a separate layer.

That change is not complete. Open source models accounted for 11 percent of enterprise language model API usage in the Menlo study, so frontier capability still sits with closed providers.

Public models can read books, websites and generic marketing advice. Client work produces a different record. It shows which score created noise, which objection predicted a lost deal and which approval stopped a bad send.

Reusable patterns improve when real teams test them. Client data stays out of the shared core. The learning sits in the pattern, the test and the documented failure.

A modern GTM engine demands discipline, consistency, routine and repetition at a volume that wears people down. I keep seeing people approve output faster than they can truly review it. Developers fall into the same habit when code arrives faster than attention can follow.

The human gate often becomes a rubber stamp. This happens often enough to change the architecture.

Some actions still need real judgment. Relationships, unusual deals, brand risk and political choices deserve time. Machines can carry the routine so people can spend their attention there.

The guardrails have to be right from the start. Clear definitions, access rules, tests, limits, logs and undo paths matter more as output grows. A button labelled approve provides little protection when the reviewer cannot keep up.

The honest counter is that the market already tested this and chose vendors. Managed operation, fast product improvement and elastic capacity beat local control. Aggregate software as a service spending still grows. Forrester expects 576 billion dollars by 2029.

I accept all of that. My argument works at the level of one motion. Forrester's own vulnerable class is the useful part of that forecast. Low switching costs and workflows with weak enterprise embedding describe many point tools sitting inside a go to market stack. Those are the pieces a team can take back.

The system of record stays a managed service. Frontier model capability stays rented. The company rules move into code the company can read. The famous replacement stories people quote in this argument settle little for either side.

I still truly believe in the below table I created

Most GTM teams run familiar motions. Their advantage sits in how they define the customer, read the signals, make decisions and act with consistency.

I think companies should own that layer. They can keep renting systems of record, model access, enrichment and compute. The operating rules deserve a home they can inspect and change.

This is what winning GTM teams look like right now. No vendor lock-in. LLM-agnostic by default, so the system holds when a model provider changes terms or a better one ships. Built as they go, adjusted the moment the business changes. Lean enough that a small embedded team outruns a large vendor stack. That combination keeps them on the cutting edge.

Tomorrow I will show the team that can run it. Marketing is becoming an engineering department and the GTM engineer is already a real job.

David

Tomorrow: Marketing Departments Are Becoming Engineering Departments

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.