Clay Is the Old Way of Building GTM. Here's What Replaced It.

Clay was built in an era when building software was hard. There's an old startup adage: find what people are doing in Excel and build an app for it. For GTM teams, the answer was always lists — prospect lists, enrichment lists, scoring lists. Clay saw that and built an app on top of it. Spreadsheet UI, waterfall enrichment, drag-and-drop tables, credit-based pricing. It worked because writing code was expensive and slow, and most sales teams didn't have engineering resources to connect APIs themselves.

Then AI made building apps easy. And suddenly, the thing Clay was charging $150–$400/month for — calling APIs in sequence and storing results in rows — became something any decent GTM engineer could spin up in an afternoon with Claude Code.

The Shift Nobody's Talking About

The conversation in GTM communities has moved past "which enrichment platform should I use?" to "why am I using a platform at all?"

A recent thread in r/gtmengineering laid it out clearly. An operator shared how they replaced Clay entirely with Supabase, Google Sheets, and Claude Code. Real Postgres database. Python or TypeScript with Claude Code handling the heavy lifting. No credit limits. No waterfall fragility where step 4 timing out means rebuilding steps 1 through 6.

The reaction wasn't shock — it was recognition. Because builders have been quietly doing this for months.

Why the Old Model Breaks Down

Clay's architecture makes a specific bet: that GTM teams need a visual UI to orchestrate API calls. That bet made sense in 2022. It doesn't in 2026.

Here's what changed:

AI coding tools eliminated the complexity gap. The whole reason Clay existed was that connecting Apollo/LeadIQ/Lusha/ZoomInfo to your CRM to a scoring model required engineering resources most sales teams didn't have. Now, Claude Code or Cursor can scaffold that pipeline from a natural language prompt. The abstraction layer Clay provided is no longer scarce.

Credit-based pricing punishes experimentation. Every time you test a new enrichment source, tweak a scoring model, or re-run a segment, you're burning credits. A script with caching costs you nothing to re-run. When speed of iteration determines who finds the right ICP fit first, paying per experiment is a structural disadvantage.

Waterfall enrichment is fragile by design. Chain eight API calls in sequence and you've created eight points of failure. When one times out, you get partial data and a rebuild. A script with try/except and local caching picks up where it left off. It's not more elegant — it's just more reliable.

The Stack That's Emerging

What builders are converging on isn't one tool. It's a pattern:

A real database — SQLite, Supabase, or Postgres. Your data lives permanently. No row limits that matter at GTM scale. No vendor lock-in. Cancel any subscription tomorrow and your data is still there.

A scripting layer — Python or TypeScript with Claude Code for enrichment, scoring, and data movement. Each step is independent. If step 3 fails, you fix step 3. You don't rebuild the pipeline.

A team-facing frontend — Google Sheets synced from the database. Your SDRs see a spreadsheet. They filter, sort, comment. They don't know there's a database behind it. You get engineering-grade infrastructure with a familiar interface for everyone else.

API-first data providers — This is where most DIY stacks still fall short, and it's the piece that matters most.

The Part Nobody's Solving Well: Phone Data

Here's the blind spot in every "I replaced Clay" post. They focus on the orchestration layer — how to move data between systems — and treat the data itself as interchangeable. It's not.

You can build the cleanest pipeline in the world, but if the phone numbers coming out of it are wrong, your reps are dialing disconnected lines. The enrichment layer only matters if the data it returns is accurate.

Most data providers optimize for coverage — how many records they can return. Few optimize for what actually matters to an outbound team: can a rep dial this number and reach the right person?

That means direct dials, not switchboards. Verified numbers, not database records that haven't been checked in months. Real-time validation that catches numbers flagged as spam by carriers before your rep wastes a dial on them.

This is what we're building at Million Phones. Our API is designed for exactly this use case — plug it into whatever stack you're running (Clay, custom scripts, doesn't matter) and get phone numbers that actually connect.

Because the best GTM stack in the world doesn't fix bad input data.

What This Means for Your Stack

If you're a builder comfortable in a terminal, you don't need Clay. You need:

1. A database you own
2. Scripts that handle enrichment with proper error handling and caching
3. A phone data provider with an API you can call programmatically — one that prioritizes accuracy over volume
4. A frontend your team already knows how to use

The total cost of this stack — Supabase free tier, free enrichment endpoints from Apollo, a phone data API like millionphones.com, Google Sheets — runs a fraction of what Clay charges. And your marginal cost for running another 5,000 rows through enrichment is close to zero.

The teams that win at outbound in 2026 aren't the ones with the fanciest workflow builder. They're the ones with the cleanest data going into every conversation.

When Clay Still Makes Sense

Credit where it's due: if you have a team of non-technical SDRs who need a visual workflow builder, Clay works. The drag-and-drop interface is accessible. The waterfall concept is smart. Not every team has a GTM engineer.

But if you're reading this, you're probably past that. And if you're still paying for a UI to do what your terminal already does, it's worth asking what you're actually paying for.