Quick answer
A lean 2026 GTM stack needs four jobs covered, not seven subscriptions: data, sending, calling and recording. The tools filling those jobs are mostly interchangeable. What is not interchangeable is whether every tool connects to one control plane through a CLI or MCP, so the whole system runs off a written instruction instead of seven open tabs.
I plan the tool stack for every outbound account before I touch targeting or copy, because a bloated stack quietly caps everything downstream of it. One of Hlib Storchak's recent videos walks through the exact seven tools he runs his own outbound through, and the part worth reading closely isn't the tool list, it's the reason the list works at all.
Why most B2B stacks run ten tools to do four jobs
Take a look at the tool list in most B2B companies and the pattern repeats: one subscription for email, a second for LinkedIn, then a scraper, a finder and a validator that all overlap, with the same list exported and re-uploaded between them. Four tools end up doing roughly one job, and a chunk of every day goes into switching tabs rather than selling anything.
A lean core looks different. Email and LinkedIn sit in one platform instead of two. One database handles data, with two fallbacks behind it. One dialer connects straight into the CRM. One CRM records everything. And one layer sits on top of all of it and makes the pieces act like a single system rather than five separate ones.
The four layers an outbound stack actually needs
However many logos end up in the stack, they all fall into four jobs. The first is data: building lead lists reliable enough to target through cold email, LinkedIn and the phone. The second is sending: a reliable way to get email and LinkedIn messages out on a schedule. The third is calling: reaching people by phone where that channel is already part of the motion. The fourth, and the one most builds treat as an afterthought, is recording: a CRM that's actually easy enough for a rep to use daily, so the other three layers don't just generate activity nobody tracks.
| Tool | Layer | What it does | Cut first, or keep |
|---|---|---|---|
| Salesforge | Sending | Email and LinkedIn campaigns from one workspace, with a CLI and MCP server | Keep, it's the core |
| Prospeo | Data | Primary database: company lists, people lists, email and phone enrichment | Keep, it's the core |
| Leadsforge | Data | Fallback data source for when the primary database misses a contact | Keep as a backup |
| Icypeas | Data | Verifies an email before it ever reaches a mailbox | Keep, it protects deliverability |
| Trellus | Calling | Parallel dialer with live AI coaching, runs as a browser extension on top of the CRM | Only if calling is already part of the motion |
| Attio | Recording | CRM that syncs with everything above it | Keep, it's the core |
| Clay | Optional | Enrichment and workflow building, useful below real volume | First to cut once volume is high |
| Apify | Optional | Scraping job boards, tech stacks and other public sources | Keep for occasional use |
Prospeo plus two fallbacks: a data layer that does not run dry
Prospeo builds both company level lists and the people inside those companies, then enriches for email and phone on top of the list. The part of the video worth noting is how the list gets built in the first place: you describe the audience in plain English, something like Nordic SaaS companies under 500 employees, and the tool sets the filters and returns a clean company list to enrich from there.
No single database is complete, though, so the stack carries two fallbacks. Leadsforge fills in when the primary database misses a contact's email or phone. Icypeas runs a second validation pass on anything uncertain before it goes anywhere near a sending platform. He says in the video that running every address through that validation step is what keeps his bounce rate under 1%, which is the kind of detail that matters more than which database sits at the top of the stack.
Tip. A single database without a fallback isn't a data layer, it's a single point of failure. Budget for a validator before a second sending tool, a bounced email costs you deliverability on every message after it, not just the one that bounced.
Why run email and LinkedIn from one platform instead of two?
Running email and LinkedIn as separate tools means syncing lead lists by hand every time a segment needs to move from one channel to the other: say 500 people got emailed, 50 replied, and the other 450 now need a LinkedIn touch instead. Salesforge keeps both channels in one workspace, so that handoff is a filter, not an export and re-upload.
In every account I run, email and LinkedIn sit inside one sequence rather than two separate campaigns, for the same reason: splitting the channels splits the data and the timing that makes a sequence work as one plan. Salesforge also ships a CLI and an MCP server, so campaigns get built, launched and filtered without opening the browser UI at all, which matters once sending volume climbs into the hundreds of thousands of messages a month. I've written guest articles for Salesforge's blog, and no tool named in this article pays me to mention it.
Do you need a separate dialer for cold calling?
Cold calling isn't a channel I run for clients, my own work is cold email and LinkedIn. But plenty of outbound motions already include a calling team, and for those, the video's answer for that layer is Trellus. It runs as a browser extension on top of whatever CRM or data tool you're already in, works as a parallel dialer, and listens to calls to offer live coaching if you give it context on what the call is for. If calling isn't already part of your motion, skip this layer rather than add it for its own sake.
Attio as the recording layer, not an afterthought
Attio is the CRM in this stack, and the reason it gets called out as more than a line item is that it syncs with the sending tool, the data tools and the dialer, so a rep sees context pulled in automatically rather than typing it in after the fact. None of that matters, though, if the handoff from a reply to a rep is slow. I've argued separately that the single biggest fix in a GTM system is how fast a rep answers an interested reply, and a CRM that doesn't alert someone the moment a reply lands undoes most of the value of the three layers feeding it.
The layer most people skip: one control plane instead of seven tabs
Here's the part of the video worth watching twice. Every tool in this stack, Salesforge, Prospeo, Leadsforge, Icypeas and Apify, exposes a CLI or an MCP server, which means an AI agent can call each one directly instead of a person clicking through five separate dashboards. Claude sits on top as the control plane: it builds the lead list by pulling from the data tools, pushes it into Salesforge once it's validated, routes non-repliers into a calling list, and syncs results back into the CRM, all from one written instruction.
This is the least obvious claim in the whole video, and it's the one that actually explains why a seven tool stack feels lean instead of bloated. The tools themselves are mostly interchangeable, swap Prospeo for a competitor and the system barely notices. What makes the stack act like one system rather than seven is that every piece of it can be called programmatically, so one person with a well documented set of instructions can run what used to take a team clicking through separate logins. This overlaps with what gets described elsewhere as GTM engineering, a title I don't carry myself since I work as a GTM consultant, though the underlying skill of stitching tools together through an AI agent is the same one. If you want the hour by hour and dollar by dollar case for building a piece like this yourself instead of buying it ready made, I broke that down in what each layer actually costs to build and keep running.
What one prompt across the whole stack actually looks like
The clearest example comes at the very end of the video. Picture a single written instruction: build a list of Finnish SaaS companies under 500 employees, find the senior decision makers including salespeople, find and verify their emails, upload the list into a multi-channel template inside the sending platform, wait three days before the first touch, route anyone who hasn't replied into a separate list for calling, and sync everyone else into the CRM, with responders going into a longer nurture track. That's the whole motion, end to end, from one instruction instead of five separate logins and a spreadsheet passed between them.
Where Clay still fits, and where I'd cut it first
Clay is a fair starting point if you're still building out your first outreach function, it covers a lot of ground without needing five separate subscriptions underneath it. The video's own take is that it slows down once volume gets real, with a single table topping out somewhere around 50,000 contacts, which stops being workable once a target market runs into the millions. At agency level sending, that combination of a ceiling on table size and a price per row adds up to costing more than it returns. I've gone deeper on the wider tool market separately if a full tier by tier breakdown of GTM tools is useful alongside this one.
Apify: the optional tool for scraping jobs and tech stacks
Apify is the seventh tool, and it's the one used occasionally rather than daily. It's a scraping platform, and the two use cases called out in the video are pulling job postings off Indeed to spot companies that are hiring, and pulling the technology a company runs off BuiltWith. Like the rest of the data layer, it connects through an agent rather than through a UI someone has to babysit, which is why it earns a place in the stack without earning a daily login.
What I'd cut first on a smaller budget
If I had to drop tools to cut cost, Clay goes first past a certain point, since the system above already covers enrichment and list building without it once volume justifies the switch. Apify is next, since it's occasional rather than core. Trellus only belongs in the stack if calling is already part of the motion, so it's not a cut so much as a layer that shouldn't be there in the first place for an email and LinkedIn only operation. What I would not cut is the fallback and validation pair, Leadsforge and Icypeas, because losing them doesn't save much money and it does cost deliverability, which is the one thing the rest of the stack depends on.
Key takeaways
- A lean stack covers four jobs, data, sending, calling and recording, not seven subscriptions doing overlapping work.
- Tool choice matters less than whether every tool connects through a CLI or MCP so an agent can call it directly.
- A fallback data source and an email validator protect deliverability more than a flashier primary database does.
- Clay works fine below real volume, the video's own account is that it slows down and costs more than it returns once a table nears its ceiling.
- A calling layer only belongs in the stack if calling is already part of the motion being run.
- One written instruction through a control plane replaces the manual work of switching between seven separate logins.
FAQ
Do I need all seven of these tools to run a lean GTM stack?
No. The seven tools cover four jobs: data, sending, calling and recording. Start with one tool per job, a data source, a combined email and LinkedIn sender, and a CRM, then add a fallback data source, a validator or a dialer once volume or the motion actually calls for it.
What's the minimum stack to start cold email and LinkedIn outbound?
One platform that runs email and LinkedIn as a single sequence, one data source for building and enriching lists, and one CRM to record replies. Everything past that, a fallback database, a validator, a dialer, gets added once the gaps in that minimum setup actually show up.
Is Clay still worth using in 2026?
If you're early and still building out your first outreach function, yes. Once volume gets real, a single table runs into a size ceiling and the per row cost adds up, which is when a smaller set of connected point tools tends to cost less and run faster.
Do I need a CRM if I'm only running outbound?
Yes. A reply with no record of which sequence it came from or who owns the follow-up gets wasted regardless of how good the outbound that generated it was. Even a lightweight CRM keeps the recording layer intact.
Can I run a stack like this without writing any code?
Yes, every tool in it works fine from its own interface. The CLI and MCP connections only matter if you want a single AI agent orchestrating the whole system from one instruction, which is an efficiency layer on top, not a requirement to get started.