How to Build an App Like GetYourGuide (Tours and Activities Booking)

GetYourGuide processes more than 1 million bookings a year. The platform takes 20-30% commission on every activity. That is a strong business model -- but the platform itself is not the opportunity.

The opportunity is vertical. A destination management company that curates local food tours, cooking classes, and market visits. A hotel group that offers in-house activity booking for guests and keeps the commission inside the property. A corporate event operator that manages team-building experiences across multiple outfitters. An adventure sports company that aggregates bookings for climbing, kayaking, and cycling tours in a specific region.

These are all the same technical problem. This guide covers how to build it.

Who actually builds this

Destination management companies (DMCs) sell curated local experiences to inbound travelers. A DMC in Lisbon may work with 40 local operators: boat tours, food walking tours, tuk-tuk rides, wine tastings. A platform lets them aggregate all those offerings in one booking interface, capture the customer relationship, and take a commission.

Hotel groups want to offer in-house activity booking for guests without sending them to a third-party app. A resort with 800 rooms can book surf lessons, snorkeling tours, and cooking classes directly through the hotel's digital platform. The hotel keeps the commission. The guest never leaves the brand experience.

Corporate event platforms manage team-building experiences for company offsite events. The buyer is an HR or events manager. The activities are cooking competitions, escape rooms, city scavenger hunts, and outdoor challenges. The platform connects event managers with experience operators and handles group bookings with custom invoicing.

Adventure sports operators booking for multiple outfitters. A regional outdoor sports company that works with 12 independent climbing guides, 8 kayaking operators, and 6 cycling tour companies needs a single booking platform that manages availability across all of them and routes payouts correctly.

Cruise lines booking shore excursions. Passengers book excursions before or during the cruise. The platform connects cruise itinerary data with local experience operators at each port.

Experience listing data model

Each activity listing needs two types of data: what the activity is, and when it is available.

The what: activity name, category (food tour, museum visit, outdoor sports, water sports, cultural experience, team-building), description, meeting point (an address plus a Google Maps pin), duration, what is included (transport, equipment, meals, entrance fees), what guests should bring, difficulty level, age restrictions, minimum and maximum group size, photos, and cancellation policy.

Cancellation policy needs structured data, not a text block. The booking system needs to evaluate whether a refund applies based on the time between cancellation and the activity date. A common policy: full refund if cancelled 48 hours before the activity starts, 50% refund if cancelled 24 hours before, no refund inside 24 hours. Store this as rules with thresholds, not a paragraph.

CREATE TABLE activities (
  id                UUID PRIMARY KEY,
  operator_id       UUID REFERENCES operators(id),
  title             VARCHAR(255) NOT NULL,
  category          VARCHAR(100),
  description       TEXT,
  meeting_point     TEXT,
  latitude          DECIMAL(9,6),
  longitude         DECIMAL(9,6),
  duration_minutes  INT,
  min_group_size    INT DEFAULT 1,
  max_group_size    INT,
  difficulty        VARCHAR(50),
  cancellation_policy JSONB,
  status            VARCHAR(50) DEFAULT 'active'
);

Availability and capacity: the hardest part

This is where most first-time builds go wrong.

Each activity runs on time slots. A food walking tour runs at 10 AM and 2 PM daily. A private boat charter is available at 9 AM and 1 PM on weekdays, 8 AM and 12 PM on weekends. A museum night tour runs Friday and Saturday at 7 PM only.

Each slot has a capacity. The 10 AM food tour holds 12 people. When 12 people have booked, the slot is sold out and disappears from the booking calendar.

You need three inventory states: available (slots remaining), limited (fewer than 3 slots remaining, show urgency), and sold out.

The booking flow must decrement inventory in real time. When a customer selects a slot and moves to checkout, you need to hold that inventory for the duration of the checkout session (typically 10-15 minutes). If the customer abandons checkout, release the hold. If the customer completes payment, confirm the booking and permanently decrement the slot count.

This is a classic inventory reservation problem. Implement it with a bookings table that has a status column (hold, confirmed, cancelled) and a hold expiry timestamp. A background job releases expired holds every 5 minutes.

CREATE TABLE slots (
  id          UUID PRIMARY KEY,
  activity_id UUID REFERENCES activities(id),
  starts_at   TIMESTAMPTZ NOT NULL,
  capacity    INT NOT NULL,
  booked      INT DEFAULT 0
);

CREATE TABLE bookings (
  id          UUID PRIMARY KEY,
  slot_id     UUID REFERENCES slots(id),
  customer_id UUID,
  party_size  INT NOT NULL,
  status      VARCHAR(50) DEFAULT 'hold',  -- hold, confirmed, cancelled
  hold_until  TIMESTAMPTZ,
  created_at  TIMESTAMPTZ DEFAULT NOW()
);

A slot is available when capacity - booked > 0. When a booking is confirmed, increment booked. When a booking is cancelled, decrement booked.

Pricing models

Per-person pricing is the default: $45 per adult for a food tour. The platform multiplies by party size at checkout.

Group pricing sets a flat rate for up to a fixed number of people: $350 for groups of 1-8. Larger groups need a separate booking or a custom quote. Some operators prefer this because it reduces the friction of pricing for smaller group sizes.

Tiered pricing uses different rates for different guest categories: adult $55, child (under 12) $30, senior (65+) $45. This is common for activities with age-based pricing or attractions with student discounts.

Private tour pricing offers the full activity exclusively for a specific group at a premium: $480 for a private food tour for up to 10 people. The customer pays more; the operator guarantees the slot for their group only.

Store all pricing as a price table linked to the activity. The booking checkout resolves which pricing tier applies based on guest inputs.

The commission model and Stripe Connect

This is the payment architecture that every marketplace needs and most first-time builders underestimate.

Two commission models exist. In the net rate model, the operator sets the price they want to receive (say, $36 per person). The platform marks up to the customer price ($45 per person) and keeps the $9 difference. The customer sees $45. The operator expects $36.

In the retail model, the operator sets the public price ($45 per person). The customer pays $45. The platform deducts its commission (20%) and sends the operator $36.

Both models use the same Stripe Connect architecture. The customer's payment hits the platform's Stripe account. On payout day (weekly, or after activity completion), the platform transfers the operator's net amount to their connected Stripe account and keeps the commission.

Stripe Connect has two modes: Express (faster operator onboarding, Stripe handles the payout UI) and Custom (full control over the payout experience, more development work). Start with Stripe Connect Express for v1.

The operator onboarding flow is not trivial. Operators need to complete Stripe KYC (identity verification, bank account connection). Plan for 2-3 weeks of development time just for the onboarding flow, error states, and webhook handling.

The booking flow

The customer booking flow has five steps.

Pick the activity and date. The calendar shows available dates highlighted, sold-out dates greyed out, and limited availability dates with a soft indicator. This calendar pulls availability in real-time from your slots table.

Pick a time slot. The customer sees all available slots for the selected date with remaining capacity.

Select party size. The customer enters how many adults, children, and seniors (if the activity has tiered pricing). The system calculates the total price.

Add contact details. First name, last name, email, and phone number. For group bookings, the contact person is the lead guest.

Checkout. Stripe payment form. On successful payment, the booking status changes from hold to confirmed. A confirmation email with the QR voucher goes out immediately.

Two confirmation modes: instant confirmation (most activities) and request-to-book (some operators want to approve bookings before confirming, common for private tours or activities with specific requirements). For request-to-book, the customer is charged only when the operator approves. The operator has 24 hours to approve or decline. A decline triggers a full refund.

Voucher generation and delivery

When a booking is confirmed, generate a QR code containing the booking ID. The QR code is the customer's proof of purchase and entry ticket.

Deliver the voucher two ways: embedded in the confirmation email as an image, and available in the customer's booking confirmation page in their account.

The QR code content is a booking reference, not a URL. When the operator scans it with their mobile app, the app looks up the booking ID in the platform API and confirms the booking details: activity name, date, time, party size, and customer name. The operator sees confirmation on screen and marks the booking as attended.

Use the qrcode npm package for QR generation. Generate a PNG and embed it base64 in the email template. Also generate a downloadable PDF version for operators who print vouchers for their records.

Operator dashboard

Operators need five tools: calendar management, booking list, payout tracking, listing management, and customer communication.

The calendar view shows upcoming slots, bookings per slot, and available capacity. The operator can block out dates (for a private event or maintenance), add new slots, and update capacity limits.

The booking list shows all upcoming bookings in chronological order with customer name, group size, activity, and date. The operator can export this list before each tour to brief their guides.

Payout tracking shows the operator's pending and completed payouts, with a breakdown of each booking's contribution. Stripe Connect provides the payout history; your dashboard surfaces it clearly.

Listing management lets the operator update photos, description, meeting point, and pricing. Price changes take effect for new bookings only -- existing confirmed bookings are not affected.

Customer communication lets the operator send a message to a booked customer (meeting point reminder, weather update, what-to-bring instructions). This is not a full messaging system -- it is a one-way notification tool for the operator before the activity date.

Voucher validation mobile app

The operator needs a mobile app to scan vouchers at the meeting point. This is not optional -- it is what closes the booking loop and confirms customer attendance.

Build this in React Native so it runs on both iOS and Android. The operator logs in with their operator credentials. They open the scanner, point at the customer's QR code, and the app calls your API to validate the booking.

The API response returns: valid or invalid, activity name, date, time, party size, and customer name. If valid, the app shows a green confirmation screen. If invalid (wrong date, already scanned, cancelled booking), the app shows a red screen with the error reason.

Mark scanned bookings as attended in your database. This data is useful for operators to track no-shows and for your platform to calculate activity-level no-show rates.

Reviews: post-activity only

Send a review request email two days after the activity date. Not before. A customer who has not done the activity yet cannot review it.

The review is simple: 1-5 stars and a short text write-up. No photos in v1. Require a minimum of 3 review text characters to prevent blank star submissions.

Set a minimum review threshold before an activity appears in ranked search results. An activity with 1 review cannot game your rankings with a single 5-star submission. Require at least 5 reviews before the activity is ranked by rating.

Activities with 4.8+ stars rank first in category search within your platform. Activities below 3.5 stars after 20+ reviews get a review flag and an operator notification.

Automate the review request email via SendGrid. Send it at 10 AM local time on the second day after the activity. Include a direct link to the review form -- do not require the customer to log in to leave a review.

Tech stack

React for the customer-facing booking web app and operator web dashboard. React Native for the operator voucher-scanning mobile app (iOS and Android from one codebase). Node.js for the backend API. PostgreSQL for activities, slots, bookings, and operators. Stripe Connect for customer payments and operator payouts. The qrcode npm package for voucher QR generation. Google Maps API for meeting point display on activity pages. SendGrid for booking confirmation and voucher emails. Redis for caching availability data on high-traffic activity pages.

Two optional additions worth considering for v1: Twilio for SMS voucher delivery (some customers prefer SMS over email), and AWS S3 for activity photo storage (operator-uploaded photos need a reliable CDN, not local file storage).

Timeline and cost

A production-ready v1 for a single-niche experience marketplace takes 12-16 weeks with a team of 5-6.

Weeks 1-3: data model, activity listing, and operator onboarding. Weeks 4-6: availability calendar and slot inventory management. Weeks 7-9: customer booking flow, payment integration, and Stripe Connect payout logic. Weeks 10-11: QR voucher generation, confirmation email, and SendGrid templates. Weeks 12-13: operator web dashboard (calendar, booking list, payout view). Weeks 14-15: React Native voucher scanning app. Week 16: QA, load testing the availability decrement logic, and launch prep.

Cost: $120K-$180K for a production-ready single-niche v1. Add a native customer iOS or Android app (separate from the web experience) for an additional $40K-$60K. Add corporate group billing (invoicing instead of card payment, purchase order support) for another $20K-$30K.

The Stripe Connect setup is typically 3-4 weeks of engineering work, not 1. The operator onboarding KYC flow, webhook handling for payout events, and the dispute management process all take more time than first estimates suggest.

What to skip in v1

Gift cards: a common feature request, but gift card redemption adds payment flow complexity. Add in v2 when you have a clear gift occasion use case from real users.

Waitlists: useful when activities sell out regularly. On a new platform, you need data on which activities actually sell out before building the waitlist logic.

Dynamic pricing: charging more for peak-time slots or last-minute availability. This is a revenue optimization for established platforms. Build it when you have 6+ months of booking data.

Multi-currency display: if your platform is regional, single-currency is fine for v1. Add currency conversion when you have confirmed demand from international customers.

The real work before you write code

Before the platform is useful, you need supply. A booking platform with 5 activities listed is not useful to customers. You need a minimum viable supply density -- at least 20-30 activities in your niche -- before you launch customer acquisition.

This means operator sales work before the platform is built. Sign up your first 10-15 operators early. Run their availability and bookings manually (via spreadsheet or email) while the platform is in development. On launch day, migrate those bookings into the platform and go live with a real supply base.

RaftLabs has built booking platforms, availability management systems, and marketplace products for hospitality and experience operators. If you have a niche and a target operator set in mind, one conversation is enough to scope what Phase 1 looks like.