Pivot or Break
A real-time build log of a lead-list workflow in Clay — where the pseudocode held, where live data broke it, and what I'd re-architect knowing what I know now.
What I built first, and why
My corner was a Lead List — the spine of the workflow I care about most: lead routing behind a "Schedule a Demo" web form.
A front-end form felt like the obvious start, but a form can't show the backend data motion I wanted to demonstrate. The real object was a structured database that ingests a lead the way production would, enriches it, scores it, and routes it. The build had to hit a concrete spec:
⟳Pivot or break
The build didn't move in a straight line. It pivoted twice around one hard constraint: you can't enrich data that doesn't exist.
Purely simulated rows are nearly impossible to enrich — the companies and personas don't exist in any real database. The fix was a hybrid: real B2B leads blended with simulated rows, so I had realistic enrichment targets and controlled variables to test against.
How a lead moves through it
Columns were mapped to mirror how a live lead ingests from a production web form — source, enrich, transform, score, route.
Not in the pseudocode: automated Calendly routing. The moment a lead is routed, the workflow pulls the assigned AE's scheduling link and attaches it for the prospect — closing the gap between routing logic and immediate conversion.
Not every signal is equal
Laying out the actual scoring weights exposed what the checklist hid: a handful of signals dominate the whole workflow. Email-domain verification isn't one input among many — it's the gate.
Once you see the weights, you stop running every enrichment equally. You branch on the gate — and everything downstream gets cheaper and cleaner.
What broke, what I did
No plan survives contact with live data. Four things broke; each forced a response.
What I'd build today
If I built this again, conditional routing and normalization would come first — not after enrichment. Instead of treating every lookup as a flat check, branch instantly on the domain-verification score.
A match on the gate triggers an optimized, concurrent enrichment path; a miss halts or routes to fallback — so you spend execution time and API credits on rows that can actually succeed, not on ones destined to fail.
Pseudocode vs. live execution
Pseudocode is a great way to map high-level logic, but it can't predict platform constraints or enrichment nuances — and it quietly assumes steps run in a line. Real data runs them in parallel, and that's where the plan cracked.
The question shifts from "how do I link these tools together?" to "how do I handle data states dynamically when multiple workflows run at once?" Abstract logic is where you start; real GTM engineering means diving into structural boundaries, data discrepancies, and execution constraints early — normalizing and sample-testing prompt outputs before you ever hit run.