Klaudius now builds booking systems: production-grade, custom to the business, in one command

Every website Klaudius builds can now take bookings.

Not an embedded widget. Not a link out to a platform. A complete, custom booking system on the business's own website: a restaurant's sittings, tables and party sizes, or a barbershop's services, staff and durations — with instant confirmation emails, self-service cancellation, a staff dashboard and automatic day-of reminders. The operator types one command, answers a few questions about how the business actually works, and the AI builds, installs and live-tests the whole thing.

That sentence would have sounded absurd eighteen months ago. A custom booking system is the kind of build that gets quoted at $4,000–$10,000 — it's real engineering, with real failure modes (we'll get to the double-booking problem below). Which is why nearly every small business rents one instead: OpenTable, Booksy, Fresha, Treatwell. And renting is expensive in its own way — we'll put numbers on that too, because those numbers are exactly what make this feature valuable to sell.

The system itself isn't a demo we knocked up for this post. It's distilled from a booking system we built bespoke for one of our restaurant clients, which has been running in production for weeks, taking real bookings every dinner service. What follows is the restaurant version end to end — the more demanding of the two shapes it takes — then what's under the hood, and what it's worth.

What the diner sees

A /book page on the restaurant's own website, in the site's own design. Pick a date, say how many of you there are, pick a sitting:

What's happening behind that innocuous "Available" label is the interesting part, and we'll get to it — the system is simultaneously checking seats and physical tables for that party size, the day's closures, and how close to service it is. If the kitchen is committed, or the party can't be seated, the sitting simply isn't offered. The form never advertises a time the restaurant can't honour, and it never fakes scarcity to pressure anyone.

Booking is instant — no account, no app, no "requested, pending confirmation" limbo:

And the confirmation email arrives from the restaurant itself — details, cancellation policy, and a one-click cancel link that automatically stops working close to service (configurable; this restaurant uses six hours), after which the email politely says to call:

What the owner sees

A staff dashboard at /admin/bookings on their own site. Tonight's service at a glance — how full each sitting is in both guests and tables — plus every booking with contact details and requests, one-tap cancellations (the diner gets notified automatically), closures for holidays or private hire, and an add-booking form for phone bookings, which is allowed to bypass the online cutoff because the person on the phone is the restaurant:

The dashboard is password-protected, and properly so — not a password check bolted onto a page, but a real session system: the owner's password is compared in constant time, a successful login issues a cryptographically signed session cookie, and every dashboard request and admin action re-verifies that signature on the server before touching anything. The owner just experiences "one password, and it works on my phone" — the engineering underneath is the same standard as software they'd pay a subscription for.

There's also a quieter feature owners end up caring about a lot: every time someone checks availability and can't book — sitting full, party too big, day closed — the system logs it. After a month you can tell an owner "23 parties tried to book Saturdays you couldn't seat". That's not a report a booking platform is keen to hand over, and it's exactly the evidence that justifies adding a sitting, a service day, or more covers.

What this is worth

Here's where the rental numbers matter. What a business currently pays for booking capability, at mid-2026 listed prices:

• Restaurants. OpenTable's entry plan is $149 a month — and then $1.50 per diner for every booking that arrives through its network, plus 25¢ a cover for bookings made on the restaurant's own website on that plan, plus, since early 2026, a 2% service fee on transactions. Industry worked examples for a moderately busy restaurant come out around $2,600 a month. The flat-fee alternatives aren't cheap either: ResDiary runs roughly $125–$300 a month; SevenRooms starts around $499 a month.
• Salons and barbers. Booksy is $29.99 a month plus a fee per extra team member — and its Boost feature takes a 30% commission on a new client's first visit. Fresha charges a per-team-member subscription, a 20% commission on every new client its marketplace sends, and payment-processing fees on top. In the UK, Treatwell takes 35% + VAT — about 42% all-in — of a new client's first booking.

So a restaurant on per-cover pricing can be spending $25,000+ a year; even a barbershop's subscription plus commissions runs to four figures. And the buy-it-outright alternative — having a system like this custom-built — is routinely quoted at $4,000–$10,000 for the basic version, before anyone talks about the website it has to live on.

That's the gap this feature drops an operator into. On one side: what businesses already pay, forever, for a widget with someone else's branding that keeps their customer list. On the other: what custom development costs. You're selling something in between — custom, owned outright, on their own site, with no meter running — and the running costs underneath it are genuinely zero at small-business volume (the free tiers of the hosting, database and email services it's built on cover a small business's booking traffic comfortably; the only real-world cost is a ~$12-a-year domain). Price it wherever you like inside that gap: it's the rare pitch where the business's own bank statements make the argument for you.

How it works under the hood

For the technically curious — this is the part that separates a production booking system from a form that inserts rows. The stack is three free-tier services and some discipline:

• The site: Next.js, hosted on Vercel's free tier. The booking pages are server-rendered on every request, which matters more than it sounds — it means rule changes appear instantly without redeploying anything.
• The database: Postgres, via Supabase's free tier. Tables for bookings and closures — and one settings row that is the single source of truth for every business rule: service days, sitting times, capacity, party sizes, the cutoff, the advance window.
• Email: one SMTP transport. Confirmations, owner notifications, cancellations in both directions, and a day-of reminder sent by a scheduled job each morning.

Four design decisions do most of the work:

Capacity is two-dimensional, because dining rooms are. A restaurant doesn't just have "36 seats" — it has ten tables that seat four. A party of five doesn't take five seats; it takes two tables. So every sitting tracks both numbers, and a booking consumes both: a party of five counts five against the 36 covers and ⌈5⁄4⌉ = two against the ten tables. A sitting is full when either dimension runs out. Get this wrong — count only headcount, as a naive implementation would — and the maths will happily book nine couples onto ten tables and then try to seat a party of four in the chairs that are left at opposite ends of the room. You can see both dimensions ticking along in the dashboard screenshot above: 14/36 guests, 5/10 tables.

Every rule lives in the database, never in the code. The first version of this system had the booking cutoff written in two places — a code constant and the database function that enforced it. We changed one and not the other, and same-day bookings quietly broke in production. The fix became the architecture: rules are rows. The code reads them; the database functions read them; nothing duplicates them. It also means the owner saying "make the cutoff four hours instead of six" or "add a 9pm sitting on Saturdays" is a one-line database update that takes effect in seconds, with no deploy.

Double-bookings are prevented in the database, not in the application. This is the classic booking-system bug. Two parties hit "confirm" for the last table at the same moment; both requests check availability; both see it free; both insert. Checking harder in application code cannot fix this — the race lives in the gap between the check and the write. Our booking function takes a Postgres advisory lock keyed on the date and sitting before it checks anything, so two simultaneous attempts are forced into single file: the first books, the second is told, honestly, "this sitting just filled up". The subtle detail — and the reason an ordinary row lock doesn't work — is that an empty sitting has no rows to lock. You have to lock the idea of the sitting, not the data.

Email identity is a routing problem, not a sending problem. The confirmation should look like it comes from the restaurant — but the address it's sent from can't receive replies. So every email sets its Reply-To deliberately: diner-facing mail replies go to the owner's real inbox, owner-facing mail replies go straight back to the diner. The owner can hit reply on a booking notification and be talking to their guest, and neither of them ever sees the plumbing. On a client with their own domain, sending runs through Resend with the domain verified, so mail comes from bookings@theirdomain.com.

Add the unglamorous parts — a honeypot field and rate limiting on the public endpoints, a per-customer daily booking cap so nobody can fill a service with a script, cancellation that's idempotent so racing cancel-clicks can never send duplicate emails, and cryptographically random cancel tokens so links can't be guessed — and you have the whole system. No platform, no subscription, no per-cover meter running.

The same engine, pointed at a salon

Restaurants are the harder case, but the machinery generalises. Bookings come in exactly two shapes: slots with capacity (restaurants, classes, tours — fixed start times that fill up) and services with staff (barbers, salons, clinics — durations on someone's calendar, with per-service cleanup buffers and "anyone available" assignment). Same settings row, same locking, same emails, same dashboard, same telemetry — different availability maths:

One command, and it proves itself

The operator types /booking restaurant-name. The AI asks a short set of questions — which shape, what days and sittings, how many tables and covers, what rules — then installs the entire system on that client's site: database, booking page restyled to match the site's design, dashboard, emails, reminders. And before it ever reports done, it tests itself against the live site: it makes a real booking, checks the confirmation email actually arrived, cancels it through the cancel link, verifies the dashboard shows the right state, and cleans up after itself. The screenshots in this post are from exactly such installs on demo sites.

That's the part we care most about, honestly. "AI built it" is easy to say; "it booked a table on the live site, received the email, and cancelled itself before handing over" is a different standard.

If you've read this far

Everything in this post ships inside Klaudius — the same system we use ourselves. It's not a course and not a SaaS: it's the complete, working pipeline as a one-time purchase. You point an AI agent (Claude Code or Codex — the AI does the building; you don't need to code) at your own region, and it finds local businesses without websites, builds each one a bespoke site, deploys it, and handles the outreach. The booking system is one command on top of any site it builds — along with a self-serve content management system and a live Google-rating widget you can sell the same way.

One licence, $399, one time — no subscription, and a 7-day money-back guarantee. What you charge your clients for builds, bookings and care plans is yours.

See how Klaudius works →