Why Clay Is Both the Most Loved and Most Hated GTM Tool
84% of GTM Engineers use Clay. It tops both the "most exciting" and "most frustrating" tool lists. That paradox tells you everything about the state of the GTM stack.
The Dominance Is Unprecedented
84% of 228 surveyed GTM Engineers use Clay. At agencies, adoption hits 96%. No other tool in B2B SaaS comes close to this penetration within its primary user base. Salesforce has roughly 23% of the CRM market. Slack has about 30% of workplace messaging. Clay owns 84% of GTM Engineering.
This dominance happened in under three years. Clay launched in 2023. By mid-2025, it was the center of gravity for the entire profession. The GTM Engineer role and Clay are so intertwined that many job postings list "Clay expertise" as the top requirement, above Python, above SQL, above any other tool.
When a single tool captures 84% of a professional function, everything else orbits around it. Clay is the platform that GTM Engineers build on. It's the first tool they learn, the one they spend the most time in, and the one they have the strongest opinions about.
What People Love
Flexibility. Clay's table-based interface lets you build almost any data enrichment workflow. Pull company data from one API, enrich contacts from another, score them with a custom formula, and push qualified leads to your CRM. All in one workspace, all configurable without writing code (though code nodes exist for advanced users).
Integration depth. Clay connects to 100+ data providers and tools. Instead of managing separate subscriptions to ZoomInfo, Apollo, Clearbit, and Lusha, you can access all of their data through Clay's integration layer. This consolidation saves money and reduces the tool management burden that eats up GTM Engineer hours.
Community and ecosystem. Clay has built one of the most active communities in B2B SaaS. The Clay Bootcamp, run by Nathan Lippi, has trained thousands of practitioners. Templates, tutorials, and use-case libraries are everywhere. For a new GTM Engineer, the learning resources are abundant. No other GTM tool has this depth of community support.
Speed of iteration. Clay ships product updates weekly. New integrations, new AI features, new table functions. The product evolves at a pace that keeps power users engaged. When you're inside the Clay ecosystem, you feel like the tool is always getting better.
What People Hate
Complexity. The same flexibility that makes Clay powerful makes it overwhelming. A new user opening Clay for the first time faces a blank table and infinite possibilities. There's no guided workflow. No "click here to build your first outbound campaign." The learning curve is steep, and many practitioners report spending 2-4 weeks before they feel productive.
Pricing. Clay's credit-based pricing model frustrates users at scale. Each enrichment action, each API call, each AI generation step consumes credits. For GTM Engineers processing thousands of records per day, the credit costs add up fast. A workflow that looks affordable at 100 records becomes expensive at 10,000. This creates a constant tension between building comprehensive workflows and managing costs.
Fragility. Complex Clay workflows break. An upstream API changes their response format, and your entire table chain fails. A rate limit gets hit mid-run, and you have partial results mixed with errors. A formula references a column that was renamed, and downstream calculations return nulls. Every Clay power user has stories of debugging a broken table at midnight because a critical pipeline stopped running.
Lock-in. Once you've built your workflows in Clay, migrating to another platform is a significant undertaking. Your tables, formulas, integrations, and automation logic all live within Clay's proprietary system. There's no "export my workflow" button. This lock-in gives Clay pricing power and reduces competitive pressure, which is exactly what frustrates users who feel trapped.
The Agency Dependency
96% adoption at agencies creates a specific problem: agencies can't offer non-Clay alternatives. When a client asks for GTM Engineering support, the agency delivers Clay-based workflows. There is no practical alternative at this adoption level.
This dependency means agency pricing is partially a function of Clay pricing. When Clay raises credit costs, agencies pass the increase to clients (or absorb it, which cuts margins). Agency business models are built on top of Clay's pricing model, which means they're exposed to a platform risk they can't control.
Some agencies have responded by building proprietary tools that sit on top of Clay, adding monitoring, reporting, and optimization layers that create differentiation. Others have started exploring Python-based alternatives for specific workflows, particularly data transformation and enrichment tasks where Clay credits are expensive but Python scripts are free to run. This diversification is a small but growing trend.
The Competition (or Lack Thereof)
Unify sits at 8.8% adoption. That's the second-place competitor. No other enrichment/orchestration platform cracks the top 10 in the survey. The competitive gap between Clay and everyone else is enormous.
Why hasn't a competitor emerged? Three reasons. First, Clay's community creates a network effect. New GTM Engineers learn Clay because that's what everyone teaches, which increases Clay's dominance, which makes it harder for alternatives to gain traction. Second, Clay's integration depth is hard to replicate. Building connections to 100+ data providers requires years of API partnerships. Third, the switching cost is high. Migrating existing workflows to a new platform takes weeks of rebuilding, during which pipeline generation drops to zero. Few companies will accept that disruption.
This competitive vacuum is unlikely to last forever. The history of B2B SaaS shows that dominant platforms eventually face viable alternatives. Salesforce's CRM dominance spawned HubSpot, Pipedrive, Close, and Attio. Marketo's marketing automation dominance spawned HubSpot (again), Pardot, and ActiveCampaign. Clay's dominance will eventually spawn competitors that target specific pain points: simpler pricing, easier onboarding, or better reliability.
When that happens, the GTM Engineers who can work across multiple platforms will be more valuable than those locked into Clay. The coding premium applies here too: Python scripts are platform-independent in a way that Clay tables are not.
What This Means for You
If you're a GTM Engineer, learn Clay. The 84% adoption rate makes it a career requirement. But don't stop there. Build Python skills that let you replicate Clay's core functionality independently. Write API integration scripts that don't depend on Clay's credit system. Learn SQL for direct data access that bypasses Clay's enrichment layer when it's cheaper or faster.
If you're a hiring manager, "Clay expert" is a minimum requirement, not a differentiator. Every serious candidate knows Clay. The differentiating question is: what can they do when Clay breaks, when Clay is too expensive for the use case, or when Clay doesn't support the integration they need? The candidates who answer "I'd write a Python script" are the ones worth the premium.
If you're building a competitor to Clay, focus on one thing Clay does badly: pricing transparency, onboarding simplicity, or workflow reliability. Don't try to match Clay's breadth. Win on depth in one category, build a community around it, and expand from there. The 84% adoption number looks unbeatable, but it's also a sign of a market with unmet needs. People don't simultaneously love and hate a product unless it's the only option for something they need.
The Credit Economy Problem
Clay's credit-based pricing deserves its own section because it's the single biggest frustration among power users. Every action in Clay consumes credits: enrichment lookups, AI generations, waterfall steps, API calls. A single table row can consume 5-20 credits depending on the workflow complexity. At scale, this creates a perverse dynamic where the most valuable use cases (high-volume enrichment, multi-step scoring, comprehensive data augmentation) are also the most expensive.
GTM Engineers respond to credit pressure in predictable ways. They build hybrid workflows that do expensive operations in Python scripts (free) and use Clay only for operations where it has genuine advantages (UI-based data exploration, manual review steps, provider waterfalls). This approach reduces Clay costs by 40-60% for some practitioners. But it also fragments the workflow across multiple systems, increasing maintenance burden and debugging complexity.
The credit model also creates budget unpredictability. A GTM Engineer might design a workflow in Clay that uses 500 credits per run. If the team decides to run it against a 20,000-record list instead of the planned 5,000, the credit cost quadruples. Explaining a surprise $2,000 Clay bill to a CFO who approved $500/month is a career conversation nobody wants to have.
Other tools in the GTM stack use subscription-based pricing (unlimited usage within a tier) or per-seat pricing. Clay's credit model is closer to AWS billing: granular, scalable, and completely opaque until the invoice arrives. Whether this pricing model survives long-term depends on whether the value Clay delivers justifies the anxiety it creates. For now, it's the primary source of hate in the love/hate equation.
For the full tool analysis, see the Clay deep dive. For what frustrates GTM Engineers most, see tool frustrations. For the most exciting tool list, see most exciting tools.
Source: State of GTM Engineering Report 2026 (n=228). Salary data combines survey responses from 228 GTM Engineers across 32 countries with analysis of 3,342 job postings.