A local-first restaurant booking and floor management system, built for one real restaurant. Runs entirely on the manager's laptop at the host stand, with no internet required during service.
Most modern booking systems live in the cloud. That sounds great until your internet drops on a Friday at 7pm and the floor team can't seat anyone. Booky takes the opposite approach: it runs locally on the manager's laptop, with all data stored on disk, no hosted backend and no internet dependency during service.
It's built as a single-restaurant product by design — deliberately not a multi-tenant SaaS — for a real venue: the founder's dad's restaurant. Updates still ship through a proper signed release pipeline, so fixes reach the install without ever exposing its data to me or anyone else.
The install runs against its own local data. When I push a fix, GitHub Actions builds and GPG-signs a release. The manager checks for updates from the Admin panel and clicks "Update Now" when they're ready. Before applying anything, the updater runs the new migrations on a copy of the database. If it fails, the update aborts and the venue stays on the working version. If they don't like the new version, one click rolls it back.
I have no remote access to customer data. Ever. That was the design constraint from day one.
The app is feature-complete for day-to-day service, with v0.1.4 as the latest signed release. It's going through a pre-launch hardening pass: session handling, admin authentication, encrypted backups with in-app restore, and the data retention schedule have all been reworked, and the privacy notice and software terms have been rewritten. The first-run installer now installs into a hidden AppData folder and sets up Node.js automatically. What's left before go-live: running that installer start-to-finish on the actual restaurant machine (BitLocker + TPM check + live release download, never tested end-to-end outside dev) and registering the restaurant as a data controller with the ICO.
This is the project where I had to stop thinking like a developer and start thinking like an operator. A restaurant doesn't care about your architecture diagram. They care that the system works at full service when their manager is two hours into a 12-hour shift. Every decision in Booky was made against that test.