Bordvakt
Some restaurants release a month of tables in one batch, and lose them in minutes. This one waits for the release so you do not have to.
What it tries to solve
The good sittings exist for about as long as it takes to read the page they appeared on. What is left an hour later is the late tables nobody wanted — so the useful question is not "is there a table tonight" but what the next release will open, and whether it contains a night you want. The alternative is refreshing a booking page for a month, which is not a plan so much as a hobby.
- It explains a nothing. "0 matches" reads like a full restaurant, when the usual cause is that the times on offer fall outside the window you asked for. So it says which:13 on offer but none between 18:00 and 20:00 — they sit at 21:00, 21:30.
- Preferences rank, they never exclude. An ideal night decides which of several acceptable tables is offered first. It never rules one out.
- Nothing is booked without you. An alert is an alert; the booking waits for a button, and changing that takes a deliberate trip into settings.
The walkthrough
Ten frames from the running prototype, on one Mac watching three Stockholm restaurants that all book through the same engine. The numbers in the screens came back from real sweeps.
And it is not only a recording. Switch to try it yourself and the window takes the full width of the page, running the real matching logic over a snapshot of what was actually free: change the evenings, move the window, exclude a week, and what appears, how it ranks and the sentence explaining a miss are all recomputed the way the watcher computes them. Two honest limits — the availability is frozen at the moment the page was built, and the booking button only pretends.
Open the clickable prototype →It is an application. A big screen suits it.
Is this worth building?
One press. No name, no address, no follow-up — it tells me whether to take this further or let it mature a while longer.
Noted. Thank you.