How to Build an App Like OpenTable: Restaurant Reservations and Two-Sided Marketplace Architecture

OpenTable looks like a simple directory with a booking widget. Find a restaurant, pick a time, confirm your name. Done.

The simplicity is the product. What makes it hard to build is everything behind that simplicity: a two-sided marketplace where supply (restaurants) and demand (diners) both have separate products to build, real-time table availability that must be accurate across every channel simultaneously, and the operational reality that a single double-booking at a busy restaurant will kill the relationship.

This guide covers what to build, what to skip, and where the engineering is actually hard.

The two-sided marketplace problem

Every marketplace has two sides: supply and demand. Fail to serve either one well and the whole thing collapses.

For OpenTable:

Supply side (restaurants): They need a reservation management system that replaces or integrates with their existing hostess stand process. They need to set up their floor plan, define shift hours, configure covers per time slot, and see incoming reservations in real time. They also need reminders to go out to diners automatically, so they are not calling every reservation manually.

Demand side (diners): They need to find a good restaurant near them with availability on the date and time they want, book a table in under a minute, and get a confirmation they can reference when they show up.

The restaurant product and the diner product are roughly equal in scope. Teams that treat the restaurant dashboard as an afterthought ship a broken supply side, restaurants churn off the platform, and the diner app has no good listings. Every time.

The restaurant product: What you are building for supply

This is the part most product owners sketch on a napkin and underestimate in the sprint plan.

Restaurants need to configure their reservation system before a single diner can book. That means:

Shift setup

A shift is a service period: lunch service from 11:30am to 2:30pm, dinner service from 5:30pm to 10pm. Each shift has:

• Start and end times

• Table layout (which tables are in use, how many covers each seats)

• Slot interval (every 15 minutes, every 30 minutes)

• Covers per slot (how many total diners can be seated in each 15-minute window)

• Blackout dates (private events, holidays, closed days)

• Special hours for holidays or seasonal changes

This is the most underbuilt piece of first-generation reservation platforms. If the shift configuration is wrong, every downstream reservation is wrong.

Reservation list view

During service, the hostess or manager needs a clear view of all reservations for the current shift -- time, party size, diner name, and status (confirmed, arrived, seated, no-show). This view runs on a tablet at the host stand. It needs to work fast on poor WiFi. It needs large touch targets for a hostess managing a busy Friday night.

No-show tracking

A diner books a table and does not show up. The restaurant is left with an empty table that could have seated a walk-in. At scale, 15-25% no-show rates are common for free reservations. The restaurant dashboard needs one-tap no-show marking, and your system needs to track no-show history by diner account to identify repeat offenders.

Basic analytics

Restaurants want to know: how many covers are they getting through your platform per week? What is their busiest shift? What is their no-show rate? Basic analytics on the restaurant dashboard are a meaningful retention feature, especially when you are asking restaurants to pay a monthly fee.

The diner product: What you are building for demand

Restaurant search

Search by location (city, neighborhood, or current location via GPS), date, party size, and optionally cuisine type and price range. Results show available time slots for the requested date and party size -- not just a list of restaurants that happen to exist.

This means availability is computed at search time. If a restaurant has no availability for Saturday at 7pm for a party of 4, it does not show "Saturday 7pm" as an available option in search results. Showing unavailable slots and making the diner click through to find out is a broken experience.

Real-time availability by party size

Not all tables seat the same number of people. A table for 2 cannot seat a party of 6. Your availability engine needs to match requested party size to available tables within each slot. If a restaurant has 3 two-tops and 2 four-tops, and all two-tops are booked for 7pm, a party of 2 still has no availability at 7pm -- but a party of 4 might.

This logic runs every time a user changes their party size or date. The availability engine needs to be fast: sub-200ms response times for a search result page to feel instant.

Booking confirmation and reminders

When a reservation is confirmed:

1. Immediate email confirmation with restaurant name, date, time, party size, and a link to modify or cancel
2. SMS confirmation via Twilio with the same key details
3. SMS reminder 24 hours before the reservation: "Your table at [Restaurant] is tomorrow at 7pm for 4 people. Reply CANCEL to cancel."
4. SMS reminder 2 hours before the reservation on the day

These reminders reduce no-shows by 30-50%. They are not optional. Build them into v1.

Booking management

Diners need to view, modify, and cancel upcoming reservations. Cancellation should be instant and should immediately release the table slot back to availability so other diners can book it. This is a state machine: reservation states are pending, confirmed, modified, cancelled, completed, and no-show.

The real-time inventory problem

This is the hardest engineering problem in the platform.

A restaurant has 10 tables. Your platform shows availability. A diner on the mobile app and a diner on the web simultaneously try to book the last available 7pm slot for Saturday. Without proper database-level locking, both bookings go through. Now you have a double-booking.

The fix is a database-level lock on the reservation slot, not an application-level check.

When a diner begins the checkout flow for a specific time slot, your backend executes a SELECT FOR UPDATE query on that slot's row in the database. This locks the row for the duration of the transaction. Any concurrent request trying to book the same slot will wait until the transaction completes. If the first booking confirms, the slot is marked as booked. The second request then reads the slot as booked and shows an error.

If the first diner abandons checkout (closes the browser, payment fails), the transaction rolls back and the slot returns to available. Add a maximum lock duration (5-10 minutes) to prevent a session from holding a slot indefinitely.

This logic must run at the database layer. It cannot run in application code alone -- application-level checks can be bypassed by concurrent requests that start before either check completes.

Restaurant onboarding is the hard part

Technology does not solve the chicken-and-egg problem. You need restaurants to have diners. You need diners to attract restaurants. Which comes first?

Supply comes first. Always.

OpenTable solved this by going city by city, neighborhood by neighborhood. They would sign 10-15 restaurants on a specific street or in a specific neighborhood and make that neighborhood fully bookable before moving to the next. A diner who searches for "Italian restaurants in the West Village" sees complete, real inventory -- not a half-empty directory.

Your strategy for the first 3 months is not technology. It is sales. Get on the phone, visit restaurants, walk them through the dashboard. Offer free trials. The reservation management product is genuinely useful to restaurants even before you have diner traffic -- it replaces paper reservation books and cuts the number of phone calls they take for reservations.

Sign 10 restaurants in one neighborhood. Make the booking loop work perfectly for those 10. Then expand.

The business model decision: Per-cover vs. SaaS fee

OpenTable's original model charged restaurants per seated diner (per cover). OpenTable's cover charge was around $1 per diner seated through the platform. This worked well as volume scaled -- the more diners OpenTable drove, the more restaurants paid.

The problem: restaurants resent per-cover fees when the platform drives most of their traffic. They feel held hostage. Some of OpenTable's competitors (Resy, Yelp Reservations) moved to a flat monthly SaaS fee per restaurant instead.

Per-cover model: Revenue grows with volume. Lower upfront cost for restaurants. Restaurants pay more as you drive more value. Risk: restaurants try to book diners offline to avoid the fee.

SaaS model: Predictable revenue. Restaurants pay regardless of whether the platform drives traffic. Easier to upsell features. Risk: harder to justify the cost to a restaurant before you have proven diner volume.

For v1, the SaaS model is easier to sell. Restaurants know their monthly cost upfront. You do not need to track per-cover attribution (which requires knowing when a reservation was seated, which requires the hostess to mark it in your dashboard). Once you have traffic and can prove value, you can move to a hybrid model or add per-cover pricing for prime-time slots.

No-show charges and Stripe holds

The most effective tool against no-shows is a card hold. When a diner books, you place a hold (not a charge) on their card using Stripe. If they show up, you release the hold. If they do not show up and do not cancel within the cancellation window, you capture the hold as a no-show fee.

Stripe supports this through PaymentIntents with capture_method: manual. You create the PaymentIntent at booking time (hold placed), and either capture it (no-show fee charged) or cancel it (hold released) after the reservation time passes.

The no-show fee amount is set by the restaurant -- typically $15-$25 per person for high-demand restaurants. Your platform can take a cut (15-20%) of no-show fees collected.

This feature changes diner behavior immediately. No-show rates on card-hold reservations drop to 3-5% from 15-25%. Restaurants love it. Diners grumble once and then remember to cancel.

Add no-show charges as an optional restaurant feature in v1. Not all restaurants want it (casual bistros vs. Michelin-starred restaurants have very different needs). Let restaurants opt in.

Tech stack

What to skip in v1

Each of these is a real feature on OpenTable. None of them belong in your v1.

• Pre-ordering: Diners select dishes at booking time. Requires restaurant menu integration and kitchen coordination. Complex and rarely adopted by diners at v1 traffic levels.

• In-app payment: Full meal payment through the app. Requires point-of-sale integration or a separate check-settlement flow. Keep payments to no-show holds only in v1.

• Gift cards: A nice upsell but a distraction before you have booking volume.

• Loyalty points: Requires a points ledger, earn rules, and redemption logic. Build after you can prove booking retention.

• Experiences: Special-event dining, chef's tables, cooking classes. A different product category with different inventory setup.

• Concierge service: Human-assisted booking for special occasions. A service layer, not a technology problem. Add when you have the operational capacity.

• Waitlist management: Digital waitlist for walk-ins. Useful but separate from the core reservation flow. Build in v2.

Get the core booking loop working perfectly: diner searches, finds availability, books, gets a reminder, shows up. That is the entire v1 mandate.

Cost to build

Monthly operating costs once live: $1K-$5K covering Twilio SMS, Google Maps API, email delivery, Stripe fees, and hosting. At scale (100K+ reservations per month), SMS costs alone can run $2K-$4K/month.

How RaftLabs approaches this

Restaurant reservation platforms fail most often for one of two reasons. Either the restaurant dashboard is too complex for hostesses to use in a busy service, or the supply-side onboarding never gets past 20 restaurants because the team spent all their time on the consumer app.

We build the restaurant dashboard and the diner app in parallel, with equal weight on each. The dashboard has to be usable on a 10-inch tablet in a dim room with a distracted hostess. That is not a design afterthought.

We also push founders to solve the supply-side problem before they write code. Who are your first 10 restaurants? Do you have relationships? Are you targeting a specific neighborhood or cuisine category? The product architecture follows from those answers.

If you want to understand the full cost breakdown for your specific concept -- whether it is a neighborhood reservation platform, a corporate dining tool, or a white-label reservation system for a restaurant group -- start with a scoping call.