The GTM engineering stack: one tool per layer, and why the vendor matters least
The short answer
Four layers, ideally one tool each: a signal source that detects change, an enrichment layer that turns a domain into a usable picture, an orchestration layer holding the routing and qualification logic, and an action layer that executes outreach and generates assets. Every tool you pay for should map to exactly one layer.
Most GTM stacks are not stacks. They are twelve tools acquired over three years, four of which overlap, two of which nobody has logged into since the person who bought them left.
The tool count is not the problem. The absence of an architecture is. A stack with four tools that map to four layers works. A stack with twelve tools that map to nothing produces exactly the failure mode it was bought to fix: nobody can say which system owns a given decision.
Start from the layers, not the category
A working go-to-market engine has four layers, and every tool you own should occupy exactly one of them.
| Layer | Job | What belongs here |
|---|---|---|
| 1. Signal | Detect that something changed | Visitor identification, intent feeds, job posting monitors, product usage events |
| 2. Enrichment | Turn a domain into a picture | Firmographic and contact providers, tech stack data, unstructured research |
| 3. Orchestration | Decide who gets what, when | Workflow tooling, routing, scoring logic, the rules themselves |
| 4. Action | Do the thing | Sequencers, asset generation, CRM writes |
The architecture is covered fully in GTM engineering. What follows is what actually goes in each box, and where money gets wasted.
The diagnostic question: point at each tool you pay for and name its layer. Tools you cannot place are candidates for cancellation. Tools sharing a layer with another tool are either a deliberate waterfall or an accident, and you should know which.
Layer 1: Signal
Buy first: website visitor identification. Your own traffic is the highest-precision signal available and the cheapest paid tier in the category.
Buy second, maybe: review site intent, if your category has real presence on comparison platforms.
Buy last, or never: co-op content intent networks. Broad, expensive, structurally imprecise. Useful as a prioritisation tiebreaker, poor as a trigger. The full comparison is in intent data providers compared.
Where money is wasted here: buying third-party intent before instrumenting first-party events. Most teams that believe they need better intent data already have excellent intent data that is not connected to anything.
Layer 2: Enrichment
One primary, at least one fallback. Single-sourcing silently loses 20 to 40% of records, and nothing flags it. The mechanics and the ordering rules are in waterfall enrichment.
Add an unstructured pass. Structured APIs give you headcount and tech stack. They do not tell you how a company describes its own category or what recently changed in its positioning. That reading is what separates informed outreach from merely accurate outreach, and it became affordable per-account rather than per-campaign.
Where money is wasted here: paying for premium tiers on fields you never use. Audit which enriched fields actually appear in a message or a routing rule. It is usually a handful, and you are frequently paying for a hundred.
Layer 3: Orchestration
The thinnest layer in most stacks, because it is the least tool-shaped.
You can buy a signal feed. You can buy enrichment. You cannot buy your own qualification logic, and that is the layer that determines whether the other three produce anything.
What lives here: which signal combinations constitute a real trigger, which tier an account lands in, who the entry point is, what happens on conflicting signals, and when an account exits rather than gets chased.
Where money is wasted here: buying a heavier orchestration platform to compensate for logic nobody has written down. The tool is not the missing piece. The decisions are.
Write the logic in a document before you build it in a tool. Teams that do this routinely discover their rules contain two or three outright contradictions that had never been visible because the logic lived in three people's heads.
Layer 4: Action
Sequencing across email, LinkedIn and calls, coordinated across the buying committee rather than aimed at one contact.
Asset generation, producing account-specific material rather than campaign-level material. This is where cheap research pays off most visibly.
CRM writes, so the rest of the company can see what happened.
Where money is wasted here: over-investing in this layer because it is the visible one. If reply rates are poor, the cause is almost never the sequencer or the copy. It is a bad account list or thin enrichment producing a message that is well-written and irrelevant. Teams replace the action tool, see no change, and conclude the channel is dead.
The property that matters more than any vendor
Graceful degradation.
Every provider you depend on will be unavailable at some point. Credits run out, rate limits hit, APIs change, services go down.
If your engine stops entirely when one source is unavailable, you have built something that fails on a Tuesday for reasons nobody can diagnose. If each source is wrapped independently, marked unavailable, and the run continues with what remains, you have built something that survives ordinary operational reality.
When evaluating tools, ask what happens when the thing upstream of them fails. Most demos never cover it. It matters more than any feature comparison in the deck.
What a working stack costs
Rough annual ranges for a mid-market B2B SaaS team, to calibrate expectations:
| Layer | Realistic spend |
|---|---|
| Signal | $5k to $40k |
| Enrichment | $10k to $50k |
| Orchestration | $5k to $30k |
| Action | $15k to $60k |
$35k to $180k a year, and the spread is mostly driven by how much third-party intent you buy, which is also the layer with the weakest return.
A startup running 25 accounts can operate credibly at the bottom of that range or below it. The stack should follow the motion, never lead it.
Build order
1. Instrument first-party signals. Free. Most teams find the best data was already there.
2. One enrichment provider, and measure coverage rate.
3. Write the orchestration logic down. In a document. No tool required.
4. Add a fallback enrichment source once you know where the gaps are.
5. Automate what you have already proven manually.
6. Add third-party intent only if first-party volume is genuinely too thin.
Automating an unvalidated motion produces failure at scale, delivered faster. Every step above exists to make sure the thing you automate is worth automating. When build capacity rather than strategy becomes the bottleneck, that is the moment to consider hiring a GTM engineer.
Frequently asked questions
What is in a GTM engineering stack?
Four layers, ideally one tool each: a signal source that detects change, an enrichment layer that turns a domain into a usable picture, an orchestration layer holding the routing and qualification logic, and an action layer that executes outreach and generates assets. Every tool you pay for should map to exactly one layer.
How much does a GTM stack cost?
Roughly $35k to $180k a year for a mid-market B2B SaaS team. Most of the variance comes from how much third-party intent data is purchased, which is also the component with the weakest measurable return. Small teams can run a credible stack well below that range.
What should you buy first for outbound?
Instrument first-party signals, which costs nothing, then add one enrichment provider and measure its coverage rate. Buy third-party intent last, and only if first-party signal volume is genuinely insufficient to fill a pipeline.
Do you need Clay or a similar orchestration tool?
Only once you have written your qualification and routing logic down and validated it manually. Orchestration tools execute logic well but do not supply it. Buying a heavier platform to compensate for undefined logic is the most common way money is wasted in this layer.
What is the most important property when choosing GTM tools?
Graceful degradation: what happens when a dependency is rate-limited, out of credits or down. Each source should be wrapped independently so the run continues with whatever is available. This matters more than any feature comparison and is almost never covered in a demo.
---
*NomiOS is RZLT's GTM and ABM engine. Point it at a target and get back finished, branded work built on a real read of that company.*
[See how NomiOS works →](https://nomios.rzlt.io)
Questions
Frequently asked
- What is in a GTM engineering stack?
- Four layers, ideally one tool each: a signal source that detects change, an enrichment layer that turns a domain into a usable picture, an orchestration layer holding the routing and qualification logic, and an action layer that executes outreach and generates assets. Every tool you pay for should map to exactly one layer.
- How much does a GTM stack cost?
- Roughly $35k to $180k a year for a mid-market B2B SaaS team. Most of the variance comes from how much third-party intent data is purchased, which is also the component with the weakest measurable return. Small teams can run a credible stack well below that range.
- What should you buy first for outbound?
- Instrument first-party signals, which costs nothing, then add one enrichment provider and measure its coverage rate. Buy third-party intent last, and only if first-party signal volume is genuinely insufficient to fill a pipeline.
- Do you need Clay or a similar orchestration tool?
- Only once you have written your qualification and routing logic down and validated it manually. Orchestration tools execute logic well but do not supply it. Buying a heavier platform to compensate for undefined logic is the most common way money is wasted in this layer.
- What is the most important property when choosing GTM tools?
- Graceful degradation: what happens when a dependency is rate-limited, out of credits or down. Each source should be wrapped independently so the run continues with whatever is available. This matters more than any feature comparison and is almost never covered in a demo.
