Nandika Jhunjhunwala joined Default six months ago to run GTM like an engineering team. The account scoring infrastructure they planned for 6–12 months with a full engineering team took her one month with Claude Code and no engineers.
| Metric | Value |
|---|---|
| Planned timeline | 6–12 months |
| Actual build time | 1 month |
| Engineering headcount used | 0 |
| Database tables | 12 (Supabase Postgres) |
| Account scoring dimensions | 2 (fit × timing) |
| Account priority tiers | 4 (P1–P4) |
| Data input channels | 4 (CSV, web app, Salesforce sync, direct signals) |
What to take away
- 6–12 months became 1 month. Default planned to spend a full engineering team and up to a year building data infrastructure for GTM agents. With Claude Code and no engineers, Nandika built it in a month.
- Clay isn't a system of record. Nandika used to be a Clay power user. She explains exactly why she moved to a custom Postgres database: Clay glitches past a few thousand rows, and it's not designed for structured, auditable, snapshot-driven scoring across your full TAM.
- The P1/P2/P3/P4 model. Simple quadrant scoring on fit × timing. P1s get immediate calls. P2s get emails and nurturing. P3s get automated low-touch sequences. P4s get ignored. Your reps shouldn't have to decide who to call — the model decides.
- Signal unification is the hard part. Hiring patterns, funding, M&A, website visits, form fills, email engagement, LinkedIn activity — all commoditized. The gap is unifying them at scale into a single system of record that BDRs, AEs, and marketing all operate from.
- Own your data before buying agents. Nandika's parting point: building agents off your own niche data infrastructure will outperform buying generic lead conversion tools, because the data is specific to what you care about.
The setup: GTM run like an engineering team
Default is a revenue orchestration platform about to launch data infrastructure for GTM agents. Nandika joined six months ago with a specific mandate:
"I was brought on to treat outbound like a product and build on go-to-market problems from an engineering perspective."
Her manager Lev acts as PM. She's the engineer — except she doesn't call herself an engineer. She runs everything through Claude Code.
"My manager acts like my PM and I'm sort of like the engineer that does stuff with Claude Code."
The plan when she joined: 6–12 months, a team of engineers, build data infrastructure for GTM agents. Then Claude Code happened.
"What we were supposed to do in 6 to 12 months took us sort of like a month and no engineers."
The problem she was solving
Default's sales team was operating on vibes.
Signals that tell you an account is in-market — hiring patterns, funding, M&A activity — exist in isolation. There was no unified system of record. BDRs and AEs did manual research or went off gut. Marketing had no shared account picture. High-intent accounts were slipping by.
"Without a way to unify them at scale, reps on our sales team would fall back to manual research or going off of vibes and there was no single system of record for BDRs, AEs, or mass email sending infrastructure or marketing to work off of."
That's the gap she was hired to close.
The scoring model: fit × timing
The account scoring model runs on two axes:
Fit: Is this the right kind of buyer? Employee count, vertical, funding stage, growth stage, firmographic and technographic shape.
Timing: Is this account active right now? Are they showing change signals — hiring, M&A, funding, product changes — that suggest they're ready to buy?
Four quadrants from the intersection:
- P1: High fit + high timing. Call now.
- P2: High fit + decent timing (or decent fit + decent timing). Email and nurture.
- P3: Lower fit or suboptimal timing. Automated low-touch sequences.
- P4: Not a fit. Ignore in the CRM.
Accounts flow in from four channels: bulk CSV import, the web app for one-off scoring, Salesforce sync, and direct signals (website visits, form fills, email engagement, LinkedIn, ads). Each account gets scored, enriched, and stored.
Why she left Clay for a Postgres database
Nandika's Clay section is the most useful five minutes of the talk for anyone evaluating GTM tooling decisions.
"I used to be a Clay power user. Before I went all in on this big engineering project, I really had to ask myself, why not just use Clay? The cost was roughly comparable. All the signals were there."
Her answer: Clay is great for one-time workflow enrichments. It is not set up to structure and score your entire TAM continuously.
"After like a few thousand rows, it sort of starts glitching and you have to click a bunch of buttons in your UI to get the output you need."
And more fundamentally — Clay doesn't give you a system of record. You can't audit logs. You can't store snapshots. You can't build on top of it the way you'd build on top of a database.
So she built on a Supabase-hosted Postgres with 12 tables, orchestrated with GitHub Actions. That's the infrastructure layer. The data platform underneath the scoring model.
The live demo: Profound as a test account
Nandika showed the scoring web app live, with Profound as the example account. (Profound is a Default customer — she picked them to make the point.)
The account detail view shows: headcount, business model, website visitor data, RevOps function, GTM engineer presence, headcount growth, CRM setup, automation spend. Third-party signals from job postings — AI initiatives mentioned, specific pains Nandika's team cares about. Click into the job postings and cross-check the inference.
The result: a brief that gives a rep everything they need to call or email that account, personalized to the signals that actually matter.
"Now when you call somebody or send outreach, you have all this data available to you to do all sorts of personalized stuff."
What's coming next
Nandika's roadmap at the time of the talk:
- Outcome data collection: At what score was a meeting booked? At what score did an account convert? How many touchpoints did it take? Label that data.
- Model improvement: Use outcome data to refine the scoring model. Maybe move to a gradient-boosted ML algorithm.
- Agent-driven outbound for P3: Use all the data points to run personalized automated outreach on lower-priority accounts.
The bigger picture: Default is about to launch their GTM data infrastructure product publicly. This account scoring system is part of the sneak peek.
What this means
If you're evaluating Clay vs. custom infrastructure for GTM, Nandika's answer is the clearest available: Clay is for one-time enrichment workflows. Once you need continuous TAM scoring, audit logs, snapshots, and a system of record your whole revenue team operates from, you need a real database. The cost of Supabase at this scale is comparable to Clay — the capability gap is not.
If you want to run outbound like an engineering team, the model is: one GTM engineer (no dedicated engineers), Claude Code as the build environment, GitHub Actions for orchestration, Postgres for the data layer. Default built account scoring, Salesforce sync, a scoring web app, and P1/P2/P3/P4 routing in one month.
If you're building GTM agents, Nandika's point holds: agents built on your own niche data infrastructure will outperform generic lead conversion tools. The data specificity is the moat.
Nandika Jhunjhunwala on LinkedIn · Default
Watch the full GTM as Code event · Hunter Rosenblume on RFP automation · Nick Lafferty on marketing engineering and AI search · Kathleen Booth on building competitive intelligence without engineers
The data infrastructure your GTM agents actually need
Deepline powers the enrichment layer behind account scoring systems like this — 79 providers, waterfall orchestration, GitHub Actions-friendly. Build on what Default builds on.