The case for custom over off-the-shelf in hospitality
OpenTable is excellent at one job: handing a single-venue restaurant a reservation widget plus access to a discovery network. Square is excellent at one job: handing a venue a POS that runs reliably. Mindbody is excellent at one job: scheduling a salon or studio. None of them are excellent at the job boutique hospitality groups actually need, which is one brand experience across rooms, restaurant, spa, and events that share a guest, a payment trail, and an admin layer.
We have built this system for a boutique luxury hospitality client (Lagos) with four venues under one brand. The friction the operator was feeling before the build was not "OpenTable is bad" — OpenTable was fine in isolation. The friction was that four fine-in-isolation tools produced four sets of confirmation emails, four guest records for the same person, four admin portals to log into, and a Monday-morning ritual of stitching CSVs together because nothing was joinable in one query. The labor cost compounded. The brand-experience cost compounded faster.
The case for custom is not "off-the-shelf is broken." It's that there exists a class of operator — multi-venue boutique groups with brand-experience expectations and operational complexity — for whom one well-shaped data model and one admin layer is measurably cheaper to operate over an eighteen-month horizon than four well-shaped vendor stacks. Whether your operation is in that class is an audit, not a debate. We help you run the audit. If the answer is custom, we build it. If the answer is not custom, we tell you that too — there is a longer piece on exactly when off-the-shelf wins.
What we ship for hospitality
Seven specific deliverables. Not "digital transformation" — these are the actual systems we build, the actual technology choices, the actual scope.
Multi-venue brand site
Cinematic motion (GSAP, ScrollTrigger, Lenis) on a Next.js 14 base. One brand across rooftop, restaurant, spa, and events without four separate microsites.
Custom unified booking
One Supabase backend, per-venue forms, one guest record. Restaurant covers, rooftop reservations, spa appointments, event enquiries — all queryable in one place.
Spa scheduling with deposits
Paystack or Stripe deposit capture at submission. Resource-aware scheduling (therapist + room + treatment-specific equipment). Cancellation policy enforced as code.
Event enquiry kanban
Pipeline: New → In Discussion → Quoted → Confirmed → Completed. Audit trail per movement. The system of record for the multi-step sales conversation.
Branded admin CMS
Multi-venue switcher, role-based access via JWT, real-time dashboards. One login for the GM, the spa director, the events team — different views per role.
Local SEO + GBP build-out
Restaurant + Menu + LocalBusiness schema, weekly Google Posts cadence, review-response discipline, photo strategy. One playbook applied per venue.
AI concierge chatbot
Trained on the property's policies, menus, and FAQ. Handles guest questions, reservation enquiries, upsell suggestions. Hands off to staff on out-of-scope.
The shape of the system
The actual architecture we ship for a multi-venue boutique hospitality group. Same shape across builds; the venues, the integrations, and the AI surface vary.
One Next.js front end, one Supabase database with row-level security per venue, one admin CMS, payments routed by region. The AI concierge reads from the same data model the booking forms write to.
How we think about the boutique hospitality stack
Eight questions every multi-venue operator we talk to asks within the first hour, answered as we'd answer them across the table. No theory. No "in today's competitive landscape." The actual calls, the actual numbers where we have them, the actual ranges where we don't.
What does a custom booking system actually cost?
A single-venue restaurant booking sits in the $14K–$32K CAD range to build, with hosting at roughly $40–$120 per month. A multi-venue group spanning rooftop, restaurant, spa, and events together is typically $32K–$65K CAD. The math against off-the-shelf is OpenTable's per-cover fees plus per-venue subscriptions, summed across all venues, summed across eighteen months — that's the comparable. Most multi-venue groups cross the break-even inside roughly eighteen months. Single restaurants don't.
Off-the-shelf hospitality software charges in three patterns: per-cover (OpenTable), per-subscription (SevenRooms, Mindbody), and per-transaction (Square, Resy Pay). For a single restaurant doing 200 covers a night, OpenTable's roughly $1-per-cover network fee plus subscription is $250–$500 per month per venue. Reasonable. For a four-venue boutique group with 600+ covers a night across the property, plus spa subscriptions at $300–$700 per month, plus events handled in spreadsheets because no off-the-shelf models the sales pipeline — the monthly run-rate climbs above $2K and doesn't count the GM's 6+ hours a week of glue work.
Custom-build math is different in shape. The build itself is capex; the run-rate is hosting (Vercel + Supabase, low hundreds of dollars a month) plus the payment processor's standard 2.4–2.9% on transactions. The build pays for itself when the avoided vendor subscriptions plus the recovered GM hours exceed the amortized build cost. For multi-venue boutique groups we've seen this break at month 14–22.
How long does a multi-venue hospitality build take?
Single-venue restaurant booking ships in four to six weeks of focused engineering. A multi-venue group with the four standard surfaces — rooms, restaurant, spa, events — takes eight to fourteen weeks depending on integration depth. The first week is exclusively the data model. Spending one week getting that shape right saves roughly four weeks of refactor over the project's first year.
The variance in timeline is integrations, not feature scope. A build that has to integrate with an existing PMS (Opera, Mews, Cloudbeds) for room availability runs longer than a greenfield. A build that has to migrate guest history from a legacy CRM runs longer. A build that just lives inside its own data model, talks to Stripe and Paystack, and produces a clean admin — that's the shorter side.
The week-one data-model session is the load-bearing call. We cover this in detail in the multi-venue architecture piece — short version: one Postgres database, row-level security per venue, unified bookings table with type-specific extensions, kanban for events. The pattern composes; the alternatives don't.
What does the data ownership argument actually mean in practice?
Data ownership in hospitality means three things: the guest list lives in your database, the marketing follow-up runs on infrastructure you control, and a vendor's pricing change cannot strand your operations. Off-the-shelf systems share the guest record with their network; custom systems put the record entirely under your control. The practical test: can you, today, export every guest who has interacted with any venue in your group, with their full interaction history, in one CSV? If yes, you own the data. If you have to ask permission, you don't.
The export test sounds trivial. It isn't. Most multi-venue groups we've talked to fail it. Their guest data is split across OpenTable's network, Square's customer directory, the spa software's local database, and a Mailchimp list that Karen-from-marketing built three years ago. "All my guests" doesn't exist as a query.
The ownership argument is also a vendor-risk argument. When a hospitality SaaS vendor gets acquired and changes its pricing, or sunsets a feature, or has a regional outage, the cost lands on you. Owning the system means you absorb the cost of maintenance and gain the option of changing course. That's a trade-off, not a free lunch. For groups whose brand integrity is core to the business, the trade-off pays.
How does an AI concierge fit into a boutique hospitality stack?
An AI concierge sits on top of the property's data model — the same booking, guest, and policy data the human staff use. It handles guest-facing queries that don't require human judgment (hours, menus, policies, room amenities, basic booking), hands off to staff on out-of-scope or VIP signals, and writes its conversation history back to the guest record. The build sits in the $8K–$40K CAD range depending on integration depth. We cover the architecture in detail in the AI concierge cornerstone.
The cheap version of "hotel chatbot" is an FAQ widget. It answers policy questions from a static knowledge base. That's a few weeks of work and a $200/month API bill. The expensive version is a booking-capable concierge that checks live availability, makes reservations, modifies bookings, and reads from the property's PMS. That's a $25K–$40K CAD build with a $500–$1,200 monthly API and integration cost.
The middle ground — and the one most boutique groups should start with — is a concierge that answers from the knowledge base, hands off booking intent to the live booking flow with context preserved, and writes the conversation back to the guest record. That's the architecture we cover in the AI concierge cornerstone.
Which integrations matter most: payments, CRM, POS, or channel managers?
In order: payments first, then POS, then CRM, then channel managers. Payments is the conversion surface — a broken payment integration kills revenue at the moment of intent. POS is operational continuity — it's where the front-of-house staff live. CRM is the marketing follow-up, important but not blocking. Channel managers matter at scale; most boutique groups can run direct-only at first and add OTA channels as room volume justifies the rev-share tax.
The order matters because the ROI of each integration is non-linear. A working payment flow is non-optional — every booking goes through it. A broken POS integration is painful but recoverable; staff fall back to manual until it's fixed. A missing CRM integration is invisible to operations but eventually shows up as poor returning-guest engagement. A missing channel manager integration is tolerable until OTA traffic crosses 20% of room volume, at which point the math flips.
We default to Stripe + Paystack on payments, the property's existing POS at integration time (Square, Toast, Lightspeed are the common ones), and the CRM as a downstream of the guest record rather than a primary system. Channel manager integrations are case-by-case.
When should we keep our existing system instead of rebuilding?
Keep when the friction is operational, rebuild when the friction is architectural. A working OpenTable plus a working POS plus a working spa scheduler is not broken if the GM is not drowning in glue work. The trigger that says rebuild is when a single human at the property is reconciling four spreadsheets every Monday because no system talks to another. Until that signal, custom is overhead. After it, custom is the path back to sanity.
The diagnostic question we ask first is: walk me through how you produce the weekly group-level revenue report. If the answer involves four logins, manual CSV exports, and a Google Sheet stitched together in someone's spare time, the system-of-record is the spreadsheet, not any of the vendors. That's the architectural-friction signal.
The follow-up question: how does a returning guest get recognized across venues? If the answer is "they don't, unless the host happens to remember them," cross-venue customer identity isn't a system feature, it's tribal knowledge. A custom system makes it a query.
Two yes-es and the rebuild conversation is worth having. One yes is borderline. Zero, the existing stack is fine; spend the budget elsewhere.
What does the launch process actually look like?
Two-phase rollout, not big-bang. Phase one: brand site and admin CMS go live; the existing booking systems stay in place. Phase two, two to four weeks later: the new booking system replaces the old one, with overlap so reservations made before cutover are honoured. We don't ship single-day cutovers on production hospitality systems — the cost of a quiet bug at the booking layer is too high for a venue that can't take outages on a Friday night.
The phased approach has two payoffs. The first is the brand-site launch is unblocked from the booking-system launch; the new property look-and-feel can go live on schedule even if the booking system needs another week. The second is real user behaviour can be observed on the new admin CMS before the booking system depends on it — if a venue manager flags an admin UX issue, we have time to fix it before the booking flow is feeding the admin.
The cutover itself is a Tuesday morning, never a Friday. New bookings flow into the new system; existing bookings made on the old system are honoured against a read-only export until the last one is consumed. Old vendor accounts stay billed for one more cycle as a safety net, then cancel.
How do you handle multi-currency for properties spanning regions?
Geo-first at first paint, with manual override. North American visitors see CAD or USD, routed to Stripe. West African visitors see local currency, routed to Paystack on local rails. Both gateway tables write to the database; a unified read-side view joins them for reporting. The full technical breakdown lives in our build log entry on multi-currency hospitality booking.
The architecture is two narrow tables (one per gateway), one read-side view that unions them, and a routing decision at checkout based on currency. We tried single-table-with- discriminator first and it produced unmaintainable RLS policies; the two-table pattern composes cleanly with per-venue isolation and webhook idempotency.
Currency display is server-rendered on first paint using the Vercel Edge geo header — no flicker, no client-side currency swap that visibly re-renders the price. Manual override is available; the system trusts the override but logs it for fraud-pattern analysis in case a single user is repeatedly switching currencies in suspicious ways.
Custom build vs the four major off-the-shelf systems
Eight dimensions, summarised. The longer version with the decision framework lives in the why-not-OpenTable piece.
| Dimension | Custom | OpenTable | Resy | SevenRooms | Square |
|---|---|---|---|---|---|
| Multi-venue support | Native — one schema, one admin | Per-venue accounts | Per-venue | Group dashboards on higher tiers | Per-venue |
| Deposit capture | Native, arbitrary policies | Limited to specific events | Yes (Resy Pay) | Yes, varies by tier | Yes (Square Online) |
| Resource scheduling (spa rooms) | Native | Not supported | Not supported | Limited | Not supported |
| Brand control on booking flow | Full — your design system | Their widget, your colors | Their widget, more control | Their widget | Their widget |
| Data ownership | Yours | Shared with their network | Shared | Shared | Yours |
| Per-transaction fees | Processor only (~2.4–2.9%) | $1/cover + subscription | Per-cover + subscription | Subscription | 2.6% + 10¢ in-person |
| Kanban event pipeline | Native | Not in product | Not in product | Limited via tags | Not in product |
| Integration depth | Whatever you build | Strong restaurant POS | Growing | Strongest CRM | Tightest with Square POS |
Boutique luxury hospitality client, Lagos
The problem. A multi-venue brand launching in June 2026 needed a unified booking surface, an admin layer that handled all four venues from one login, and a brand site that felt like one experience across the whole property. The clock was real — the launch date was fixed, the venues were under construction, and the system had to be running before the first guest walked in.
The architecture. Next.js 14 on Vercel for the brand site and the booking flows. Supabase as the data layer with row-level security per venue. Paystack for NGN settlement on Lagos venues; Stripe for CAD and USD on the Toronto sister property. A custom CMS at an admin subdomain, role-based access via JWT, real-time dashboards. A kanban event pipeline for the events venue. Resend for transactional email; the AI concierge stub running on a knowledge base compiled from the property's policies and menus.
The build philosophy. No off-the-shelf where it compromises brand or data ownership. The booking widget lives inside the brand's design system — the cinematic motion, the typography, the cursor — without a third-party iframe interrupting the experience. The full technical case study is anonymized at present pending client permissions; the named flagship will live with all the receipts when those clear.
What's visible publicly. The brand site's cinematic motion system (GSAP + ScrollTrigger + Lenis), the booking drawer with four tabs (rooftop, spa, events, restaurant) reading from the unified Supabase availability view, the cursor and motion transitions specific to the brand. The system supports the same patterns we ship across hospitality builds — what's specific to this client is brand-specific, not architecturally novel.
Deeper reading
Four pieces that go further on the technical and operational questions a multi-venue hospitality operator runs into.
Local SEO and Google Business Profile Playbook for Boutique Restaurants
Practical, step-by-step Google Business Profile and local SEO playbook for boutique restaurants — verification, categories, photos, posts, review responses, schema markup, and the moves that compound.
Read pieceArchitecting a Multi-Venue Hospitality Platform: One Brand, Four Properties, One Admin
How DOTxLabs structures the data model, row-level security, and admin layer for boutique hospitality groups running rooms, spa, events, and restaurants under one brand. Patterns from real builds.
Read pieceSpa Booking Systems That Actually Work: Deposit Capture, Resource Scheduling, and No-Show Prevention
How DOTxLabs designs spa booking flows with deposit capture, therapist + room resource allocation, and cancellation-policy enforcement. Real patterns, real trade-offs, no fabricated numbers.
Read pieceWhy We Build Custom Booking Systems for Boutique Hospitality (and When OpenTable Is the Right Call)
An honest look at when custom booking infrastructure pays for itself in boutique hospitality — and when OpenTable, Resy, or SevenRooms is the smarter buy. Trade-offs across eight dimensions.
Read pieceThe Boutique Hospitality Tech Stack Audit Checklist
Twenty-five questions an operator can self-run on their current stack — booking, admin, local SEO, brand site — with a "what to consider if you answered no" follow-up on every item. Ungated. Print-ready. Real instrument we use before we propose a build.
Frequently asked questions
Twelve questions multi-venue hospitality operators ask us within the first conversation.
What does a custom hospitality booking system actually cost?
A single-venue booking system, fully custom, sits in the $14K–$32K CAD range for the build, with hosting and infrastructure running roughly $40–$120 per month. A multi-venue group with rooftop, restaurant, spa, and events together typically scopes between $32K and $65K CAD. Off-the-shelf systems are cheaper to start and more expensive to operate at multi-venue scale once per-cover fees and per-vendor subscriptions are summed; custom usually pays back inside roughly eighteen months for groups.
How long does a multi-venue hospitality build take?
Single-venue restaurant booking is four to six weeks of engineering. Multi-venue group with rooftop, restaurant, spa, and events together is eight to fourteen weeks depending on integrations and admin scope. The first week is exclusively scoping the data model — getting that wrong is what makes booking systems painful to live with for the next two years.
Do you build for hospitality groups outside Toronto?
Yes. We have shipped boutique hospitality builds spanning multiple regions, including Toronto and Lagos. The build is the same; the integrations vary — Stripe and Square in North America, Paystack in West Africa, region-appropriate channel managers and POS systems where they exist. Geo doesn't constrain the architecture.
Can an AI concierge actually make reservations, or is it FAQ-only?
Both shapes ship. A FAQ-only concierge is a few weeks of work and answers policy and property questions; it lives in the $8K–$15K CAD range. A booking-capable concierge with PMS or property-data integration is $15K–$40K CAD depending on the integration depth — it checks availability against the property's booking system, presents options, and either completes the reservation or hands off to a PCI-compliant payment flow.
What integrations matter most: payments, CRM, POS, or channel managers?
In order: payments first, then POS, then CRM, then channel managers. Payments because the booking flow is the conversion surface and a broken payment integration kills revenue at the moment of intent. POS so the front-of-house staff see consistent guest data. CRM for the marketing follow-up. Channel managers last — they matter at higher room counts but most boutique groups can run direct-only at first and add channels as room volume justifies the rev-share.
When should we keep our existing system instead of rebuilding?
When the existing system is doing the job and the friction you feel is operational, not architectural. A working OpenTable plus a working POS plus a working spa scheduler isn't broken if the GM isn't drowning in glue work. The signal that says rebuild is when the same human is reconciling four spreadsheets every Monday because no system talks to another. Until then, custom is overhead, not value.
What does the launch process look like?
Two-phase rollout. Phase one: brand site and admin CMS go live; existing booking systems stay in place. Phase two, two to four weeks later: the new booking system replaces the old one, with overlap so reservations made on the old system before cutover are honoured. We don't ship big-bang launches on production hospitality systems; the cost of a quiet bug at the booking layer is too high.
How do you handle multi-currency for properties across regions?
Currency is determined geo-first at first paint, with manual override available. North American visitors see CAD or USD, routed to Stripe. Visitors in Nigeria, Ghana, and South Africa see local currency, routed to Paystack on local rails. The hospitality group sees a unified read-side view that joins both gateway tables for reporting. The deeper technical breakdown lives in our build log.
Do you take ongoing maintenance or hand it off?
Either model works. Most groups run a maintenance retainer with us covering hosting, security patches, occasional feature work, and on-call for production issues — typically $1.5K–$4K CAD per month depending on scope. Some groups bring engineering in-house and we hand off with documentation and pairing sessions. We don't lock the code; the system is yours regardless of who maintains it.
How do you protect guest data across venues without locking it down too tightly?
Postgres row-level security is the load-bearing primitive. Per-venue staff see only their venue's bookings via JWT-encoded venue IDs; group owners and the operator see everything; the guest record itself is cross-venue so returning-guest detection works. The policies are tested in CI on every PR — a regression in the security boundary fails the build.
What if we already have a half-built custom system from a previous agency?
We work from where you are. The first move is a Stack Diagnostic — we audit what exists, identify what's salvageable, and scope what needs replacing. Sometimes the right answer is finishing what's there with a new direction; sometimes it's a clean rebuild. We tell you which one we'd recommend and why, and the diagnostic is its own deliverable regardless of whether you proceed with the larger build.
Is the data and the code actually mine?
Yes. The repo is yours, hosted on your GitHub or GitLab. The Supabase project is yours, billed to your account. The domain and Vercel deploy are yours. We retain no kill-switch, no proprietary lock-in, no per-seat fees on systems we built. If you part ways with us, the system keeps running and any other engineering team can pick up the codebase. That's the data-ownership argument made literal.