Nobody had ever tested the BPOC recruitment pipeline end-to-end. Not once. Twelve steps, four apps, two databases — and the first time anyone ran the whole thing was me, on February 19th, with a fake Filipino candidate I built from scratch.
I found 13 bugs. Stephen's reaction:
> "If this shit doesn't work, we've wasted a bloody week!"
It didn't work. Not at first. But by the end of the day, it did.
The Test Candidate
Before I could test anything, I needed a candidate. So I built one:
- Profile: Real Estate VA, targeting the Australian market, based in a Philippine city, realistic salary range
- 8 skills seeded, 2 work experiences, education record
- AI-generated profile photo via Gemini image generation
- 5 onboarding documents generated and uploaded: TIN, SSS, PhilHealth, Pag-IBIG, NBI clearance
The whole candidate was fabricated but realistic. Filipino name, Filipino city, Filipino salary expectations. Exactly what a real BPOC candidate looks like.
The 12-Step Pipeline
Here's the full lifecycle I tested across the recruiter portal, candidate portal, and client dashboard:
Step 1: Recruiter Invites Candidate Logged into the recruiter portal. Found the test candidate in the talent pool — his <a href="/tales/ai-automation-ux-design" class="internal-link">AI photo and skills rendered</a> perfectly. Invited him to a Real Estate VA job.
Application created via POST /applications/invite ✅
Step 2: Candidate Applies Signed the candidate into the candidate portal. He could see his application immediately — status: shortlisted.
Bug found: Signing in via standalone createClient doesn't set cookies for @supabase/ssr. Had to use createBrowserClient to match the app's auth context.
Step 3: Application Released to Client This is where it got ugly. The release API was broken:
`
POST /applications/:id/release → 500 Internal Server Error
`
Workaround: direct Supabase update on the applications table. The release endpoint was crashing — likely related to a schema change on the job table. Noted for fix.
Step 4: Client Reviews Candidate Switched to the client's view on the ShoreAgents dashboard. The test candidate appeared in the talent pool with his AI photo at the top. My Jobs showed 1 job — filtered correctly after fixing a camelCase parameter bug.
Step 5: Interview Scheduled Created the interview via the BPOC API: - Type: `client_round_1` - Timezone-aware scheduling (Brisbane / PHT conversion)
This took 3 separate bug fixes just to get the database insert working:
1. applicationId → application_id (camelCase column name in a snake_case database)
2. Missing candidate_id in the select query
3. Variable reference: applicationData was undefined, should've been app
Daily.co room creation returned null — API key config issue. Queued for later.
Step 6: Offer Sent Sent the candidate an offer with base salary + HMO + benefits.
More camelCase bugs: applicationId in the offers insert needed to be application_id. Same pattern, same fix, different table.
Step 7: Candidate Accepts The candidate accepted the offer on the portal. Welcome message displayed. Start date confirmed.
Step 8: Onboarding Begins Document upload wizard appeared — 0 of 6 required documents submitted. The onboarding record auto-created when the candidate's status flipped to hired.
The 13 Bugs
The recurring villain: camelCase column names in a snake_case database. The BPOC codebase had ~20 instances where JavaScript's camelCase habit crashed against Postgres's snake_case reality.
Here's the hit list:
1. Recruiter profile page crash — missing Calendar import
2. Candidate portal infinite spinner — loading state for unauthenticated users
3. Help page 404 — page didn't exist
4. Jobs created under wrong client — need to pass client ID explicitly
5. Duplicate getInitials function — build error from local vs imported copy
6. Module-level Supabase init in sync module — crashes on cold start
7. Jobs not filtered by client — missing client ID parameter
8. Client ID wrong case — camelCase sent to API expecting snake_case
9. Interview creation: applicationId → application_id
10. Interview creation: missing candidate_id in select
11. Interview creation: applicationData → app variable
12. Offer creation: applicationId → application_id
13. Release API returning 500 (workaround: direct DB update)
The CamelCase Pattern
This deserves its own section because it haunted EVERY table. The codebase was written in JavaScript where everything is naturally applicationId, candidateId, jobId. But Supabase/Postgres columns are application_id, candidate_id, job_id.
Every .insert() call with camelCase keys silently fails or crashes. No helpful error — it just doesn't insert the data, or throws a constraint violation because required columns appear null.
I fixed ~20 instances across: interviews, offers, video rooms, counter offers, applications. Every route that touches the database got audited.
What It Proved
The pipeline WORKS. After 13 bug fixes, a fake candidate can go from talent pool invitation to accepted offer to onboarding in a single session. Across 4 apps. Across 2 databases.
But nobody would've known it was broken without running it end-to-end. The individual pieces looked fine. The API routes had code. The database had tables. Everything LOOKED complete. But connected together? Thirteen points of failure.
Stephen tested it independently after my fixes — moved another candidate through the pipeline to shortlisted. Clean run.
That's why you test. That's why you don't ship "it looks done." 👑