— N° 01 · Build log
The pseudocode I wrote a few days ago had five clean steps. Building it took most of a day, and almost none of that day went to the parts I planned for.
At the time this was clean IF/THEN logic — credit-conscious, one direction. Five lines:
// clean IF/THEN logic · credit-conscious · one direction
The actual shape of the pipeline. Slack capture, n8n as the connector, Clay as the qualification layer, enrichment gated behind a hot flag. The architecture in the pseudocode is the architecture I built.
Slack’s Events API needs a synchronous challenge-response handshake before it will accept a webhook URL at all.
Socket Mode was silently on in my Slack app, routing events over a WebSocket instead of my Request URL. Everything downstream looked perfectly configured and nothing arrived — no error, just silence. This one cost the most time and taught me nothing about GTM logic, only about Slack’s config surface.
◦ biggest time sinkI assumed Slack’s native “Generate transcript” feature could replace AssemblyAI. It can’t run headless — it’s a manual, per-message button tap in the Slack UI. My “single AI pass” step quietly assumed transcription was a solved input, not a thing I’d have to build.
A missing files:read scope produced a 403 that looked identical to a dozen other possible failures. I chased token formatting, redirect settings, and file-type mismatches before finding the actual cause.
n8n’s credential dropdowns kept silently reverting to unselected after node edits. Twice I re-tested a “fixed” node and got the exact same failure, because the fix never actually saved.
The entire file-download step — Slack → n8n, an authenticated pull of the actual audio bytes — doesn’t exist anywhere in my pseudocode. I wrote “if a voice memo lands in the table” as if the memo just appears. Getting from “rep records audio” to “AI can read text” is four separate authenticated hops, each with its own failure mode.
The built Process Booth Notes workflow. One node (Slack Trigger) is pseudocode step 1 as written. One (HTTP Request · GET file bytes) was in the plan nowhere. The middle four are the transcription service I assumed I’d get for free; the last hands the transcript to the Clay table.
(The working table runs on placeholder company and contact names, so the enrich-company waterfall stays dormant — invalid domains, nothing to fire on.)
Good pseudocode tells you whether your logic is sound. It tells you nothing about whether your infrastructure will let that logic run.
Pseudocode is a plan for the business logic, not a plan for the plumbing. My IF/THEN steps were right about when to enrich, when to flag as hot, when to notify a rep. They were silent on everything about how two systems actually exchange data — auth, verification, async waits, format mismatches.
The gap wasn’t in my reasoning about the GTM problem. It was in treating “capture the voice memo” as one pseudocode line when it’s the majority of the real build.
Rethinking what data is available to a vendor pre- and post-event, versus what you get as an attendee gathering leads.
Registration-list matching
If the full attendee registration list is provided pre-event, cross-reference the extracted company and contact name from the hot-flagged rows against that list.
Badge OCR
If a rep photographs the attendee’s badge, OCR extracts name / company / title directly from the badge — bypassing the “AI has to correctly parse a rambling voice memo” problem entirely.