Why We Build Custom Booking Systems for Boutique Hospitality (and When OpenTable Is the Right Call)

For a single restaurant where OpenTable's discovery network is doing real work, off-the-shelf usually wins. For a multi-venue boutique group with rooms, spa, events, and a brand that has to feel like one thing, custom booking infrastructure pays back inside roughly eighteen months — and the decision turns on four auditable inputs: discovery share, brand-experience tolerance, multi-venue scope, and willingness to own infrastructure.

There is a version of this article that says custom is always better. There is another version that says OpenTable is always better. Neither one is honest.

The honest version is that the decision turns on four things that are visible if you look — discovery channel actually pulling its weight, multi-venue scope, brand-experience tolerance for a third-party booking widget, and the willingness to own a system instead of rent one. We have built custom hospitality booking infrastructure for groups where it was the right call, and we have advised groups to stay on OpenTable when it was. This is how we run that decision.

When OpenTable, Resy, or SevenRooms is the right call

OpenTable's pitch is straightforward: connect to a network of millions of diners, get a reservation widget on your site, run your front-of-house off their host display. Resy is the more design-forward sibling. SevenRooms is the CRM-flavored one. Tock and Tablein and a handful of others compete in the same broad space.

The thing they have in common is that the booking primitive is the table at this restaurant on this night. Single venue, single resource type, single transaction shape. When that's what your business actually is, the off-the-shelf systems are excellent. They are battle-tested at volume, they handle the back-of-house staff workflow well, they integrate with the POS you probably already use, and the discovery network is a real distribution channel for restaurants where diners actually open the app.

The point at which they stop fitting is the point at which any of those primitives stops being singular.

What changes when the business isn't one restaurant

A boutique hospitality group launching a brand with a rooftop, a spa, an events venue, and a restaurant under one roof is not the same business as four standalone restaurants. The customer-facing experience is one brand. The booking surfaces overlap — a guest who books the spa might want to add dinner; an event lead converts to a room block; a rooftop reservation is fundamentally a different shape from a spa appointment.

Off-the-shelf systems handle this poorly because the data model wasn't built for it. You end up with:

• Four separate booking tools, four separate confirmation email templates, four separate "reply STOP to unsubscribe" footers from four vendors, none of which know about each other
• A guest experience where the same person enters their name and email four times to book four things at the same group
• An admin layer that requires a staffer to log into four different vendor portals to see the day's bookings across the property
• Reporting that lives in CSVs exported from four different sources and stitched together in Google Sheets every Monday morning

We've seen all of these in production. The cost isn't that any one of them is broken — it's that the friction compounds. The general manager spends a hundred minutes a week on admin glue work that an integrated system would absorb.

What custom buys you (specifically)

A custom booking system, built honestly, gives you four things off-the-shelf can't:

One data model. A bookings table with a venue_id and a booking_type (rooftop, restaurant, spa, event, room) is one query away from "how did the property do today" or "what are this guest's last five interactions with us." Off-the-shelf gives you four data models that don't compose.

One admin surface. A staffer signs into one CMS, picks a venue, sees the kanban for events, the day's covers for restaurant, the spa schedule, the rooftop list. Same login, same color system, same report shape. The training cost on a new front-desk hire drops measurably.

Brand control on the booking widget. OpenTable's widget looks like OpenTable's widget. That's a feature for OpenTable's brand, not yours. A custom flow lives inside your design system — the cinematic motion, the typography, the cursor — without a third-party iframe interrupting the experience.

Data ownership. Your guest list is yours. The marketing follow-up sequence runs on your CRM (or whatever you build), not theirs. When a vendor changes pricing or sunsets a feature, you're not exposed.

Comparison: custom build vs the four major off-the-shelf systems

Eight dimensions that tend to be load-bearing in real decisions.

| Dimension | Custom build | OpenTable | Resy | SevenRooms | Square | |---|---|---|---|---|---| | Multi-venue support | Native (one schema, one admin) | Per-venue (separate accounts) | Per-venue | Per-venue, group dashboards available on higher tiers | Per-venue | | Deposit / prepay capture | Native via Paystack/Stripe; arbitrary policies | Limited to specific events | Yes, via Resy Pay | Yes, varies by tier | Yes (Square Online) | | Resource-level scheduling (e.g. spa rooms, treatment chairs) | Native | Not supported | Not supported | Limited | Not supported | | Brand control on the booking flow | Full (your design system) | Their widget, your colors | Their widget, more visual control | Their widget | Their widget | | Data ownership | You | Shared (their network access) | Shared | Shared | You | | Per-transaction fees | Payment processor only (~2.4–2.9%) | $1 per network cover + subscription | Per-cover + subscription | Subscription | 2.6%+10¢ in-person | | Integration depth (POS, CRM, email) | Whatever you build | Strong restaurant POS integrations | Growing | Strongest CRM in category | Tightest with Square POS | | Kanban / pipeline workflows (events) | Native | Not in product | Not in product | Limited via tags | Not in product |

The honest read on this table: there is no row where custom can't match the off-the-shelf option. There are rows where the off-the-shelf option is so much cheaper to operate (POS integration with Square, network-driven inbound on OpenTable) that the labor of replicating it isn't worth it. The custom advantage shows up when several of the rows matter at once.

The decision framework we run with hospitality clients

Four questions, in order:

1. Is your booking primitive singular? If you run one restaurant, the answer is yes. If you run a group with even two of restaurant, rooms, spa, events, or rooftop, the answer starts becoming no, and the no gets sharper as the count grows. Singular booking primitive → off-the-shelf wins. Multiple → custom enters the conversation.

2. How much of your demand actually comes from the discovery network? Pull the last 90 days of reservations by source. If OpenTable / Resy is supplying more than 15–20% of bookings and your alternative would be paid acquisition at a worse CAC, the network fee is buying something real. If it's under 5%, you're paying for distribution you're not using.

3. Does your brand experience tolerate a vendor widget? This is a taste call, not a math call. Some operators legitimately don't care; the booking flow is utility, the experience is the room. Others do — the booking flow is part of the brand, and a third-party widget mid-flow breaks the spell. There is no right answer here, only a self-honest one.

4. Are you willing to own infrastructure? Custom means you own a system. Owning a system means deploys, occasional bugs, a hosting bill, and a partner who will keep it running. If you would rather pay a vendor and never think about it, that's a legitimate position; the cost is the trade-offs above.

What a custom build actually looks like in production

For a boutique luxury hospitality client (Lagos) with four venues under one brand, we shipped a Next.js 14 booking system with Supabase as the data layer. The shape:

• A venues table with row-level security so each venue's staff sees only their reservations
• A bookings table with a polymorphic relation to restaurant_bookings, spa_bookings, event_enquiries, and rooftop_bookings — each with its own type-specific fields, but all surfaced through a unified read view for the property dashboard
• An event_enquiries table that drives a kanban pipeline (New → In Discussion → Quoted → Confirmed → Completed) — workflow off-the-shelf can't model
• Paystack for NGN settlement on the Lagos property; Stripe for CAD/USD on the Toronto sister property; routing decision is geo-based at checkout
• A custom admin CMS at an admin subdomain, role-based access, multi-venue switcher, real-time dashboards
• The booking widget lives inside the brand's design system — same cinematic motion, same typography, same cursor — no third-party iframe

Build time was on the order of ten weeks of engineering across four venues, including admin, payments, RLS, and the kanban. Hosting on Vercel + Supabase runs in the low hundreds of dollars per month. The labor savings on the GM's weekly admin glue work alone are measurable; the brand-experience integrity argument is harder to quantify but the operator cared about it. The full case is anonymized at present pending client permissions — when those clear, the named flagship will live with all the receipts.

When you should keep OpenTable

If you operate a single restaurant, your reservations are roughly half-from-OpenTable and half-from-direct, your front-of-house is trained on the OpenTable host display, and your brand experience is the room and the food rather than the booking flow — keep OpenTable. The math doesn't favor a custom build at that profile. We'll tell you that if you ask us.

If you operate a multi-venue boutique group with rooms, spa, events, kanban needs, and a brand that has to feel like one thing — we'd rather build the system once, properly, and have you own it. The eighteen-month-ish payback math becomes obvious in the spreadsheet, and the brand-experience math becomes obvious the first time a guest finishes the spa booking and immediately starts the dinner booking on the same flow without re-entering their email.

What we'd ask before scoping anything

Three numbers and one taste call.

• Last 90 days of reservations, by source, by venue.
• Current vendor stack with monthly cost per venue.
• The labor estimate on weekly admin glue work — staff name, hours, what they're doing.
• The taste call: does your booking flow need to feel like your brand, or is it utility?

Once those are on the table, the right answer is usually visible inside an hour. If the right answer is OpenTable, we'll say so. If it's custom, we'll scope it.