How to Build an App Like Expedia: Travel Aggregation, APIs, and Real Costs

You are not building an airline. You are not building a hotel chain. Expedia does not own a single seat or a single room. What Expedia built is a search engine and booking layer that sits on top of inventory owned by thousands of airlines and hotels. That distinction changes what you actually need to build.

Most founders scoping an Expedia-like platform are not trying to replace Expedia globally. They are building something focused: a travel booking tool for corporate clients, a niche OTA for adventure tourism, or a white-label booking engine for a hospitality group. That focus is a strength. Expedia's breadth is also its liability -- it cannot optimise deeply for any single audience.

Monthly API costs once live: $2K-$15K depending on search volume and booking conversion, covering GDS query fees and payment processing. Budget these as a percentage of gross booking value, not a fixed monthly cost.

What Expedia actually is

Expedia is an aggregation and distribution layer, not a travel supplier. It connects supplier inventory (flights, hotels, car rentals) to consumers who want to compare and book. Expedia earns money in the middle.

According to Phocuswright's 2024 US Online Travel Overview, online travel agencies now control about 39% of global hotel bookings. That dominance is why hotel chains and airlines spend billions on direct-booking campaigns -- they are trying to recover the commission margin that OTA platforms capture.

Expedia Group runs multiple brands -- Expedia, Hotels.com, Vrbo, Orbitz, Travelocity -- all on the same core: a meta-search and booking engine that aggregates supplier inventory into a unified search experience.

When you build an Expedia-like platform, you are building five things:

1. A connection layer to supplier APIs (flights, hotels, cars)
2. A search and filtering interface on top of that inventory
3. A checkout flow that processes bookings through the supplier
4. An itinerary management system that tracks bookings across suppliers
5. A user account layer for saved preferences and booking history

You are not building the inventory. You are building everything around it.

Who builds a travel aggregation platform instead of using Expedia

Three types of businesses regularly build their own OTA layer rather than white-labeling an existing one.

Corporate travel programs that need policy enforcement. A mid-size company with 200+ frequent travelers pays Expedia's rack rates and has no way to enforce booking policies -- no pre-approval workflows, no preferred vendor rates, no spend visibility by department. A custom booking tool integrates with the company's expense management system, surfaces only policy-compliant fares, and routes approval requests to managers automatically. Concur and TravelPerk exist in this space, but their per-seat pricing reaches $30K-$80K per year at 200+ travelers -- and neither allows deep customisation of approval workflows.

Vertical travel operators with niche inventory. An adventure travel company curates experiences that never appear in Expedia's catalog -- guided glacier hikes, private sailing routes, remote safari camps. Expedia's search interface is built for commodity hotel and flight inventory. It cannot surface or cross-sell bespoke experiences alongside standard accommodation. A custom platform lets the operator control the full itinerary, bundle proprietary experiences with standard flights and hotels, and present the trip as a coherent package rather than separate bookings.

Hospitality groups needing direct booking control. A hotel group with 15-25 independent properties pays Expedia a 15-25% commission on every booking through the OTA channel. At $5M in annual OTA revenue, that is $750K-$1.25M in commission paid to Expedia per year. A direct booking platform with integrated loyalty costs $90K-$140K to build and, even with marketing spend to shift channel mix, pays back within 12-18 months on that volume.

White-label travel platforms for other businesses. HR tech companies, employee benefit platforms, and corporate card providers have started embedding travel booking inside their products. Building a white-label travel booking engine and licensing it as a B2B SaaS product is a different business model from consumer OTA -- and one where the comparison set is not Expedia but Spotnana or TravelPerk.

How Expedia makes money -- and what your options are

Travel platforms earn money in three ways. Which model fits depends on your audience and your supplier relationships.

Commission on bookings. The standard OTA model. You pass the booking through at the supplier's published rate and earn a percentage: typically 5-15% for hotels, 1-3% per flight segment via GDS. No upfront supplier negotiation required. The downside is margin compression -- your economics are set by what the supplier pays you, not by what you charge the traveler.

Markup on net rates. You negotiate wholesale rates from hotel groups or bed banks like Hotelbeds, mark up to your own price, and keep the difference. Better margin but requires minimum volume commitments. Most new OTAs cannot hit those minimums until they have established booking volume. This model works better after 12-18 months of operating on commission.

Subscription or white-label SaaS (B2B). You build the travel booking engine and license it to corporate travel programs, HR platforms, or employee benefit tools. Monthly SaaS fee rather than per-booking commission. According to Skift Research's 2024 Corporate Travel Report, corporate travel management software is a $7.5B market growing at 11% annually, driven by companies that need custom policy enforcement that generic OTA platforms cannot provide.

For a consumer travel startup, start with commission. For a corporate travel tool, start with subscription pricing immediately -- the value proposition is clear and buyers are accustomed to per-seat or per-transaction SaaS fees.

Unit economics to plan around: at 500 hotel bookings per month at an average booking value of $400 and a 12% commission, the platform earns $24,000 per month gross. Subtract $2K-$6K in API costs and $3K-$5K in payment processing. That leaves roughly $13K-$19K per month in gross margin before customer acquisition cost. The business becomes viable when customer acquisition cost per booking drops below $15-20.

What features does a travel booking MVP actually need?

"The biggest mistake travel startups make is building five things at 60% instead of one thing at 100%. You cannot have a mediocre search experience in travel. Users have Expedia in their back pocket." -- Kevin May, former editor of Tnooz and co-founder of PhocusWire, in a 2023 interview.

A working single-vertical MVP has five features. Nothing else.

Search with filters. For flights: origin, destination, dates, passengers, cabin class, with results filtered by stops, airline, departure time, and price. For hotels: destination, dates, guests, with results filtered by price, rating, cancellation policy, and property type. Keep filters to 6-8 maximum in v1. Expedia has 40+ hotel filters. Yours needs the ones that actually drive booking decisions.

Pricing calendar. A 30-day view showing the cheapest available fare by date. This is one of Expedia's highest-engagement features. Users shift travel dates by 1-2 days to save $50-$150 on flights. Building it adds roughly 2-3 weeks but measurably improves conversion.

Checkout and booking confirmation. Passenger or guest details, payment, confirmation, and email with the supplier booking reference. This is where most errors occur: API timeouts, price changes between search and checkout, and payment gateway failures. Design checkout to handle each failure explicitly. If the price changed, tell the user and let them accept or decline before payment. Silent failures at checkout are trust-destroying.

Booking management. Users need to view, download, and where the supplier allows it, cancel their bookings. In v1, support view and self-serve cancellation for refundable fares only. Route everything else to customer support. The airline change API error cases are numerous -- do not build self-serve changes until you have mapped them for your specific carrier set.

User account and itinerary dashboard. A logged-in view of all upcoming and past trips. A trip may include an outbound flight, a return flight on a different booking reference, and a hotel. The itinerary dashboard aggregates these by travel date. This data model -- trips as containers, bookings as line items, each with a supplier booking reference -- must be designed before you build anything else. Retrofitting it in v2 is a major rewrite.

V1, V2, V3: feature phasing and cost by phase

What to skip in v1: Package deals require coordinating availability across two APIs simultaneously -- complex pricing logic and cancellation policies. Car rentals add another API integration with its own data model. Activities via Viator or GetYourGuide add a third content type with different booking windows. Loyalty points require a points ledger and earn/burn rules. Personalized recommendations require booking history data you do not have yet.

Build the booking loop end to end in one vertical. Get real users completing real trips. Then add the second vertical.

Which API should you use for flights and hotels?

The single most consequential technical decision in a travel platform is which inventory APIs you connect. It determines your v1 scope, your timeline, and your ongoing API costs.

For flights, start with Duffel. Duffel is a modern flight API built on top of airline NDC (New Distribution Capability) connections. It has a cleaner developer experience than legacy GDS, integrates faster, and supports ancillaries like seat selection and bag fees natively. Coverage is narrower than Amadeus but growing. Cost: per-booking fee. For most v1 builds, Duffel gets you to market 4-6 weeks faster than Amadeus.

Amadeus is the right choice when you need full GDS coverage (400+ airlines) or when booking volume justifies the GDS relationship and per-search query pricing in production. Sabre and Travelport are enterprise alternatives with longer sales cycles -- use these only if you are targeting corporate travel or need specific carrier access.

Cross-platform frontend development saves $30K-$50K compared to building separate native apps. The web-first approach (Next.js) is correct for travel: Google indexes your search result pages, and SEO drives a meaningful portion of OTA traffic at scale.

For hotels, start with Booking.com Demand API or Expedia Partner Solutions. Both give you broad inventory (28M+ properties on Booking.com) without requiring direct hotel relationships. You earn affiliate commission on completed bookings. Hotelbeds is a wholesale alternative with strong coverage in Europe, Caribbean, and APAC -- better margins once you have volume, but requires minimum commitments. Direct chain APIs (Marriott, Hilton) offer higher commission rates but limit you to that chain's properties.

For v1, pick one hotel source. Broad coverage from a single API beats fragmented integration across three sources.

Where travel platform builds actually fail

"The hardest problem in travel technology is not connecting to the GDS. It is what happens in the 90 seconds between a user selecting a fare and completing payment. Prices change, seats fill, the supplier times out. Every one of those failure modes needs a graceful resolution path." -- Scott Gillespie, founder of tClara, in a 2024 interview with Skift.

Two failure modes appear consistently in travel platform builds.

The pricing cache is set wrong. Flight prices change every few seconds. If you cache too aggressively, users see prices on the search page that no longer exist when they hit checkout. The result is a price-mismatch error at the worst possible moment -- after the user has entered passenger details and credit card information. The correct architecture is a two-layer approach: cache search results for 2-5 minutes to keep the experience fast, then fetch a fresh price guarantee when the user selects a specific fare and moves to checkout. Teams that skip the guarantee step discover the problem after their first batch of angry customers.

The itinerary data model is built too late. A round-trip on American Airlines may generate two separate booking references if the outbound and return legs are priced separately. Add a Booking.com hotel reservation and the same trip has three booking references from three different suppliers. When the data model treats each booking as independent rather than as a line item under a trip container, the itinerary dashboard becomes impossible to build correctly in v2. This is consistently the most expensive retrofit we see -- 4-6 weeks of rewrite work on a system that already has live data in production. Design the trip-as-container structure before you build the first booking flow.

According to Amadeus's 2024 Travel Technology Report, travel platforms that invest in itinerary management from v1 see 34% higher return booking rates than platforms that treat each booking as a standalone transaction.

Build vs. Expedia: when does custom win?

Keep using Expedia (or a similar OTA) when:

• Your travel volume is under $1M annually. At that scale, the commission cost is lower than the build-and-maintain cost of a custom platform.

• You need broad multi-destination inventory immediately. Building supplier relationships and API integrations takes time. Expedia has them already.

• Your travelers are consumers with no special policy or compliance needs. Generic OTA search is fine for leisure travel with no approval workflows.

• You are a single-property hotel. The economics of a direct booking platform only work for groups with 10+ properties or $2M+ in annual OTA commission spend.

Build your own when:

• You pay more than $500K annually in OTA commissions. The payback period on a custom direct-booking platform drops below 18 months at that volume.

• You need booking policy enforcement that off-the-shelf tools cannot provide (pre-approvals, preferred vendor restrictions, department-level spend caps).

• Your inventory does not exist in standard GDS or OTA catalogs -- bespoke tour packages, private accommodation, curated experiences.

• You are building a B2B product and travel booking is an embedded feature rather than the core product. White-labeling Expedia is not an option in that architecture.

• You need deep integration with another system -- expense management, loyalty, HR -- that no OTA offers natively.

How RaftLabs approaches this

Most founders come to us wanting to build "an Expedia competitor." We redirect that conversation immediately. Expedia has 30 years of supplier relationships and $11B in annual revenue. You cannot compete on breadth.

What you can win on is focus. A travel platform for adventure travelers that integrates with activity providers and boutique lodges. A corporate travel tool that connects to expense management. A family travel platform that handles lap-infant policies across carriers that no generic OTA surfaces cleanly.

The product architecture follows from the niche. Which APIs do you connect to? What does search optimise for? What does the itinerary view show?

We build the GDS integration, the price caching layer, and the booking management flows alongside the search UI -- not after it. You cannot test a real travel booking platform without live API data. Demo connections are not representative of what breaks in production.

If you want to scope the build for your specific travel product, start with a 30-minute scoping call.