2025Founder / Designer / Builder

Cheft

Live product

My wife and I are exactly who this is for. We love Top Chef and the whole world of TV cooking competitions, and we travel a lot, so we're forever trying to eat at these chefs' restaurants. Finding them is miserable: unless you already know the chef you're after, the information is scattered across outdated blog posts, places that closed two years ago, and SEO spam. People keep trying to fix it, but keeping it accurate is a mountain of manual research, so it never lasts.

Cheft is my answer: a searchable map and directory of every restaurant run by a TV chef, with verified locations, prices, cuisines, and whether each spot is even still open.

I also took it on as my first real attempt to put LLMs and automation together — to build the system, not just design it. The result is a research-grade database that builds and maintains itself, from nothing but a list of contestant names.

The Cheft landing page: 'Restaurants by TV's Top Chefs,' with live counters reading 1,293 restaurants, 464 chefs, and 162 cities, above a featured-chef spotlight for Kwame Onwuachi.
Every number on that page is a row an LLM pipeline researched, structured, and verified.

The problem is trustworthy data, not pages

A directory is only worth visiting if the data is right. The hard part of this product was never the map or the card layout: it was assembling accurate, current information about ~1,200 restaurants and ~460 chefs without a research team, and without the hallucinated restaurants and dead links that make every other source useless.

So I treated the data itself as the product, and built an AI pipeline to produce it: turn a bare list of show contestants into verified, richly-tagged profiles, and keep them honest over time.

A Cheft restaurant page for Tatiana by Kwame Onwuachi — an OPEN badge, 4.3 rating from 765 reviews, price tier, New York location, a photo gallery, and the chef who runs it.
One restaurant profile: status, rating, price, location, and the chef behind it — every field researched and verified, not scraped.

One command builds a whole show

Adding a season is a single command with a list of names. From there the pipeline does the research: it discovers each chef's bio and awards, every restaurant they run and where, their other TV appearances, and writes the SEO copy for each chef, city, and show page. A new show (dozens of chefs and their restaurants) goes live in under a minute for around fifty cents.

Under the hood it's a service-based architecture I refactored out of a 1,300-line script into focused services (bio, restaurant discovery, show discovery, status verification, narrative writing) wrapped in workflows with built-in cost caps, retries, and rollback. The data layer never trusts the model blindly: duplicate detection, confidence scores, schema validation, and a Google Places check sit between the LLM and the database.

The Cheft show page for Top Chef — 214 chefs, 506 restaurants, 206 cities, and 20 Michelin stars, above a 'Where Winners Cook' grid of champions and their flagship restaurants.
A whole show, built from a list of names: 214 chefs and 506 restaurants, live in under a minute.

A hybrid search architecture that made it cheap

The first version was slow, expensive, and inconsistent: a single reasoning model doing its own web search took two minutes and produced wildly varying results. I rebuilt it as a hybrid: a fast orchestrator model decides what to look up and structures the output, while a dedicated search model does the grounded web lookups and hands back facts.

That one change took a chef from ~120 seconds and three cents to ~15 seconds and a third of a cent, and from one-to-eight scattered results to a consistent seven-to-eleven. Layering on a cached search API, a discounted batch tier, a reused Wikipedia cache, and a hundred parallel workers brought a full show down to seconds. The whole live database costs about a dollar a month to keep running.

A Cheft chef page for Kwame Onwuachi — a full written bio (Culinary Roots, Rise to Fame), a quick-facts sidebar with his show, restaurant count, James Beard award, and social handle.
What the pipeline produces per chef: a sourced bio, awards, restaurant count, and links — from nothing but a name and a show.

Automations keep it true

Restaurants close. A directory that doesn't notice is worse than no directory. Three scheduled jobs keep Cheft current: a weekly sweep re-checks restaurant open/closed status, a monthly job re-researches any chef whose data has gone stale, and a queue processor handles approved edits, all with the same cost ceilings and confidence thresholds as the build pipeline.

On the visitor side, the same structured data powers natural-language search: "Top Chef winners in Chicago" resolves to real filters over verified rows, not a guess.

The Cheft restaurants directory — 974 open across 50 cities, with filters for state, city, open status, Michelin, and price, over a grid of verified restaurant cards.
974 open right now: status the weekly sweep keeps honest, filterable down to city, price, and Michelin.

Learning the system by building one

I started Cheft to find out whether I could build this kind of system at all, not just design it. I'd spent a year reading about LLM pipelines and automation; this was the project where I stopped reading and shipped one.

What I worked out here became the template for everything after: treat the data as the product, never trust the model blindly, wrap every call in cost caps and verification, and let scheduled jobs keep it honest. Cheft is where building with AI stopped being something I was aiming at and became something I'd actually done.