The problem
A TPM who has spent years running programs across engineering and product teams has deep pattern recognition about what makes software work — timelines, dependencies, risk, communication. What that person often lacks is the hands-on fluency to build the thing themselves. That gap matters more now: AI tools are changing who can ship working code, but only if you know enough to direct them precisely.
The goal was not to finish a course or earn a certificate. It was to become someone who could sit down with a real technical problem, make sound engineering decisions, and ship a working artifact — without a senior engineer in the room. Real code doing real work, not exercises designed to feel productive.
The compounding risk of the self-teaching path is low signal-to-noise. Tutorials are abundant and seductive; actual artifacts are rare. Every week spent watching instead of building is a week where nothing gets shipped and nothing gets harder.
The approach
The plan was a six-week cadence targeting roughly ten hours per week: weekday concept sessions of ninety minutes each, and a Sunday build block of three to four hours where everything from that week had to combine into one working artifact. Bounded time, a clear definition of done, no moving the goalposts.
Week 1 built LLM API fluency in Python from scratch. Week 2 added structured outputs and tool use — forcing the model to return Pydantic-validated JSON instead of free text, and building a three-tool agent loop that could traverse a website. Week 3 introduced Cloudflare Workers and the TypeScript/Wrangler stack. Week 4 combined everything into the first real infrastructure slice.
The key strategic decision was to drop a planned workflow-builder track and move to Cloudflare Workers instead. Workers produce transferable skills and fit how the Semantic lead pipeline needs to run. A workflow-builder would have been faster to get going but would have capped the ceiling.
Each build was designed to be reused by the next. The Pydantic model and forced tool-use pattern from Week 2 reappear directly in the Week 4 Worker. Nothing was throwaway.
The build
Week 2 — Receipt Extractor (receipt_extractor.py): A Receipt Pydantic model serves simultaneously as data validator and tool schema. The build extended it in two directions: batch processing (a loop over a folder of receipts writing all results to a single output.json) and vision (the same extraction function accepts either a plain-text .txt file or a .jpg/.png image, builds the appropriate content block for the Anthropic API, and passes it to the same downstream machinery). The critical design choice was an explicit two-tool system: the model is forced to call either submit_receipt (valid data) or cannot_extract (garbage input, cleanly signaled). Garbage in returns {"error": "...", "source": "filename"} — never invented data.
Week 4 — Lead Intake Worker (lead-intake/): A TypeScript/Hono Cloudflare Worker implementing a four-step pipeline on every POST /intake:
- Zod validation rejects malformed payloads before spending an API call (the Pydantic discipline, ported to TypeScript)
- Claude Haiku classifies the lead using forced tool use — the same pattern as Week 2, now running inside a serverless Worker
- The record is written to Cloudflare KV before the response returns, so no lead is ever lost to a downstream failure
- Slack notification fires via
waitUntil()in the background, decoupled from the response path
The Worker also exposes retrieval routes, a health check, structured console.log output for wrangler tail, and a smoke-test.sh that exercises every code path in one command. A timeout plus one retry wraps every Claude call, with a fallback to "manual review" if the API is unavailable. A Claude outage cannot lose a lead. A follow-on webhooks lesson hardened the entry point with HMAC-SHA256 signature verification (verify.ts on a dedicated /webhook route), so the endpoint rejects forged or tampered payloads before any work runs.
Outcomes
The Week 2 receipt extractor processes a mixed batch of text and image receipts and writes every result — valid or garbage — to a single structured JSON file. The model never invents data it cannot see; the failure path is explicit and clean. That pattern — messy real-world input in, validated structured data out, with a graceful failure mode — is the core operation the Semantic lead pipeline needs.
The Week 4 Worker is the first real infrastructure slice of that pipeline: a deployed endpoint on Cloudflare's global network that classifies, stores, and alerts on inbound leads without a server to manage. Every engineering decision — Zod over raw validation, store-before-classify ordering, waitUntil for non-critical side effects, the two-tool escape hatch — is a deliberate tradeoff that reads correctly in a production code review.
The broader outcome is the compounding stack. Week 1 built API muscle memory. Week 2 built structured-data and tool-use patterns. Weeks 3 and 4 ported those patterns onto a real cloud platform in a second language. Each artifact was designed to be extended, not discarded.
What's next
Weeks 5 and 6 extend the same Worker rather than starting over. Week 5 adds a Postgres table so getLead becomes an indexed query and KV becomes a cache layer. Week 6 wires in Python enrichment scripts — ICP scoring, pain-match, outreach drafting — and adds a CLI that scaffolds a per-lead working folder on manual acknowledgment. The capstone demo, on Jul 13, 2026, shows the full inbound-to-enriched-to-repo flow end to end. The receipt extractor and the intake Worker are not exercises; they are the first two pieces of a system that will run in production.