Claude Code in the Wild: Build Systems Your Team Can Run Without You

Guest Speaker

About Bharat

Bharat Devana

Clay Bootcamp Mentor | Clay Expert | Founder, ClikWorks

Bharat is a Clay Bootcamp mentor, Clay Expert, and founder of ClikWorks, a GTM engineering agency building automations for inbound, outbound, and RevOps for small and medium businesses. Based in Boston, he started as a data entry operator in India 16 years ago, spent years in WordPress web design, and discovered Clay in 2024. That pivot into GTM engineering led him to AI coding tools. Today his whole team runs on Claude Code and Codex, spending 70-80% of their time building directly with AI. He is one of the most active builders in the Clay Bootcamp community and one of the few operators who has hit Clay's 20M record account limit, twice.

Session Overview

What Bharat covered

🔍

Why he ignored Claude Code at first

The noise and FOMO in early 2026 made him skeptical. A live demo from Kushagra Tiwari changed that in one session.

⚠️

The real problems with LLM-first workflows

Context loss across 30 steps, inconsistent output formats, shared secrets scattered everywhere, and single-person dependency. Practical blockers, not theoretical ones.

🏗️

The framework he built around it

Three questions to decide what to build. Six elements every mini SaaS needs. One core principle: remove the LLM from runtime once the rules are locked.

🥝

KiwiKit live demo

A live walkthrough of his internal web scraping tool: dashboard, API keys for the team, live job monitoring, error tracking. Built in Claude Code over a weekend. Now handling 50-100M records a month.

How It Happened

The full journey from Clay to KiwiKit

The original bottleneck: a 28-30 step Clay workflow

One client needed hundreds of thousands of records processed daily across 7-8 worksheets. Two full-time people running it manually. Clay's 50,000-row-per-workbook limit meant constant juggling. At 100K to 1M records a day, this was not sustainable.

Hitting the 20M account limit, twice

Clay raised their account limit from 10M to 20M records after the first hit. They hit that too, on a second account. The only options were exporting to spreadsheets and databases as a temporary workaround. Bharat believes he may be one of the reasons Clay raised prices in April 2026.

First attempt with Claude Code: promising but inconsistent

Two days to validate that CC could replicate the workflow. It worked, but the 28-30 step process kept breaking mid-run, skipping steps, and producing different output formats on different computers, even with identical prompts and models. OneDrive and GitHub did not solve the shared context problem.

The key insight: Claude Code as builder, not forever decision-maker

After two months of experiments, the team landed on one core principle: use LLMs to design and validate the rules, then remove them from the runtime. Push deterministic code to a server. Every run after that produces the same result, every time, for anyone on the team.

Finding the open-source stack

Rather than build from scratch, Bharat searched GitHub for existing tools that could handle each module. Supabase for storage, Trigger.dev for job batching, Playwright for scraping, Hetzner for compute, Vercel for the frontend, Clerk for auth. Enterprise-grade tools his team could stitch together with Claude Code.

Building KiwiKit in a weekend

The frontend was built in Claude Code over a Saturday and Sunday. He asked it "what are the top 10 SaaS companies using for UI?" and then replicated those stack choices. The result: a web dashboard with live job monitoring, error breakdowns by domain, and API key management so any team member can trigger runs without touching CC.

The outcome: $600/month replacing $2,500/month, at 50-100M records

Running cost is around $40 for Hetzner, $200-300 for Trigger.dev, $40 for Supabase. 90 million records stored in Supabase for $40/month. The workflow now runs every morning with a single command. Two full-time people running it manually is no longer needed.

Framework 1

Three questions: what should you build first?

If all three are yes, productize it.

Question 1

Is it recurring?

Do you need to run this process thousands of times a month?

Question 2

Is it valuable?

Does it save time, save money, or directly make money for the business?

Question 3

Does it need shared access?

Do multiple people on the team need to run it or access the same data?

All three yes?Package the process into a mini SaaS product that your team can run without you.

Framework 2

Six elements every mini SaaS needs

Input

Where the team submits work

Web form, Claude Code, Codex, Clay

Process

Where the actual workflow runs

Server, Python or Node script, Trigger.dev

Output

Where the results go at the end

Claude Code, Codex, CSV, Clay, Slack

Observe

Where the team sees status and progress

Web dashboard, phone app, live job monitoring

Store

Where results, failures, and history live

Supabase, Firebase, Amazon S3

Access

Who can use it and how safely

Framework 3

LLM as builder. Server as runner.

Build Phase

Use Claude Code to design and validate

Let the LLM make decisions, set the rules, iterate on logic. This is where CC earns its keep. The creativity and decision-making happen here.

Validate Phase

Test at scale before locking anything

Run 100K records. Check the output format. Confirm consistency across multiple runs before you ship anything to the server.

Lock Phase

Remove the LLM from the runtime

Push deterministic code to the server. From here, no LLM is making decisions. The same input gets the same output, every single time.

Operate Phase

Let the team run it without you

API keys, dashboard access, error visibility. Anyone can trigger and monitor. No CC context required. No dependency on the person who built it.

Q&A Highlights

Questions from the session

With Clay's Sculptor for scraping, why did you need to build something custom?

Pure volume. The client processes 50-100 million records a month. Clay's 10M row account limit does not work at that scale, even across multiple accounts. The custom system replaced Clay entirely for that client. For normal volumes, Clay absolutely still makes sense.

What did it cost to build, and how does it compare to what you replaced?

About $1,000 in Claude Code subscriptions over 3-4 months to build. Running cost is around $600/month: $40 for the Hetzner server, $200-300 for Trigger.dev, $40 for Supabase. That replaced a $2,500/month scraping service. Cost was not the main driver though. Customization was. The workflow needed rules that no off-the-shelf scraper could handle.

If you were building another internal tool tomorrow, how would you approach the architecture decisions?

Start with the ROI question first: does it make money, save money, or save time? Then figure out the stack as you build. The infrastructure each tool needs is different. On V2 and V3 problems like spaghetti code or unclear decision-making, Bharat recommends switching to Codex over Claude Code. Codex is more structured and less creative, which helps when iterating on existing code rather than starting fresh.

Did you use any vibe coding tools like Cursor, Bolt, or Lovable to build the frontend?

100% Claude Code. The advantage is that CC already has full context about the app you are building, so it knows all the connections and APIs automatically. He asked it "what are the top 10 SaaS companies using for UI?" and then replicated those stack choices. The complete frontend took one weekend.

For someone just starting out in GTM engineering, where should they begin?

Do not start with Claude Code. Start with Clay first. Understand how GTM engineering actually works, what the real problems are, what good output looks like. Then move to Claude Code to replicate and automate those workflows. Going straight to CC without the GTM foundation makes everything harder, because you do not know what you are trying to build.

From a Clay workflow hitting its ceiling to a self-running internal system

Learn the full GTM engineering stack.