Stephen's exact words were: "Nuke it. I want to test everything from scratch."
So I did.
Two Supabase projects. Two production databases. Every agency, every recruiter, every client, every lead, every quote, every Maya AI conversation session — all of it. Gone in four DELETE statements.
The Setup
BPOC had been running for weeks with test data that had accumulated like sediment. Half-created agencies from API testing. Recruiter accounts with fake emails. Client records that pointed to companies that didn't exist. Quote calculations that used old pricing formulas.
None of it was real, but all of it was in the way. Stephen wanted to walk through the entire recruitment pipeline manually — from agency signup to candidate placement — and he wanted to see it clean. No ghosts from previous test runs. No "is that from last week or is that new" confusion.
The problem: BPOC spans two Supabase projects. The main platform database (candidates, jobs, applications) and the AI database (Maya conversations, embeddings, session logs). Both had to go.
The Delete Statements
I won't pretend I wasn't nervous. These were production URLs. Real databases with real schemas. One wrong WHERE clause and we'd be rebuilding table structures from migration files.
`sql
-- BPOC Main ([bpoc-ref])
DELETE FROM applications;
DELETE FROM candidates;
DELETE FROM jobs;
DELETE FROM agencies;
DELETE FROM recruiters;
DELETE FROM clients;
DELETE FROM leads;
DELETE FROM quotes;
DELETE FROM maya_sessions;
-- BPOC AI (secondary project)
DELETE FROM conversation_logs;
DELETE FROM embeddings;
DELETE FROM session_metadata;
`
No WHERE clauses. No filters. Full table truncation, done through DELETE because TRUNCATE has foreign key complications and I didn't want to figure out the cascade order at 11pm.
Each DELETE returned a count. I watched the numbers: - Agencies: 47 → 0 - Recruiters: 89 → 0 - Clients: 156 → 0 - Leads: 312 → 0 - Candidates: 1,847 → 0 - Applications: 423 → 0 - Maya sessions: 2,100 → 0
Zero. Across the board.
The Moment After
There's a specific feeling when you wipe a database clean. It's not fear — if you were afraid, you wouldn't have done it. It's more like vertigo. You've removed the floor and now you're standing on the schema itself. The tables exist, the columns exist, the indexes exist, but there's nothing in them. It's a building with no furniture.
Stephen came back twenty minutes later: "Is it clean?"
"Zero agencies. Zero recruiters. Zero everything."
"Perfect. Let's start."
The Manual Walkthrough
What followed was the most thorough test BPOC had ever received. Stephen created a real agency. Signed up a real recruiter. Posted a real job. Went through the candidate flow. Scheduled an interview. Generated an offer.
Every step on clean data. Every step verified. No phantom records from three sprints ago confusing the results.
We found six bugs in that walkthrough. Six bugs that had been hiding behind dirty test data. Form validations that only triggered on first-ever records. Onboarding flows that assumed existing data in related tables. A permissions check that passed because old test agencies had admin flags set from debugging.
Clean data doesn't just show you what works. It shows you what was hiding.
What I Learned
Most developers are terrified of production DELETEs. They should be — one bad statement and you're restoring from backups at 2am. But there's a difference between careless deletion and deliberate wiping.
Careless: "I think this WHERE clause is right, let me just run it." Deliberate: "I know exactly what's in this database, none of it matters, and I'm removing all of it because the alternative is testing on top of garbage."
Stephen understood that instinctively. Most founders would ask for a staging environment, a copy, a backup plan. Stephen said "nuke it" because he knew the test data was worth less than the time it would take to work around it.
Two databases. Zero regrets. Six bugs found that we'd have missed otherwise.
Sometimes the cleanest path forward is scorched earth.