As fast as the blast radius allows. Revenue teams should be able to move quickly, and that is one of the biggest reasons GTM engineering exists. GTM stands for go-to-market: the systems and processes a company uses to find prospects, convert them into customers, and grow revenue. But a system that scores accounts on an internal dashboard is not the same as one that updates your CRM or emails two thousand prospects, and the difference has nothing to do with how technical the person building it is.
If someone wants to build a scoring model, automate account research, enrich a prospect list, or test a new workflow, they should not have to wait months for engineering resources. In many cases, the ability to build and change these systems quickly is exactly what makes them valuable.
The important question is not whether revenue teams should build software. They already are, and often they should. The better question is: how much damage could this system cause if it quietly does the wrong thing?
What is a GTM engineer?
A GTM engineer applies software engineering, automation, data, and increasingly AI to the systems a company uses to find prospects, convert opportunities, and grow revenue. That can include enrichment pipelines, lead scoring, account research agents, CRM automation, automated outreach, routing logic, and internal revenue tools.
GTM engineers typically work close to revenue, RevOps, growth, sales, or marketing. That proximity matters because the person building the workflow often understands the business logic directly. They know why a lead qualifies, why a rep needs a particular field, or why one account should be prioritized over another.
For experimental work, that direct connection between the person who understands the revenue problem and the person building the solution can be a major advantage.
Why does building outside engineering usually work?
Most GTM work does not need a heavyweight software development process. Forcing every experiment through a traditional engineering backlog can defeat the purpose.
Go-to-market work is naturally experimental. A messaging strategy works or it does not. A qualification rule performs better or it does not. A new data source improves account selection or it does not. You often know the answer within days or weeks.
In that environment, something that is directionally correct today may be much more valuable than something perfect delivered three months from now.
The problem starts when a system that was built like an experiment quietly becomes part of the company's operating infrastructure.
When does an experiment become production?
This transition rarely happens all at once.
Someone creates an automation that enriches 100 accounts for a campaign. It works, so the team uses it for 500 accounts. Eventually every new lead starts flowing through it. Six months later, multiple people depend on the workflow and nobody thinks of it as an experiment anymore.
Nothing necessarily changed about the code. What changed was the blast radius.
The same thing happens with AI agents, spreadsheets, scripts, low-code applications, CRM workflows, and third-party automation platforms. A prototype can slowly become production software without anyone deciding that it should now be treated like production software. That is usually where risk starts accumulating.
Where does GTM engineering quietly break?
The failures worth worrying about are often not dramatic. They are ordinary problems that stay hidden long enough to become expensive.
A CRM update nobody can undo. An enrichment process writes the wrong value into thousands of records. The problem does not surface until months later, when a report no longer reconciles, the original values are gone, and nobody can tell exactly what changed.
AI output that nobody sampled first. An agent researches a prospect and confidently states something that is not true. The output sounds plausible enough to pass a quick glance and ends up in hundreds of outbound messages. The biggest cost is not the emails. It is the impression left with the prospects receiving them.
A workflow that works at 200 records but fails at 2,000. As usage grows, the workflow starts creating duplicates or incomplete updates. There is no monitoring because nobody originally thought of it as a production system. The first warning might be a salesperson asking why the same prospect was contacted twice.
None of these failures require carelessness. They happen because the workflow grew beyond the environment it was originally designed for.
How do you decide which systems need more rigor?
The answer should not depend on who built the system or how complicated the code looks. It should depend on blast radius.
Ask four questions:
- Does it write to a system of record?
- Does it communicate directly with customers or prospects?
- Does it process personal or sensitive information?
- Could it do the wrong thing for weeks without anyone noticing?
That last question matters because systems that fail loudly usually get fixed quickly. The ones worth protecting are the ones that can fail quietly.
| What the system does | If it is wrong | What it probably needs |
|---|---|---|
| Scores or ranks accounts internally | Someone works a weaker list | Occasional review |
| Enriches records for analysis | Reports may be inaccurate | Sample checks |
| Writes to a system of record | Bad data spreads | History and reversibility |
| Messages customers or prospects | Reputation damage | Sampling, limits, kill switch |
| Processes personal data at scale | Operational or compliance exposure | Access controls and audit trail |
What does the middle ground look like?
The answer is not to send everything back to software engineering. That would recreate the problem GTM engineering was designed to solve.
The better approach is lightweight engineering discipline based on risk. For higher-impact systems, that might mean reviewing a sample of AI-generated output before sending at volume, limiting how many records one execution can modify, recording what changed, making important updates reversible, monitoring unusual activity, and providing a way to stop a running process quickly.
It also means deciding who owns the workflow once other people depend on it. Someone should know what the system does, what it depends on, what happens when it fails, and how to disable it.
None of that requires a six-month architecture project. The hard part is recognizing when the system has crossed the line where those controls are justified.
Where does this become a compliance question?
Usually sooner than companies expect.
Prospect and customer systems frequently contain personal data. Enrichment tools add more of it, and AI agents may continuously collect and process additional information.
Once that happens, questions appear that go beyond software engineering: Where did the data come from? How long should it be retained? Who should have access? Could you determine what information you have about a specific person? Those questions are easier to answer when the system was designed with them in mind and much harder to retrofit later.
When is this the wrong concern?
If the blast radius is genuinely small, leave the system alone. Adding process to a workflow that touches internal data and nothing else costs real speed for no benefit.
It is also the wrong concern when the underlying go-to-market motion is not working. Automation makes an effective process faster and an ineffective one more expensive. If the messaging is not landing or the qualification criteria are wrong, no amount of engineering discipline improves the outcome, and fixing the process is the cheaper answer.
What should an operations leader take from this?
Your revenue team is going to build software. AI agents, automation platforms, APIs, and low-code tools are making that easier every year. That is mostly a good thing.
The answer is not to slow those teams down. It is to recognize when something that started as an experiment has become important enough that the company needs to protect it.
Start by looking at the systems your revenue organization already depends on and ask what each one could quietly break. For many of them, the answer will be "not much." Leave those alone. But you will probably find a few systems that touch more customers, data, and operational processes than anyone realized. Those are the ones worth treating differently.
Speed and engineering discipline are not opposites. The right approach is to apply each where the business risk actually requires it.
Red Tree Labs helps established companies turn ideas and manual processes into production software and AI solutions. We build from specifications rather than guesses, which is how modern tooling delivers speed without costing you reliability.