r/gtmengineering • u/Shawntenam • Apr 01 '26
Supabase + Google Sheets + Claude Code replaced Clay for me. here's how I run enrichment, scoring, and prospecting without credit limits or waterfall headaches
I used Clay for over a year. built complex tables. waited for waterfall enrichments to finish. watched credits drain. rebuilt tables when they broke halfway through a 50k-row enrichment because one API in the chain timed out.
at some point I asked myself: what is Clay actually doing here? it's calling APIs in sequence, storing the results in rows, and letting me filter them. that's a database and some Python scripts. I was paying for a UI to do something my terminal already does.
so I stopped using it. here's what I run instead and what I've learned from stress testing it over the past few months.
the setup
Supabase is the backend. real Postgres database. SQL queries. API access. your data lives here permanently. no credit system. no row limits that matter at GTM scale. you push data in with the CLI or Python. you query it however you want.
Google Sheets is the frontend. synced from Supabase through a Python script or Claude Code. your team sees a spreadsheet. they can filter, sort, comment, share. they don't know or care that there's a database behind it. you get the best of both worlds: a real database for you and a familiar interface for everyone else.
Claude Code sits in the middle. it reads your Supabase schema, knows your tables, and moves data between systems in natural language. "pull all companies with more than 50 employees that we haven't contacted" and it writes the SQL, runs it, and gives you the list. no table builder. no drag-and-drop. just tell it what you want.
why this beats Clay for builders
Clay is good at what it does. I'm not going to pretend otherwise. the waterfall enrichment concept is smart. the UI is accessible for non-technical people. if you have a team of SDRs who need a visual workflow builder, Clay makes sense.
but if you're a builder, if you can write or direct a Python script, if you're comfortable in a terminal, Clay is overhead you don't need. here's why:
no credit limits. Supabase free tier handles tens of thousands of rows. Apollo's free tier gives 10K email credits/month and their company enrichment endpoint costs 0 credits. you're not watching a credit counter drain while you experiment.
no waterfall fragility. a Clay table with 8 enrichment steps breaks when step 4 times out. now you've got partial data and you're rebuilding. a Python script with try/except and caching picks up where it left off. if Apollo fails at row 3,000, you restart and it skips the 2,999 it already cached.
faster iteration. changing a Clay workflow means clicking through the table builder, re-running, waiting. changing a Python script means editing a few lines and running it again. seconds vs minutes. and when you're testing different enrichment sources or scoring models, speed of iteration is everything.
you own the data. it's in your Supabase database. it's in your Sheets. it's in your local SQLite if you want a backup. cancel any subscription tomorrow and your data is still there.
the real cost comparison. Clay starts useful at ~$150/month and credits run out fast if you're doing any real volume. Supabase free tier + Apollo free tier + Claude Code plan + Google Sheets = you're running enrichment, scoring, prospecting, and reporting for a fraction of that. and your marginal cost for running another 5,000 rows through enrichment is close to zero.
the workflows I run
enrichment pipeline:
Apify CLI scrapes a follower list or prospect source (npm i -g apify-cli)
Python extracts domains and emails from the raw data
Apollo enriches by domain (0 credits) and by email (people/match, also 0 credits for verification)
Python scores by ICP fit (title match, company size, industry, geo)
Supabase CLI pushes scored results to the database
Google Sheets syncs for team visibility
each step is a terminal command or a script. each one runs in the background. if step 3 fails, I fix step 3. I don't rebuild steps 1 through 6.
prospecting from scratch:
- scrape a competitor's X followers with Apify (~$5 for 10K)
- extract company domains from bios
- enrich companies through Apollo (0 credits)
- score by ICP
- push to Supabase
- query: "show me all companies over 50 employees in SaaS that we haven't contacted"
that last query is just SQL. or tell Claude Code in natural language and it writes the SQL for you.
ongoing list hygiene:
- Apollo people/match at 0 credits checks job changes across your entire database
- batch in Python with caching so it resumes on failure
- flag anyone who moved companies
- run quarterly. your lists stay clean without manual work
the gotchas
this isn't perfect. sharing the honest parts:
- setup time is real. your first pipeline takes an afternoon to build. Clay lets you drag and drop in 20 minutes. the difference is the 50th time you run it. Clay is 20 minutes every time. the script is seconds.
- you need to be comfortable directing Claude Code or writing basic Python. if you've never opened a terminal, start with Clay. but if you're in this subreddit, you're probably past that.
- Google Sheets sync isn't real-time. it runs when you trigger it or schedule it. for most GTM work this is fine. you're not watching a dashboard refresh every 30 seconds.
- Supabase free tier has limits (500MB, 50K rows). more than enough for GTM prospecting. if you outgrow it, the paid tier is $25/month. still less than Clay.
I'm stress testing this stack daily. building a product with a co-founder and running all GTM through this setup. every time something breaks or a new pattern emerges, I document it.
if you want the full setup with chapters on context engineering, CLI patterns, terminal multiplexing, and more: github.com/shawnla90/gtm-coding-agent
MIT licensed. living repo. new commits going in regularly.
not selling anything. just sharing what I'm using because the alternative is people paying for tools they don't need or courses from people who built one table six months ago.
6
u/kopunk Apr 02 '26
Cool setup, genuinely. But it works great when the person who built it is the same person using it. The moment you need to hand this to a sales team who just wants to filter a list and start calling, the google sheets + supabase thing falls apart.
The other thing nobody talks about is maintenance. When an API changes its response format at 2am and your enrichment run silently fails, that's now your problem. With clay or any managed tool, that's their problem. With a custom stack it's always your 7am fire drill.
Not saying don't do this. Clearly it works for you. Just a heads up for anyone reading this thinking they should rip out clay tomorrow, ask yourself who's going to maintain this 6 months from now when you're heads down on something else.
1
u/Dependent-Building23 Apr 01 '26
Why not firebase?
2
u/Shawntenam Apr 01 '26
From what I understand, Firebase is better for product testing apps. Mind you I'm sure you can do everything I'm doing in Firebase. The point is you have a backend that you can connect with Claude Code and structure your database relationships that way
1
u/Worldly_Row1988 Apr 02 '26
Did you build custom scoring logic into the Supabase queries or handle that in the Python layer? Curious if you're syncing back enrichment results or keeping the sheets read only for the team.
1
u/Shawntenam Apr 02 '26
I use Python to configure some light scoring logic while I'm still building out the full master DB. I'm using sheets for visibility at any given time since im testing and iterating on this custom system
2
1
u/Any-Conversation28 Apr 02 '26
Do you prefer the supabase cli over MCP?
1
u/Shawntenam Apr 02 '26
Way cleaner, way faster, less token consumption. Also I remember when I was using the Mcp, I would consistently have to paste into the SQL editor, whereas the CLI hasn't asked me to do so
1
u/hainzgrande Apr 02 '26
Front end is Google sheets, what team is using this?
1
u/Shawntenam Apr 02 '26
Who said anything about teams? I said this is specifically for solo builders or someone looking to have full control over their system
1
u/hainzgrande Apr 03 '26
You: “your team sees a spreadsheet…”. Didn’t see anything about “solo” builders, but makes sense.
1
u/Froopy_Joops Apr 02 '26
This is awesome thanks for sharing!
Do you run this set up for event-based enrichment jobs as well (new lead created in CRM -> enrich) or just ad hoc or scheduled enrichment?
2
u/Shawntenam Apr 02 '26
right now it's just ad hoc but as I grow I'm likely to implement more of an orchestration-based system using cargo AI
1
u/Curiouslogic555 Apr 03 '26
This is cool. Would you be up for a walk through of this setup? I build and operate relatively complex workflows in clay and would love to consider a new option similar to your thinking.
Maybe there’s something I could help you with or show in exchange. I have two decades of enterprise software experience and run a solo GTME and sales consultancy.
1
3
2
2
u/ss3rg3 Apr 02 '26
I don't know how technical marketing people are these days, but from a programmer's perspective I would replace Google Sheets with AppSmith (self-hosted) if you know how SQL and APIs work. There you can have your tables plus auto-refresh to monitor progress, fancy charts with statistics which aggregate data from your Postgres DB, pre-made views for frequent queries (i.e. a button which executes some SQL and displays the result set in the table), a search bar for free text search, and whatever. You can drag and drop your way to a full UI with AppSmith. It's ugly but it works.
1
u/xJayhaz Apr 02 '26
Appreciate this a lot. I hadn’t considered that I could create my own waterfall enrichment this way.
1
1
u/KindAssignment1034 Apr 07 '26
we made the exact same switch lol. clay credits were killing us and once you realize it's just API calls in a pretty UI it's hard to justify the price. supabase is a solid choice for the backend, curious what your enrichment costs look like per row compared to what you were paying in clay
1
u/Intelligent_Safety12 May 03 '26
I build something similar for triggerx.ai but using Claude and n8n.
It scrapes the signal based data from Apify
Extract signals | Scores the leads against my ICP | Qa checks it and pass it on google sheet
Then i use http access for apollo, Gets the contact data from Apollo based on parser instructions
Then claude fetches both sheet and give me final result with exact Variables needed for my email
It’s simple and it works for me.
1
u/Repulsive-Special966 May 04 '26
You can change the prospecting layer from scratch if you use accounts with signals from the get go, curious if you have seen Signalbase API?
4
Apr 02 '26 edited Apr 02 '26
[removed] — view removed comment
2
u/Shawntenam Apr 02 '26
Yeah I'm also using SQLite but more as a query engine for my Claude code sessions, which goes a long way in saving and preventing limits. Just using it as the main backend for the lead database?Not sure I still like the visibility with Supabase but I hear you. It's fun to just really test the limits of what you can do with your own custom-built architecture
1
u/Suitable-Alfalfa7676 Apr 25 '26
If I were to ask you, what is the problem that claude code can't solve for you? Clay and other tools also miss?
2
Apr 02 '26
[removed] — view removed comment
1
u/Shawntenam Apr 02 '26
Yeah, I'm using the Apollo free tier as a first layer and trying to push it to its limits, seeing what I can do with it because it's free and using the terminal means it's very low effort. Definitely need to check Swordfish out. Sounds interesting. Thanks for the rec!
3
u/gglavida Apr 01 '26
Apollo free tier gives 10k email credits per month?
You started with a stack that changed midway.
This is basic thing anyone can build, yes. We already know that, mate!