TableFriend — Reservation sniping for Resy, OpenTable, and Tock

The problem

The best restaurants in the world don't take reservations the way the rest of the internet works. Tables at Tatiana, Carbone, Don Angie, Le Bernardin, and a few hundred other rooms across New York, Los Angeles, Miami, London, Tokyo, and Paris drop in tiny windows — 9:00 a.m. local time, two weeks out, gone in under a minute — and they live behind three of the most aggressive anti-bot stacks on the consumer web: Resy, OpenTable, and Tock.

For foodies and power diners, that means refreshing browser tabs at the same minute every morning, missing the drop because a 2-second human-reaction lag is two seconds too long, or simply giving up and going somewhere they didn't want to go. There are scripts out there — most are flaky one-off Python files that break the next time Resy ships a frontend change. TableFriend was built on a different premise: that reservation sniping deserves a real, durable system, not a script.

The approach

TableFriend is a proper monorepo — a Turborepo with a Next.js web app, a Playwright-driven worker for each reservation platform, and shared TypeScript packages for the platform connectors and types. The architecture is built for the only thing that matters in this category: being faster, more reliable, and harder to detect than anyone else trying to book the same table.

Pursuits. The core unit of work is a pursuit — a user telling TableFriend “I want Carbone, party of 2, any Friday or Saturday between 7 and 9 p.m., for the next four weeks.” Pursuits live in Postgres and are watched continuously by background workers.

The connectors. A custom Playwright connector per platform — Resy, OpenTable, Tock — runs inside Docker workers that watch for openings the second they appear. Without going into how, TableFriend has found a way to operate inside Resy's anti-bot environment that scripts and competitors don't survive in.

The queue. A Redis-backed job queue coordinates everything: polling cadence per venue, worker pool sizing, retry logic, and prioritization so that two users hunting the same drop don't race each other into a ban. When a table opens, the right worker fires within the same tick the inventory becomes available.

The catalog. ~20,000 venues imported from Resy's catalog and normalized into a single search surface, so users can find restaurants by name, neighborhood, or cuisine without leaving TableFriend.

The dashboard. A clean Next.js front-end with the only views that matter: active pursuits, recent bookings, a saved restaurants list, and a settings panel for party size, time windows, and notification preferences.

Outcomes

TableFriend is live and consumers are fulfilling 75% of the restaurant reservation searches they create — meaning three out of every four pursuits land an actual table at an actual restaurant the user actually wanted. In a category where most tools quietly stop working the moment a platform pushes an update, that's the number that matters.

The same system runs continuously against Resy, OpenTable, and Tock with no manual intervention, indexing ~20,000 venues and surviving every anti-bot iteration the platforms have shipped to date.

Who this is for

TableFriend is built for foodies and power diners in major cities worldwide — the people for whom “I'll just walk in” isn't a strategy and “refresh at 9 a.m.” isn't a plan. New York, Los Angeles, Miami, Chicago, London, Paris, Tokyo, anywhere the best tables move faster than humans can.

The same architecture — Playwright workers, a Redis-backed queue, Postgres-resident state, and a Next.js dashboard — is a template for any consumer category where the inventory is scarce, the drop is timed, and the platform doesn't want you automating against it. The same distributed-systems pattern shows up in AutoCRM's outbound engine: durable workers, queued jobs, retries that don't flame out, and platform guardrails that keep accounts safe.