Made by David, Built with AI
All projects

Star Chaser

A tracker for visits to Michelin-starred restaurants, filled with thousands of restaurants by parallel research agents and checked by scripts.

The problem

My friends and I often plan holidays around fancy restaurants and we wanted a record of the Michelin-starred restaurants we have visited, with the stars each had at the time, and enough information about every restaurant to be worth browsing.

What I built

A single self-contained page, styled on the Michelin Guide, that ships as both a web app and an Android app from one source file.

Visit logging with the stars a restaurant held at the time, dates filled in from photo data, a map view with pins coloured by status, and a share option that includes the guide page and the restaurant's own site.

A database covering the UK list, a world list of 3,726 restaurants, full profiles for every three-star restaurant, and the history of UK stars from 2012.

Three phone screens of the Star Chaser app showing a summary, a restaurant page and a map
The summary, a restaurant page and the map view. Illustrative mock-up: the restaurant, chef and data are fictional.
Star Chaser summary screen
Summary: progress by star level, visits and favourites.
Star Chaser browse screen
Browse: search the lists and see what you have visited.
Star Chaser restaurant page
A restaurant page, with its star history and your visit.
Star Chaser log a visit screen
Log a visit: the date comes from your photo, with the stars it held then.
Star Chaser map screen
Map: pins coloured by visited, wish list and not yet.

How AI was used

Agents that gather the content

Parallel research agents compiled the lists and wrote a synopsis for each restaurant. Separate rounds of agents then found images and chef details. Batches ran at the pace the search allowance allowed. The Michelin Guide's own site blocked automated access, so it was used only for the lists.

Guardrails on what agents write

Synopses had to be ninety to a hundred and ten words in the agent's own words. Facts that could not be confirmed were left out, thin profiles were flagged instead of padded, and placeholders from agents that ran out of allowance were dropped at merge.

Scripts that check the agents

Every batch was checked for structure, length, duplicates and invalid star values. About five per cent was spot-checked against sources. A script comparing thumbnails caught fifteen photos that belonged to neighbouring restaurants.

Browser tests on phone-sized screens

Playwright tests drove the real app: logging visits, adding restaurants that had lost stars and attaching photos with and without dates, checking results against expected values.

What I think is clever

  • One source file builds both apps. A build step refuses to run if the copy breaks my style rules.
  • Image pipeline: faces centred and cropped for chef portraits, logos converted and recoloured so they show on white, images never upscaled and every file logged with its source and caveats.
  • Human in the loop. I corrected the star status of six restaurants. Follow-up research confirmed my corrections and added dates.

What I learned

  • Agents are fast and confident, and sometimes wrong. A verification script is cheap, and it found real errors.
  • Provider limits are a design constraint. Roughly two hundred searches per turn shaped the batch size and the brief for lower-priority restaurants.
  • Ask for honesty from agents. Leaving a fact out beats guessing it.

A private app. The screens shown here are an illustrative mock-up with a fictional restaurant, because the real restaurant imagery belongs to its owners.