Three restaurants, three different ways of making you set an alarm.
Wanting the table is not the qualifying condition. Being awake, free and fast at an arbitrary second is — and that is the friction this removes.
—
The window below runs the real matching logic over a snapshot of live availability taken from all three restaurants. Change the evenings, move the window, exclude a week — what appears, how it ranks, and the sentence explaining a miss are all recomputed the way the actual watcher computes them.
Two honest limits: the availability is frozen at the moment this page was built, and Book this table only pretends. Nothing here can reach a restaurant.
Click the tabs. Edit the request. Try Lilla Ego at 18:00–20:00 and read what it tells you.
Everything up to the booking button is built and was exercised against live availability while this page was written. The numbers in these screens — twelve tables at 21:00 and 21:30, seventy-two matches at Hantverket, nothing at all at Frantzén — came back from real sweeps, not from a mockup.
The booking write is the exception, and it is the important one. It has never been executed against a real reservation, because testing it means booking a table at Frantzén. The first press will be the first run.
One request returns the whole availability grid for the entire horizon — every date, every time, every seating area. Sixty days of availability for a single call.
That is what makes a five-second cadence defensible at all: during a release burst it is asking roughly what their own booking page asks when you open it, and the rest of the day it sits at five minutes.
On one Mac. Your name, email, phone and the ability to book never leave the machine. There is no account, no server, no queue — a single process and a SQLite file.
The honest gap: it is still started by hand with npm run watch. A reboot before midnight and the drop is missed, which is the one moment the whole thing exists for. A launch agent fixes that and is not written yet.