The Case for Building Your Own Go to Market Engine

Contents

1. Introduction

For fifteen years go to market teams defaulted to bought software. Building demanded engineers, long implementation cycles and permanent maintenance. Agentic development has reduced production cost enough to reopen that decision. This paper argues that capable teams can build and own the code that directs a motion while renting specialist services. The operating scope runs from search and ads through outreach, sales handoff, lifecycle and localization. Sales handoff is the moment a lead passes from marketing to a seller. Lifecycle is the contact a company keeps with a customer after the first sale.

Uber reported in August 2026 that local or cloud agents were credited with more than 70 percent of its pull requests. A pull request is one proposed change to a codebase, submitted for review before it is merged. The company had more than 3,600 agent skills, meaning saved instructions an agent can reuse. It ran more than 30,000 skill runs a day. Its cost per session fell 52 percent from a June peak while weekly agent requests grew 9.4 times between February and August [5]. Uber runs a dedicated platform engineering team, so the figure is used here for production capacity only.

The strongest counterweight comes from METR. Its randomised study used AI tools as they stood in early 2025, namely Cursor Pro with Claude 3.5 and 3.7 Sonnet. It covered sixteen experienced developers and 246 issues, meaning recorded pieces of work, in mature codebases averaging more than one million lines. Developers took 19 percent longer with AI tools. Before the tasks they expected to work 24 percent faster. After the tasks they still believed they had worked 20 percent faster [6]. METR's next published study was a survey. In February to April 2026 it asked 349 technical workers what AI had done for them and recorded a median self reported gain of 1.4 to 2 times in the value of their work [60]. METR states in the same place that its early 2025 study found people overestimated the effect on their own task time by 40 percentage points on average [60]. The randomised result is therefore dated to early 2025 tooling. The later self reported figures are not a measurement of the same kind. The evidence still supports a capability threshold, because tools cannot supply operating judgement, review discipline or maintenance.

Ownership has a defined boundary here. A company owns the code that defines its leads, stages, scores, routes, gates, approvals and spend rules. A route is the rule that sends a record to a person or a queue. A gate is a check a record must pass before the next step runs. It owns the orchestration, meaning the logic that decides which person or agent acts next. The database, enrichment service, delivery channel, ad platform, model and compute can remain rented.

2. Position

2.1 Working definitions

WD1. The decision layer. The decision layer contains the data model, definitions, rules and orchestration that direct a go to market motion. The data model defines a lead, account, stage and customer. The rules cover scores, routes, gates, spend limits and approvers. The orchestration chooses which person or agent acts, in which order and on which trigger. A trigger is the event that starts a step, such as a form completion or a stage change. The layer decides who receives contact, what gets sent, what a lead is worth and what gets charged. Trust in the data, context and permissions is the core operating question [7].

WD2. The tool layer. The tool layer stores data or executes an action. It includes the system of record, meaning the database holding the master copy of customer data, plus enrichment, email and messaging delivery, ad platforms, models and compute. These components are rented by default because scale, network coverage, certification and frontier capability sit with specialist providers. Their interfaces can change. One current provider promises at least six months of notice before it withdraws a widely released model and at least three months for specialised versions [8].

WD3. An owned go to market system. An owned system holds its decision layer as source code in the company repository. A repository is the store that holds the code and every past version of it. The system runs in an environment where the company holds the keys, meaning the credentials and the administrative rights. The company can read, change, fork and keep the code. Data access follows its existing controls. Ownership includes six things. The definitions file. The tests that prove the rules behave. The logs that record what happened. The instructions for putting a new version live. The route back to the previous version. A named operator. A copy of source code without those operating assets gives the company little practical control.

WD4. A rented go to market system. A rented system keeps the decision layer inside a vendor product. The company configures it through fields, menus, prompts and workflow builders. The vendor owns the code, the product boundaries and the meter, meaning the unit the customer is billed on. Clay showed how quickly that meter can change when it introduced Actions in March 2026. One Action covers a data lookup, an AI task, a call to other software or a record pushed out to another tool [9]. The company retains its exported data and documented configuration when it leaves.

2.2 Position statements

V1. Building the decision layer is within reach of capable go to market teams. Private company builds already run signal scoring, inbound qualification, outbound, lifecycle, reporting and internal sales tools across eleven public cases [1]. The sample contains published wins and gives no failure rate. The failure rate for this class of build is unknown. AV1 gives the nearest public proxy. The eleven cases in this paper cannot supply a denominator of their own.

V2. Owning the code and its operating environment gives an AI native go to market team one stable control point. The claim applies most strongly to teams that run several tools, change models often and need one versioned rulebook. Definitions, rules, approvals and corrections stay legible when a provider changes.

V3. Building and owning can become more economical per motion over several years. The case applies to one measured motion at a company above the minimum engineering threshold. The comparison includes implementation, usage, integration maintenance, administration, operations and exit on both sides [2][3].

V4. The common core of repeated company builds should be open source. My builds suggest that most components recur across companies. Eleven public cases show similar patterns [1]. An open core would let each company build the part defined by its own stack, data, definitions and judgement.

V1 to V3 make a bounded case for building and owning the decision layer. V4 follows when repeated components support reuse across companies. Capability, operating fit and full lifecycle economics must pass for the first claim. Working code, maintainers, contribution rules and practical fork rights must pass for the second.

2.3 Elaboration

The company should own the interpreter that knows its vocabulary. A system of record can remain the source of truth. A specialist data service can enrich an account. A frontier model can handle a difficult judgement. The owned layer reads those services through adapters. An adapter is a small piece of code that translates between the company rulebook and one outside service. The rest of the system then does not change when the service does. The layer applies one rulebook and records every consequential decision. Swapping a vendor then means writing a new adapter and putting it through a production gate, meaning the set of checks a change must pass before it handles real volume. The company specific definitions remain in the same repository.

The decision layer and the interpreter stay in company hands. The tool layer is rented. Source, the Section 2.3 table below.

Figure 1. The ownership boundary

Layer	What it contains	Default
Decision layer	Data model, definitions, rules, orchestration, approvals and logs	Own
Interpreter	Versioned adapters that translate company rules into tool actions	Own
Tool layer	System of record, data services, delivery, ad platforms, models and compute	Rent

Swipe the table sideways →

Every action passes through a logged gate with a named owner and a route back to the previous state.

Most go to market motions contain repeatable parts and company specific parts. The list below reads the same way each time. The first half is the machinery that recurs everywhere. The second half is the judgement only the company can supply.

Scoring uses decay, caps and priorities. Decay lowers a score as a signal ages. Caps stop any one signal dominating.

ABM, meaning account based marketing, works one named list of target accounts. It uses account tiering and plays.

Lists use build and dedupe rules. Dedupe removes the same company or person appearing twice. The company sets the ICP, meaning the ideal customer profile.

Market intelligence uses monitoring and alerts.

Ads use budget maths, creative loops and pause rules.

Outreach uses research and drafting chains.

Sales uses handoff and next step logic.

SEO and GEO use page generation, quality checks and citation checks. SEO is search engine optimisation, the work of ranking in a search engine. GEO is generative engine optimisation, the same work aimed at being cited by an AI assistant.

Content uses briefs, drafting and review gates.

Localization uses market variants and checks.

Unit economics uses the model and cohort maths, meaning the arithmetic that follows one month's new customers over time to see what they cost and what they return.

Lifecycle uses triggers, journeys and holdouts. A holdout is a group deliberately left untouched so the effect of a change can be read.

Every motion needs gates, logs and an undo path. These components can be expressed as tested code and reviewed before they act. Connectors still have to match the real stack. Access rules have to name who can read, approve and write. Three conflicting definitions of qualified can make an otherwise capable agent act quickly on the wrong instruction.

My rough estimate from my own builds is about 80 percent common.

Across eleven company cases the building blocks were similar while proprietary internal data produced the differentiation [1]. The estimate remains a hypothesis because no component level denominator covers those eleven cases.

3. Position arguments

3.1 Why build and own

A1. Building became cheaper while rent kept its own meters

A1. Agentic development lowers the production cost of a decision layer while rented products retain pricing power. Uber combined rising use with a 52 percent fall in session cost from its June 2026 peak [5]. The inbound agent case reports roughly 60,000 dollars a year in engineering time and API cost against more than 2 million dollars saved [11]. Programmatic page generation, meaning pages assembled by code from a data source, adds two cases at the level of a single motion. One owned search motion produced 58,800 organic clicks in ten months. Another produced 179,000 clicks. These figures come from companies with strong engineering practice and from the author's first party search records.

Cheaper production leaves the cost of owning the code untouched. AV5 treats the evidence that generated code carries a higher review and security load.

Rented software continues to reprice. Salesforce announced an average list price increase of 6 percent for selected enterprise products from August 2025 [17]. Jason Lemkin reported that his Salesforce bill rose 80 percent year over year while his seat count fell, according to a secondary account [18]. Clay replaced its previous unit with Actions across several types of work while cutting marketplace data cost by 50 to 90 percent [9]. Each event has its own commercial logic. Together they show that a customer cannot hold the meter constant.

The cost base is also moving from software access toward completed work. Sequoia reports six dollars of services spending for each dollar of software spending [19]. Most of what a company spends on a function is therefore labour. That gives owned automation a larger possible target than licence savings alone. It also raises the standard for the economic case. A build has to replace a measured part of a motion, survive operation and preserve quality.

My own deployment records add one observation. My delivery files record approximately 350,000 euro in annual licences retired at one unicorn client. That second figure comes from the author's engagement records and has not been independently verified.

A2. Agents need one written rulebook

A2. A versioned rulebook gives agents a stable definition of the business. Human teams routinely reconcile conflicting meanings in conversation. The system of record may define a lead from form completion. A sales spreadsheet may define it from account research. Finance may wait for an invoice. An ABM team also needs one definition of a target account and one named approver for each play. An agent has to act on one of these meanings without asking. It needs one answer before it can act.

The eleven company cases report that every successful deployment solved a data problem first [1]. Scott Brinker frames the operating question around trust in the data, context and permissions on which an AI system acts [7]. That issue is larger than data cleanliness. It includes definitions, ownership, access and the right to approve a consequence.

A practical rulebook holds five things for each object it defines. The definition itself. The person who owns it. The field the value is read from. Who is allowed to write to it. The test that proves the rule behaves. Changes move through review and the repository records each dependency. A gate checks the definition before a model can score, contact or charge. Logs preserve the input, rule, output and approval.

One large rebuild in my records spent nine months cleaning a customer system before one agent shipped. A definitions process then took three weeks with a formal method after comparable work had taken four to six months by hand.

An owned rulebook can span several rented tools. A vendor workflow builder can still execute part of it. The company repository remains the reviewed source from which each tool receives its instructions.

A3. A motion uses a narrow slice of a general product

A3. A motion sized system can fit work that a broad vendor product serves only in part. The martech catalogue counted 15,505 products in 2026. It grew 0.79 percent while the number of new products entering fell 40 percent from the prior year [7]. Zylo found 36 percent of licences unused. Organisations above 10,000 employees added 21 applications each month [2]. Product breadth and stack growth can coexist with low use.

The cheaper remedy comes first. A company with 36 percent of its licences unused should cut those seats before it writes any code. S1 in Section 6 exists for exactly that count. The saving it produces needs no build at all. The argument here starts after that cut has been made.

Forrester expects global software as a service spending to grow from 318 billion dollars in 2025 to 576 billion dollars in 2029 [20]. The same analysis identifies vendors with low switching costs and workflows with weak enterprise embedding as vulnerable [20]. Many go to market point tools fit that description. Each motion should be tested against it.

The most cited replacement story offers a useful correction. Klarna moved work away from one large customer system while keeping other third party tools for customer management, human resources and collaboration [21]. A separate account found that part of the exit had started in 2022 before the later AI framing [22]. The case demonstrates selective substitution within a mixed stack.

The appropriate unit is one motion with one volume and one owner. An SEO and content motion can use a page generator, source library, quality checks and citation tests. Signal scoring can use a small set of fields, decay rules and gates. Reporting can use fixed sources, definitions and templates. A general suite and the customer system can still supply storage, identity, delivery and audit functions. The owned motion can call those utilities while keeping its logic visible.

A4. Ownership preserves an executable response to vendor change

A4. Source code in the company repository reduces configuration lock in and preserves a runnable fork after a vendor change. An API is the interface one piece of software uses to call another. A company that builds on someone else's API depends on its terms. Twitter announced the end of free API access on 1 February 2023 with access due to end eight days later [23]. Reddit pricing would have cost the Apollo client about 20 million dollars a year at its reported volume and the client closed in June 2023 [24]. Unity announced a runtime fee in September 2023, a charge on each installation of a game built with its engine. It removed the fee a year later after a developer revolt [25].

Infrastructure software shows the same risk around licences. HashiCorp moved core deployment tools to a business source licence in August 2023, a licence that publishes the source while barring competitors from selling it as a service [26]. Model access has its own clocks. OpenAI removed the Assistants API one year after formal notice and publishes minimum notice periods before it withdraws a model [8]. Ad platforms can change attribution methods and bidding rules. These events cover interfaces, pricing, licences and product boundaries. They establish several ways a dependency can change.

Owned decision code preserves an executable specification. A replacement adapter can preserve scores, gates and approval logic while tests compare services on the same inputs. A fork can run during shadow mode, a trial run beside the live system. This requires the source, deployment path, secrets and operational knowledge.

Vendors are answering by exposing their own interfaces. Several go to market vendors now publish APIs and agent facing endpoints so an owned layer can call them directly. That change supports the position here. The owned layer calls a rented service through an adapter. The company rulebook stays in the company repository either way. A published interface makes the adapter easier to write.

Ownership still leaves package, cloud, model, security and maintenance risk. Section 4 treats those costs directly. The narrower benefit is continuity of the company rulebook and a practical route to substitute one rented component.

A5. Mixed systems match the real operating boundary

A5. A heterogeneous system lets the company own its interpreter while specialist providers operate utilities. One company moved steady compute away from a public cloud after an annual bill of more than 3.2 million dollars. It bought about 700,000 dollars of hardware in 2024 and reported roughly 2 million dollars in annual savings [27]. The same approach would fail where demand is volatile or the operating team is absent. Workload shape decides the boundary.

Managed infrastructure already supports owned deployment. A container is a packaged application that carries everything it needs to run. Kubernetes is the software that runs many containers across many machines. Kubernetes reached 82 percent production use among container users in the 2025 CNCF survey announcement [28]. That population consists of organisations already using containers. Deployment onto a company cloud account can use a common enterprise operating layer where that practice exists.

Model economics support a mixed design. Open source models accounted for 11 percent of the calls enterprises made to language model services in the Menlo study [4]. Frontier capability therefore remains concentrated with closed providers. The decision layer can route a difficult task to that capability while using cheaper or pinned components elsewhere. A pinned component is one held at a fixed version so its behaviour does not change underneath the system. The rulebook remains stable when the model changes.

An open analytics company describes the same operating choice through software. It receives outside contributions and supports company controlled deployment while offering a managed service [29]. Its public website repository drew roughly 10 percent of pull requests from outside contributors [29]. That figure covers the website repository. It demonstrates participation.

The provider owns service operation. The company interpreter applies ad budget rules, lifecycle triggers and model routing through logged gates. The adapter defines the contract.

In one ABM case, the qualified account pool expanded from 400 accounts to all 3,000. Account based marketing managers carried fifty qualified accounts each. The company owned the target list, tiering rules and play approvals.

3.2 Why the common core should be open

A6. The same components have been built many times in private

A6. Repeated private builds establish demand for owned decision systems and recurring patterns across them. Brendan Short documented eleven growth companies that built go to market agents internally. His sample contains successful cases and no published failures [1]. One company reduced an inbound qualification motion from ten representatives to one in six weeks. It used 25 to 30 percent of one part time engineer's time, held conversion flat and reported a saving above 2 million dollars [10][11].

The wider economic precedent for shared code is strong. Harvard researchers estimate 8.8 trillion dollars of demand side value from widely used open source software [12]. Their summary says more than 95 percent of that value comes from work by 5 percent of programmers [12]. Without open source, firms would need to spend 3.5 times more on software [13][14]. Two limits belong beside that figure. It measures what existing open source would cost to replace across the whole economy, so it says nothing about whether a new project attracts contributors. The 95 and 5 finding argues for a small concentrated maintainer group, which is the founding group model this paper proposes.

Open code already owns important layers beneath go to market. In the 2025 Stack Overflow survey PostgreSQL was used by 58.2 percent of professional respondents and VS Code by 76.2 percent [15]. An adjacent open analytics company had 39,772 repository stars when read on 13 September 2026 [16]. A star is a bookmark a developer places on a public project, so it records attention. Adoption at this scale shows that companies accept open code in operational layers when maintainers, deployment practice and support exist. Fitness for revenue decisions needs its own production gate.

The evidence establishes repeated capability and recurring patterns. Whether those patterns can support a cross company open core remains a hypothesis for the founding group to test.

A7. Open collaboration can pool reusable patterns

A7. Open collaboration offers one mechanism for sharing decision patterns while each company keeps its data. Reusable contributions can include score shapes, decay functions, gate patterns, report templates, tests and connector adapters. The company reviews each change before release. Maintainers, meaning the small group with the right to accept a change into the shared project, review quality and compatibility. Automated checks remove secrets. Human review checks examples, logs and fixtures for private data.

The mechanism already works in adjacent settings. Ramp reports 300 to 400 salespeople building internal tools with 79 tools available through its internal protocol [30]. The second example is internal sharing within one company. It shows how local work can be promoted into a governed common set.

Contribution volume has become a cost to maintainers. Daniel Stenberg ended the curl bug bounty on 31 January 2026. He wrote that the confirmed rate on security submissions had fallen from above 15 percent in earlier years to below 5 percent from 2025. The volume of AI generated reports rose across the same period [63]. His conclusion is that paying for reports invited noise the project then had to clear by hand [63]. The lesson carries directly. Review duty is priced labour, so a shared core has to cap intake, require a reproducible test with each contribution and fund the review. A common core that attracts more submissions than its maintainers can read makes its members worse off.

The go to market cases identify proprietary data as a central differentiator [1]. Data rows, real customer examples, credentials, commercial thresholds and private corrections stay inside the company. Reusable patterns need synthetic fixtures and company approval.

The cross company procedure remains prospective. The same core can support content briefs and localization checks while each company keeps its voice, claims policy, market list and local rules. Contribution rights, review duties and removal tests must be explicit.

3.3 A public account of a built engine

Tim Rutten, chief marketing officer of Backbase, described a built go to market system on the Revenue Leadership Podcast in July 2026 [55]. Every figure in this subsection is his, as reported on that podcast. None of it has been independently verified for this paper.

Rutten reported a 35 person marketing organisation supporting a business with more than 350 million dollars in ARR, meaning annual recurring revenue. He described the internal system, which the company calls GTMOS, as "literally a system, an application that is running on our premises that runs the full operation front to back." He reported that deterministic logic runs almost 70 to 80 percent of the system. Deterministic means the same input always produces the same output, with no model judgement in between. He also reported that all GTMOS code is generated.

He reported one full time builder, with himself and two to three colleagues building during part of their time. He named one full time go to market engineer plus a director of RevOps and a director of content marketing who build part time. He reported that the director of RevOps rebuilt the reporting stack inside the system in three months.

He reported vendor decisions moving with the build. A tool costing 15,000 dollars a year was deprecated in the week before the interview. The company did not renew 6sense. He reported that within two months it had built its own signal engine. He said the scoring rules were visible and auditable. He said at least 100,000 dollars of further tooling would come out before the end of the year. On the products the company was pitched, he reported that each covered "one little vertical of the actual vision" and that "there's no moat for these guys."

He described the running motion as a weekly scan of 3,000 mid to large banks against the ideal customer profile, sorted into strong fit, moderate fit, cooling down and no fit, with campaigns aimed at clusters of about 30 accounts. He reported running that scan "every week for around $500 at max."

He set his own limits on the account. He reported the advantage window as "just 6 to 12 months, maybe 18" and said "the actual challenge is mostly the human hurdle, not the building anymore." The account is self reported by the company that built the system. No independent audit of these figures is available. Self reported figures in this area run high. METR found a median self reported gain of 1.4 to 2 times among 349 technical workers while its own randomised trial had measured a 19 percent slowdown [6][60].

4. Alternative views

AV1. The market has already chosen cloud software

Steelman. Cloud software won because managed operation, rapid product improvement and elastic capacity created more value than local control. Aggregate software as a service spending still grows and Forrester expects 576 billion dollars by 2029 [20]. A famous company replacement story kept several third party products and had started leaving its customer system before the later AI narrative [21][22]. The market has already tested ownership and chosen vendors. The largest public study of enterprise AI deployment points the same way. The MIT NANDA report reviewed more than 300 publicly disclosed AI initiatives, interviewed representatives of 52 organisations and surveyed 153 senior leaders between January and June 2025. It reports that only 5 percent of custom enterprise AI tools reach production. One of its four headline patterns is that external partnerships see twice the success rate of internal builds [56].

Answer. A8 changes the unit of analysis to one motion. The inbound case replaced one qualification motion in six weeks while conversion held flat [10]. A9 uses Forrester's own vulnerable class. Low switching costs and workflows with weak enterprise embedding describe many point tools inside a go to market stack [20]. The system of record and frontier capability can remain managed services while company rules move into owned code. The NANDA finding measures generative AI pilots across every business function. Most of those are assistants and copilots. It bounds the claim and leaves it untested. S5b exists because of that bound. A build that cannot pass a production gate should not carry volume.

Concession. Aggregate software as a service spending is growing. Frontier capability stays rented. The famous replacement case proves little for either side. The best public evidence available on build success rates runs against building. This paper's eleven cases cannot supply a denominator to answer it.

AV2. Building is the cheap part

Steelman. Operations, maintenance, enhancement and retirement commonly consume 60 to 80 percent of lifecycle cost [3]. Zapier describes self hosting, meaning running the software on machines the company controls, as trading vendor risk for operational risk [31]. METR found experienced developers 19 percent slower with early 2025 AI tools on mature codebases [6]. An open package, meaning a shared library the company depends on, can add security and staffing work that a vendor previously carried.

Answer. A10 counts maintenance on both sides. Rented systems require field mapping, integration repair, credit management, administration and renewal work [2][9]. A11 applies the capability threshold from Klotz. Company specific process automation can favour building once the operating capacity exists [3]. A12 uses managed company infrastructure. A container can run on a cloud account the company already operates and Kubernetes is common among container users [28]. The METR and Uber results describe different years, tools, codebases and operating methods [5][6]. Both can hold.

Concession. Operations remains the main cost. Companies below the capability threshold should buy. Regulated work can favour vendor certification. Open code can carry supply chain risk. The xz backdoor showed how one maintainer's access could expose a widely used package. The xz utility is a compression tool built into most Linux systems. A contributor who had earned maintainer trust inserted a hidden back door into it [32].

AV3. The author is selling this view

Steelman. The published criticism of Mensch said his prescription ended at products from the company he leads [39]. Two months later that company raised capital at a reported 24 billion dollar valuation to build infrastructure and rent capacity [40][41]. A position paper can turn a commercial interest into an argument dressed as research.

Answer. A15 makes the commercial structure inspectable. Source access, company controlled operation and a fork right reduce the author's future control. A16 rests the capability and vendor change evidence on other companies, researchers and public records [1][5][23].

Concession. The author's company benefits if readers accept the argument. The disclosure belongs beside the claim and the evidence must survive without the author's cases.

AV4. Open source can change its terms

Steelman. Several infrastructure vendors withdrew open terms after building adoption. Elastic later restored an open option [33]. Developer testimony collected after that reversal reported that trust had already moved to a fork [34]. Open publication alone guarantees little when a company controls future releases. An opinion piece in The New Stack argues from the run of relicensing events that open core has become hard to reconcile with keeping community trust and a commercial business at the same time [61]. I propose a four part test for relicensing exposure, offered as my own reading of those events and not as a published finding. One company holds most of the commits. No independent foundation governs the project. Recent venture funding raises the pressure to monetise. Outside contribution is thin. GTM OS meets all four today.

Answer. A13 points to the practical fork right. Redis restored an open licence option in May 2025 after an earlier restriction and a community fork [35]. OpenTofu reported 9.8 million downloads from GitHub releases in June 2025 [36]. Its repository had 30,171 stars when read in September 2026 [37]. The Valkey repository had 27,189 stars on the same date [38]. A14 compares exit assets. Source, tests and a deployment path allow a customer or community to keep a working branch. Star counts are the weakest part of that evidence, because what saved the forks was governance spread across several companies. The protections that matter are published terms, an exercisable fork right and maintainers who do not all work for one employer.

Concession. Open source alone guarantees nothing. Licence terms, practical fork rights, maintainers and company controlled operation carry the protection. Broken trust can survive a later reversal. A single company project that has not yet distributed its governance carries the documented relicensing risk, including this one.

AV5. Generated code raises the cost of owning it

Steelman. The production saving in A1 comes from code an agent wrote. That code tests badly. Veracode ran more than 100 large language models across Java, Python, C# and JavaScript. It found that 45 percent of code samples failed security tests by introducing an OWASP Top 10 vulnerability [57]. The OWASP Top 10 is the standard industry list of the ten most common web weaknesses. Its Spring 2026 update found syntax correctness at about 95 percent while the security pass rate stayed near 55 percent, which is where it stood two years earlier [58]. Maintainability moved the same way. GitClear analysed 623 million code changes from 2023 to 2026. Refactoring line moves, meaning code reorganised without changing what it does, were down 70 percent. Cross file function calls, a measure of reuse, were down 35 percent. Duplicated code blocks were up 81 percent, copy and paste inside a single commit up 41 percent and error masking constructs up 47 percent [59]. A cheaper build can therefore buy a more expensive decade.

Answer. WD3 already counts tests, logs, a deployment path and a named operator as part of ownership, so a repository without them was never an owned system in this paper's sense. S5b adds a security gate before any motion carries production volume, listed in Section 6. The 0.25 full time equivalent booked for operations in Table 1 is the price of that review load. Section 7 prints what happens when it doubles. The scope also matters. A go to market decision layer is a small internal service with a known and limited set of callers. The vulnerability classes that drive the Veracode figures come largely from public web applications, so they apply unevenly here. Unevenly still means present.

Concession. The review burden is real and it lands on one named person. That is why B4 exists. A company that generates code faster than it can review it should not build. The maintainability evidence also means the three year window in Section 7 may understate what year four costs.

The position keeps eight limits. Frontier models remain rented. The capability threshold is real. Operations remains the main cost. Generated code carries a review and security load that the operations owner has to absorb. Open publication needs enforceable terms and active maintenance. The author has an interest. Aggregate software as a service spending grows. One celebrated replacement case settles neither side.

5. Barriers to adoption

B1. Procurement is built for rent

Software budgets, security reviews and purchasing processes are designed around contracts and vendor accountability. Zylo's sample covered 40 million licences and 75 billion dollars of spend under management. Business units controlled 81 percent of the spend while information technology directly managed 15 percent [2]. A repository needs a budget owner, operator, review path and liability model. Many organisations have no purchasing category for that bundle. Vendors also face revenue and investor incentives that make opening a core product difficult.

The licence itself decides who can adopt. Some large companies refuse whole licence families outright. The AGPL is a licence that requires the source to be disclosed when software is offered over a network. Google bans AGPL code from its products and codebase. Installation on a company device requires explicit approval from its Open Source Programs Office [62]. Any open core aimed at large buyers therefore has to make the licence choice in front of a legal reviewer, because that choice determines which companies can use the code at all. This paper does not name a licence for the project described in its footnote.

B2. A shared core is still missing

The eleven published company cases built their own systems separately [1]. Their repeated components suggest a common core while their records show no shared go to market project joining them. GTM OS is the author's attempt to create one. It remains in closed alpha with a founding group of implementers. The repository has no public date. A credible core still needs working code, contribution rules, maintainers, security practice and evidence from live projects.

B3. The operating role is young

Most marketing organisations lack an engineer with repository ownership, review practice, an on call rota and a deprecation policy. Bloomberry found combined go to market engineer and revenue operations postings up 205 percent between January to September 2024 and the same period in 2025, across 1,000 analysed roles. Median pay among postings that disclosed a range was 127,500 dollars. The average requested experience was 4.11 years [42]. SQL and Python each appeared in 38 percent of postings [42]. Demand is rising from a small base. A company without a named operator remains below the capability threshold.

The title itself may not last. The work may be absorbed back into marketing and revenue operations as the tools improve. The building still has to happen either way, which is why S0 puts operators on the build.

B4. Operations discipline

An owned motion becomes an operated system on the day it leaves shadow mode. Klotz places 60 to 80 percent of lifecycle cost in operations [3]. The original build carries the smaller share. Section 7 books the owned engineer share inside that band. In my work, many marketing organisations have no named owner for this operating cost. Marketing operations and revenue operations are usually the closest existing homes. The duties are six. A deploy pipeline with review, meaning a fixed path by which a change reaches production after someone has read it. Monitoring with an alert path, so a failure reaches a person. Written data access rules. A secrets practice, secrets being the passwords and keys the system uses to reach other services. A route back to the previous version. A reporting cadence with a named signer. S5b names the owner, on call rota and rollback route as a gate before a motion carries production volume. The other duties have no home in most marketing organisations.

Owning the system also moves the paperwork. Once a company's own code touches customer records, the artefacts a customer security review asks for become the company's to produce. A data processing agreement covering what the system reads and where it stores it. An access review showing who can reach the data. A penetration test. Evidence of whatever certification the buyer requires. A vendor used to supply those. Rutten describes the compliance sign off, the security review and the enterprise authentication for his own build environment as the biggest hurdle of the programme [55]. A company that cannot staff that work sits below the threshold this paper sets, whatever its engineering capacity.

The public Backbase case describes the same order of work. Tim Rutten reports on the Revenue Leadership Podcast that he gave premium terminal seats, meaning paid coding assistant accounts, to his marketing leadership and his revenue operations team. People were building prototypes within two weeks [55]. He reports that individual terminal use was halted after two to four weeks because it did not scale. The team then moved to a shared environment. That environment fixed who could do what, kept the data consistent across users and controlled which systems could write back to the customer record [55]. He reports the build path as a commit to a repository, then security, build and quality checks, then a pull request review, then automatic deployment [55].. These are his figures as reported on the podcast and no independent verification is offered here.

A company that skips the operating practice keeps the vendor bill and adds an unmonitored system. In the author's practice the engine is kept next to the revenue team, with the company's own engineering standards applied to it. Review and deployment then stay routine. The motion does not sit in a central queue. That is the author's working estimate of the arrangement that survives. It is not offered as evidence.

6. A buy to build migration procedure

S0. Staff the build with the operators

Name the people who will build before the inventory starts. The decisions a motion encodes are the ones its operators already make by hand each week. Which accounts to work. Which signal counts. When a sequence stops. What a report is allowed to claim. Those rules live with the people who run demand generation, outreach and the pipeline. An engineering bench briefed on each of them inherits a translation step on every change. The eleven published cases report that each successful deployment solved a data problem first [1]. Definitions come from the operators.

Tim Rutten reports that his revenue operations director rebuilt the reporting stack inside the owned system in three months [55]. He states that go to market engineering as a standalone function becomes the bottleneck, because a group of five to ten engineers will not know the business [55]. He argues for a senior architect who owns and governs the architecture, with the people closest to the work doing the building [55]. These figures and judgements are his as reported on the podcast.

Ramp reports 300 to 400 salespeople building internal tools with 79 of them available through an internal protocol [30]. In the author's practice one engineer is paired with one marketer for two motions over a quarter, with the strategy work a small part of the pairing and the architecture the larger part. That pairing is the author's own working ratio. It is an estimate with no measured result behind it.

Acceptance requires a named architect and a named operations owner, each with a weekly time share signed by their manager. Each also signs a handover requirement before the build starts. The architecture, the definitions, the deployment path and the recovery route must be written down in the repository well enough for a second named person to run the system for a month without the first. S4 adds one builder from each chosen motion.

S1. Instrument the rented stack

Create one row for every rented workflow. Record paid seats, users active in the last 90 days, automations, sequences, scoring rules, reports, owner, last edit, monthly volume, renewal date and notice period. Export permitted audit logs. Cut the seats this count shows are unused before anything else happens, because that saving needs no build. Acceptance requires one row or an explicit zero for every tool.

S2. Write the definitions

Put lead, qualified, account, stage, customer, ideal customer profile, approver and spend limit in one versioned file. Record each owner, source field and allowed action. Resolve conflicts across the customer system, seller spreadsheets and finance. Every field read by an agent needs one definition and owner.

S3. Cluster and split the motions

Group the inventory into scoring, ABM, lists, market intelligence, ads, outreach, sales, SEO and GEO, content, localization, unit economics and lifecycle. Tag each workflow as common or company specific. Common components include decay, caps, drafting chains, page checks, budget maths, sync jobs, templates, gates and undo. Company components include connectors, definitions, approvers, tone and compliance. The output is the matrix in Figure 2.

Figure 2. Common and company specific components

Motion	Common component	Company specific component
Scoring	Decay, caps and priorities	Qualified definition
ABM	Account tiering and plays	Target account list and approvers
Lists	Build and dedupe rules	ICP
Market intelligence	Monitoring and alerts	Signals that matter
Ads	Budget maths, creative loops and pause rules	Spend limits and brand rules
Outreach	Research and drafting chains	Tone and contact permissions
Sales	Handoff and next step logic	Stages
SEO and GEO	Page generation, QA and citation checks	Source content and review rules
Content	Briefs, drafting and review gates	Voice and claims policy
Localization	Market variants and checks	Market list and local rules
Unit economics	Model and cohort maths	Costs and margins
Lifecycle	Triggers, journeys and holdouts	Events and offers

Swipe the table sideways →

S4. Choose two motions

Rank motions by renewal date, common share, data readiness and executive visibility. Choose one demand motion such as SEO and GEO or ads. Choose one account motion such as ABM or outreach. The output is a signed two motion brief. Acceptance requires a named owner, baseline, volume, success measure and renewal window for each motion.

S5. Build and run in shadow

Build common components from reviewed open code. Generate local connectors, definitions, gates and tone inside the company environment. Deploy on its cloud account and keep the system of record rented. Run one full cycle beside the current workflow with identical inputs. Shadow mode means the new system does the work without acting on it, so both systems run and only the old one touches a customer. Plan for one to three months of it. The company pays both columns during that time, which Section 7 prices. Compare quality, failure rate, latency, manual review and cost.

S5b. Pass the production gate

Set thresholds before shadow mode. Name the required accuracy, the acceptable failure rate, the longest acceptable delay between trigger and action, the cost ceiling and the largest share of output a human is willing to check by hand. Run one volume peak and one failure drill. Name the owner, on call rota and rollback route.

The gate also has a security half, because the code is generated and the evidence in AV5 says generated code fails security tests about half the time. Hold every password and key in a managed vault with each key scoped to one named use. Review the outside packages the system depends on. Keep an access log. Name a second person on call. Re-run the fixed test cases whenever a provider changes a model, since the same prompt can return different output after a silent version change. Add the operating items a buyer's security review will ask about. A stated recovery time target and recovery point target. A backup restore that has been tested, not only configured. A written record of where the data sits. Evidence that deletion requests are carried out. An inventory of every outside package the system depends on. A deadline for applying security patches. A named escalation path for an incident. Least privilege on every tool call the system can make. Keep the motion in shadow until every threshold passes. Sign the gate report.

S6. Retire and iterate

Retire the rented workflow at renewal after the production gate passes. Log every result and human correction. Remove client data, secrets and local thresholds from reusable contributions. Require company review before release. Return to S3 for the next motion. Acceptance requires one retired contract line and a working rollback package.

7. Economics

The economic decision uses one motion, one stated volume and three years of full cost. Rent includes contract or dated list price, usage, onboarding, integration maintenance, administration and exit. Ownership includes discovery, build, hosting, model and compute use, operations, engineer time and exit. Operations should carry 60 to 80 percent of lifecycle cost unless company records support a different share [3]. A proposal with missing inputs stays a proposal.

Table 1 prices signal scoring plus outbound for a ten seat team covering 5,000 accounts, across three years, in euro.

Table 1. Three year all in cost, one motion, one volume

Line	Rent, three years	Own, three years
Licences, list price	€60,400	€28,000
Onboarding or discovery	€1,300	€4,300
Build		€12,000
Hosting, compute only		€900
Usage and data, shared assumption	€112,100	€112,100
Integration maintenance	€32,400
Administration	€10,800
Operations, engineer time		€54,000
Exit	€8,000	€3,000
Total, public price floor	€225,000	€214,000

Swipe the table sideways →

Table 1 rests on the following inputs. Two vendors in this motion, Outreach and 6sense, publish no list price [48][49]. Their cost is missing from the rent column, so the rent column is a floor. Every other list price was read on 13 September 2026. Clay Growth costs 446 dollars a month [45]. HubSpot Sales Hub Professional costs 90 dollars per seat a month on annual billing, for ten seats, plus 1,500 dollars of onboarding [46]. That licence sits in both columns. WD2 keeps the system of record rented on the owned side too, so the owned company pays the same seats and the same onboarding. Zapier Team costs 599 dollars a month on annual billing at the 100,000 task tier [47]. Dollar amounts convert to euro at the European Central Bank rate of 11 September 2026, 1 euro to 1.1592 dollars [50].

The largest line, usage and data, is one shared assumption. It starts from a single self reported figure, about 500 dollars a week to scan 3,000 accounts, given by one company on a public podcast [55]. The paper scales that figure in a straight line to 5,000 accounts and holds it flat for 156 weeks. That gives 112,100 euro. The same amount sits in both columns because both systems buy the same data and model calls. A vendor can undercut that assumption by bundling data credits into a licence or by pricing off a network the company cannot rebuild. The sensitivity cases below test what happens when the parity fails.

Engineer time is priced at 6,000 euro a month. That is the midpoint of the author's own published rate for an embedded engineer, so it is a sell side price [51]. A company should replace it with its own loaded payroll cost, meaning salary plus employer taxes, benefits and overhead. The same rate prices labour on both sides of the table. Hosting is one small cloud server, an AWS t3.medium in the US East region at 0.0416 dollars an hour [52]. Both columns run the same 36 calendar months. The base table assumes no shadow months, so the rented workflow is retired on the day the owned one starts. The shadow case below charges the owned side its full monthly running cost during shadow, usage and data included, so those calls are counted twice for each shadow month.

Labour is counted in full time equivalents. One full time equivalent (FTE) is one person's whole working year, so 0.25 FTE is a quarter of one person's time. Discovery takes half an engineer month and the build takes two. The rent column carries 0.15 FTE for keeping integrations working and 0.05 FTE for administration. The own column carries 0.25 FTE for operations, meaning monitoring, fixes and reviews once the system is live, including the upkeep of the adapters that reach rented services. On those inputs 78 percent of the owned engineer cost is operations. That share falls out of the inputs above and sits inside the 60 to 80 percent range Klotz reports [3]. The operations line covers monitoring, fixes, dependency and access review, secret rotation, the deploy pipeline, the fixture re-runs after a provider change and the evidence for an access review. A penetration test, an external certification audit, legal review of a data processing agreement and any dedicated security headcount sit outside the table on both sides, since they are one-off or programme level costs. Opportunity cost is excluded on both sides. Totals use unrounded inputs and round to the nearest 1,000 euro.

Read the size of the result before reading the result. The two columns share a 112,100 euro usage line and a 28,000 euro licence line, both of which cancel. What remains is an 11,000 euro difference on a 225,000 euro rent total, under 5 percent of it. Every input in the table can move by more than that.

Read the base case monthly. Rent runs at about 5,993 euro a month once onboarding clears. Ownership carries 15,000 euro of discovery and build before anything runs, then about 5,418 euro a month. Ownership therefore starts 15,000 euro behind, the head start rent never has to pay. The 575 euro monthly difference clears that head start in 26.1 months. At the public price floor, break even lands in month twenty-seven. Every missing rental cost moves it earlier. Exit sits outside that calculation, since both land at term end.

Six cases test the inputs that decide the answer. Each holds everything else at the base.

The engineer rate. The rate prices labour on both sides, 7.2 rate months on the rent side against 11.5 on the own side. One rate month is one month of one engineer at the stated rate. A higher rate therefore costs ownership more than it costs rent. The two totals meet when the rate reaches about 8,500 euro a month. At 7,000 euro, the top of the author's published band, rent is 232,000 euro, ownership is 226,000 euro and break even lands in month thirty-four.

Rent side maintenance. The 0.15 FTE booked for keeping rented integrations working is an author assumption with no measurement behind it. Reduce it from 0.15 FTE to 0.10 FTE and rent falls to 214,000 euro, the two columns meet and no break even lands inside three years. Remove it entirely and rent falls to 193,000 euro against 214,000 euro for ownership, so renting is cheaper across the whole term.

Data parity. The owned side can absorb about 10 percent more usage and data cost than the rent side before the totals meet. At 25 percent more, ownership costs 242,000 euro, above rent, with no break even.

Build overrun. Double discovery and build to 30,000 euro and ownership costs 229,000 euro, above rent, with no break even. A rebuild inside the term adds one more build line, giving 226,000 euro, also above rent.

Shadow mode. Every month the new system runs beside the old one adds about 5,418 euro to the head start, which delays break even by about 9.4 months.

Combined adverse. Take three of these together, double build, three shadow months and rent integration maintenance reduced from 0.15 FTE to 0.10 FTE. Rent costs 214,000 euro. Ownership costs 246,000 euro. No break even lands inside the three year term and ownership ends the term 32,000 euro worse off.

The earlier sensitivity on the engineer share moves with the corrected base. Half the engineer share gives 187,000 euro and break even in month twelve. Double gives 268,000 euro, above rent, with no break even inside three years. Operations at 60 percent gives 183,000 euro and month eleven. Operations at 80 percent gives 220,000 euro, with break even at 36.7 months, outside the term.

The corrected base breaks even in month twenty-seven on an 11,000 euro advantage. A single adverse assumption is enough to remove it. Every case above except the two that cut the engineer share ends with no break even inside three years. The table does not settle the decision. It sets out the inputs a company has to replace with its own numbers. Section 6 carries the decision through a shadow run and a production gate that measure them.

Table 2 records a complete public result. One inbound qualification build reduced ten representative workflows to one in six weeks with flat conversion [10].

Table 2. Reported three year case for one inbound qualification motion

Line	Prior motion, three years	Owned motion, three years
Reported annual value	More than 2 million dollars saved	60,000 dollars in engineering and API cost
Three year run rate	More than 6 million dollars	About 180,000 dollars
Operations share	Included in prior labour baseline	Unreported. The source reports engineering hours and API usage only. Maintenance, monitoring and governance are not quantified.
Exit cost	Unreported	Unreported
Break even and three times return		Month one and about 1.1 months, assuming even accrual and the full 60,000 dollars paid upfront

Swipe the table sideways →

The 2 million dollar figure is reported by the builder with no audited baseline behind it. The source does not say what became of the nine representatives whose workflow the build replaced. At half and at double the reported owned cost, break even stays inside two months on the same assumption. The source reports a 32 times return [11]. This case supports economic possibility within one motion.

Table 3 prices one site at 200 pages a month.

Table 3. Illustrative three year list price comparison for an SEO and GEO motion, before internal content labour on either side

Line	Rent, three years	Own, three years
SEO suite, list price	€15,100
Content production, list price	€310,600
Onboarding or discovery		€3,000
Build		€12,000
Hosting, compute only		€900
Model spend, stated assumption		€1,800
Administration	€10,800
Operations, engineer time		€54,000
Exit	€8,000	€3,000
Total, published list price	€344,000	€75,000

Swipe the table sideways →

Content labour is excluded on both sides, so neither column carries the internal writing, editing and subject matter time a real programme needs. Quality is also not held equal across the two columns. One buys human written posts from an agency and the other generates pages from company source material. The company's own quality gate decides whether those two outputs are comparable at all. Where they are not, this table does not apply.

Ahrefs Advanced lists at 419 euro a month [53]. The HOTH lists its 500 to 5,000 word Blogger product at 50 dollars per post [54]. Both prices were read on 14 September 2026. The rent case buys 200 posts a month for 36 months and converts dollars at 1 euro to 1.1592 dollars [50]. It carries the same 0.05 full time equivalent for administration. Owned page generation and quality checks use reviewed open code. Engineer time is 6,000 euro a month. Discovery is half a month, build is two months and operations use the same 0.25 full time equivalent as Table 1. Compute follows Table 1. Model spend assumes 0.25 euro per page across generation and checking. That is 50 euro a month. Totals use unrounded inputs and round to the nearest 1,000 euro.

The result depends on the listed content product fitting each page, capacity for 200 monthly orders and no volume discount. The company should replace those assumptions with a quote and its own quality gate. Base break even is 1.9 months, so ownership costs less during month two. Half the engineer share gives 48,000 euro and 1.8 months. Double gives 129,000 euro and 2.4 months. The break even point then falls in month three.

8. Call for discussion

This position is offered for inspection. I will publish substantive responses including disagreement, following the correspondence device used by the model position paper [43]. Readers can inspect a working demo and the founding group for GTM OS today. A future repository will include the licence, architecture, one runnable motion, deployment model and security model. No release date is offered.

Which claim has the strongest flaw, V1 on capability, V2 on operating fit, V3 on economics or V4 on the open common core? A reply with evidence will be more useful than agreement.

8.1 Two directions I am testing

Both items in this subsection are my own view. Neither is evidence for the position stated above.

I believe the useful next object is a simulator of a company's own go to market. I am building one beside that work. It holds the motions, their inputs, their gates and their recorded rates as one model. A team can then watch how a change in one motion moves the others before that change touches the live pipeline. The intended value is visibility of interactions that a per channel report hides. A scoring change that starves outreach. A budget rule that moves the qualified pool. A gate that relocates a bottleneck one step downstream. I claim no result for this work. It has not been measured against live outcomes. I offer it as a direction only.

I also believe that a small specialised model, trained on one company's definitions, rules and recorded outcomes, may serve the narrow repeated decisions in an owned engine. Model size is usually described by parameter count, the number of adjustable values inside the model. The general case has been argued in the model paper [44]. Belcak and colleagues hold that small language models are sufficiently capable, more suitable and more economical for the specialised repetitive calls that agentic systems make [44]. They report that serving a seven billion parameter model costs 10 to 30 times less than serving a model of 70 to 175 billion parameters, measured across response delay, energy and compute [44]. They also report that finetuning at that size takes a few graphics processor hours [44]. The known limit is that a tuned small model performs well on the kind of material it was trained on and degrades outside it. That matters in a go to market layer which meets new accounts, new markets and new language every week. The go to market application is my hypothesis with no test behind it. Any test would use a corpus cleared for retention, exclude customer data without explicit approval and define access, deletion and rollback before training. The governance point is the part I hold most firmly. A model whose training material is the company's own rulebook can be reviewed, versioned and rolled back on the same terms as the code around it.

Appendix A. Why these definitions hold

The definitions aim to survive vendor and model changes. The decision layer is defined by the business consequence it controls. The tool layer is defined by storage or execution. Both remain stable when a product name changes.

They are practical because a RevOps lead can classify a stack from workflows and ownership. Each rule either lives in a company repository or inside a vendor product. Each action either follows a company gate or a vendor configuration.

They align with the position because ownership matters most where accumulated company knowledge directs a consequence. The model paper uses the same discipline of working definitions, position statements, alternative views, barriers and a conversion procedure [44]. The structure is useful here while its language and subject remain separate.

Appendix B. Case studies

C1. A direct to consumer nutrition brand in Europe

An owned search motion produced 58,800 organic clicks from 4.35 million impressions in ten months. The click rate was 1.4 percent on those inputs. One assistant cited the brand first in three countries. The clicks and impressions come from a first party search console export in the author's records. No conversion, revenue or counterfactual figure is printed for this case, so it measures reach only. The same pipeline later ran for a European experiences brand and a B2B services company in APAC.

C2. A European experiences brand doing over 200 million in revenue

The site had held position four for eighteen months. The owned search motion then produced 179,000 clicks from 10.9 million impressions across thirteen months. Google AI Overview, ChatGPT and Perplexity named the brand. The clicks and impressions come from a first party search console export in the author's records. No conversion, revenue or counterfactual figure is printed for this case either. The pipeline matched C1 while the vertical, source content and review rules changed.

C3. A European streaming service

An offer and localisation task fell from two to three hours per market to two minutes across 22 markets. The timing and market count are author reported from the delivery records for that engagement. Connector details, approval rules and local language checks remained company specific.

C4. A European banking software company

This engagement covered two motions. The author estimates that about 80 percent of each new build reused prior components, measured across the components built for those two motions in the author's records. No component level denominator was recorded. Outcome figures from this engagement are held in the author's delivery files and are not printed here.

Selected anonymised results

Each result below was reported in a public interview or recorded in the author's delivery files. Companies are not named.

1. One account plan fell from weeks to 15 minutes.
2. Quarterly business review preparation fell from two to three weeks to an automated workflow.
3. Each dollar of sales and marketing spend returned eighty cents of new annual recurring revenue.
4. One marketer covered ten times as many accounts.
5. Qualified pipeline rose 85 percent year over year and average deal size rose 60 percent.
6. Account based marketing managers carried fifty accounts each.