Our GTM stack is built on three core tools: Clay for data, Windmill for automation and Claude for the work that used to need a person. Every other tool plugs into those three, so the logic lives in one place and anyone on the team can see the whole system.
Most stacks we see are the other way round: a dozen tools, logic spread thin across all of them, and nobody who can see how it fits together. A lead gets scored in one tool, filtered in another, routed by a third, and when something breaks nobody knows where to look. The fix is not fewer tools for its own sake. It is deciding where the logic lives.
What you need
- A list of every GTM tool you pay for today
- For each one, the job it does and who owns it
- An honest note of which tools hold business logic: scoring, routing, filtering, copy rules
How we tier the stack
We sort tools by how central they are to the system, not by how good they are. A low tier says nothing about quality. It means the tool does one specific job and could be swapped without rebuilding anything.
| Tier | Tools | What it means |
|---|---|---|
| Core | Clay, Windmill | Logic lives here. Replacing one means rebuilding. |
| Daily driver | Claude, Apollo.io, Slack | Used every day, deeply connected to the core |
| Solid, situational | Apify, Findymail, Serper.dev, Prospeo | Reliable for specific data jobs |
| Nice to have | Instantly.ai, HeyReach, HubSpot, Attio | Execution and records, fed by the core |
| Specific plays | Zapier, Ocean.io, Cognism | Pulled in when a particular play needs them |
| On trial | Fibbler, RB2B, Seam | Being tested against a real use case |
Claude sits in the daily-driver row by usage, but in practice it is the third pillar: it does the research, classification and drafting that would otherwise need a person.
What each tool does in the system
The core
- Clay is where account and contact data comes together. Lists are built, enriched and scored here, and this is where enrichment waterfalls run.
- Windmill runs the automation: scheduled jobs, webhooks, and scripts that move data between tools. Because it runs real code, logic can be versioned and reviewed like any other code.
- Claude handles the judgement-heavy steps: researching accounts, classifying replies, drafting copy and preparing briefs. See Claude Code for GTM for how we give it context.
Data and research
- Apollo.io for broad contact and company search.
- Findymail and Prospeo for finding and verifying emails, often in sequence.
- Apify for scraping public data that no database covers.
- Serper.dev for search results inside automated research.
- Ocean.io for lookalike companies and Cognism for phone data, when a play calls for them.
Execution and records
- Instantly.ai for cold email and HeyReach for LinkedIn outreach.
- HubSpot and Attio as CRMs, depending on the setup.
- Slack as the place alerts, replies and summaries land.
- Zapier for quick connections that do not justify code.
On trial
- Fibbler, RB2B and Seam are being tested. Each has to earn a place by doing a job nothing else in the stack does.
Why logic belongs in the core
Execution tools change. Sequencers, data vendors and CRMs come and go as prices and coverage shift. If your scoring rules live inside a sequencer, switching sequencers means rebuilding the rules. If they live in the core, switching is a matter of pointing the output somewhere new.
That is why most of our tools sit in the lower tiers. They receive data and actions from the core and send results back. They are plumbing, and plumbing should be easy to replace.
Before adding a tool, ask where its logic will live. If the answer is "inside the new tool", either it becomes a core tool, or the logic should move somewhere you already control.
How to choose a lean stack
- Map the jobs first. List the jobs your GTM motion needs: TAM mapping, enrichment, outreach, meetings, CRM, reporting, proposals, content. Tools come after jobs.
- Pick one tool per job. Two tools doing the same job means two places for data to disagree. Keep a second only where it clearly adds coverage, such as a second email finder in a waterfall.
- Require an API. Every tool needs one. Without it, the tool cannot plug into your core and someone ends up moving data by hand.
- Pick your core. Choose the few tools that will hold the logic: usually one for data, one for automation and one for AI work. Build in those.
- Let the rest be plumbing. Every other tool should be swappable. Keep a short note of what each one does and what it connects to.
- Trial with a real use case. New tools go on trial against a specific job and a clear test. If they do not beat what you have, they leave.
Signs your stack needs work
- Nobody can draw how a lead moves from list to meeting
- The same rule, such as an exclusion list, is maintained in more than one tool
- Data is exported to CSV and re-imported by hand every week
- A tool is paid for but nobody can say which job it does
A stack built this way is also ready for agents. When every tool has an API and the logic is in one place, Claude and scheduled jobs can drive much of the routine work. For what to connect, see MCP servers for GTM.
Want a second pair of eyes on your stack? Book a GTM Engine Review.
Frequently asked
Should I use the same tools as you?
Not necessarily. The principle carries over better than the tool list: a small core that holds the logic, one tool per job, and an API on everything. Pick the core tools your team can actually build in.
Why is our CRM not in the core?
In our setup the CRM is the record of what happened, not the place where decisions are made. Scoring and routing happen in the core and the CRM receives the results. Some teams run it differently, and that works if the logic still lives in one place.
How often should I review the stack?
Whenever a tool renews, and at least once or twice a year. Ask what job it does, whether anything else already does it, and whether it still earns its tier.