The brief
An AI skill gap, framed as a scraper.
The CEO of a New Zealand recruitment firm came to me with a problem they'd diagnosed as an AI capability gap. Specifically: they wanted a view of the last 24 hours of job board postings across the market, with AI doing the scraping. The shape of the request was concrete — go scrape these sources, use AI to do it.
I took the request seriously and then looked at it carefully. The thing they were asking for — AI-powered scraping of public job boards — is a solved problem. There are paid API middleware platforms that already do exactly this, reliably, for a small monthly fee. Building a bespoke AI scraper would have cost more and produced a less reliable result than the existing services already offer.
That left a more interesting question: what was the actual problem behind the stated one? The scraper was a way in, not the destination. The firm was looking for a way to participate in what AI could do for their business, and a 24-hour view of job postings was the most concrete handle they had on it.
I subscribed to an existing job board API service for the data feed and used the time I'd saved to build something the CEO hadn't asked for: a working end-to-end recruitment platform around it.
The build
Cloudflare-native, end-to-end, in 24 hours.
With the data ingestion problem outsourced, the day became about stitching the rest of a recruitment workflow together — and choosing a stack that would let me move fast without making decisions I'd regret on day two.
I went Cloudflare-native end to end. Cloudflare Workers for compute, D1 for the relational layer, Vectorize for embeddings and semantic search, Workers AI for the LLM enrichment and reranking calls. One platform, one auth model, one deployment surface. No glue infrastructure to set up, no IAM to argue with — the build time stayed inside the build, not the plumbing.
On top of that I layered the actual recruitment logic: ingestion of the live NZ job feed, LLM enrichment to extract structured fields from messy listings, a vector index over candidate profiles, and a search interface that ranked candidates against jobs using semantic similarity reranked with structured filters (location, seniority, skills). Standard recruiter workflow, just done with the tools the CEO wanted to understand.
Try the interactive walkthrough → sample data, no live integrations
The unlock
Voice was the demo, not a feature.
The piece that mattered most wasn't in the original brief at all. I wired in ElevenLabs voice screening at the candidate-shortlist stage — a synthesised recruiter voice could call a candidate, ask scripted screening questions, and feed structured answers back into the platform. Standard tech stitched together in an unusual workflow.
At the demo the next day, the scraper got about thirty seconds of attention. The voice screening got the rest of the meeting. Watching the CEO's face when an AI voice rang a candidate's phone and held a screening conversation — that was the moment the brief expanded.
That's what shifted: the conversation stopped being about scraping job boards and started being about what an AI-augmented recruitment workflow could look like. The deliverable did its job and the demo did its job, which are different jobs.
In retrospect
What this taught me about prototypes.
Three things I'd defend if a hiring manager pushed on this build.
One: the brief is rarely the problem. The CEO had correctly identified a problem (limited market visibility) and reached for the most concrete fix they could imagine (a scraper). The harder, more useful question was the one underneath it — how do we get this firm productively engaged with AI? — and you can only answer that by listening past the request.
Two: buying boring parts is a feature, not a compromise. Not bespoke-building the scraper freed up the budget that made the rest of the platform possible. The same instinct applies in enterprise: don't burn your prototype budget on problems that have already been solved by Cloudflare, Microsoft, AWS, or a paid API. Spend it on the part that's specific to the customer.
Three: a prototype is a conversation device. The artefact has to work, but its real job is to make the next conversation sharper than the last one. The voice screening wasn't the most technically interesting thing in the build. It was the thing that re-shaped the buyer's sense of what was possible — and that's what a one-day prototype is for.