How to Make an App Like Skyscanner

Building a flight and hotel aggregator is one of the more technically demanding things you can do in consumer software. The data volumes are large, the pricing logic is opaque, and user expectations are high. This post walks through what it actually takes to build something in this space.

What Does the Architecture Actually Look Like?

At its core, a travel aggregator is a search and caching engine sitting on top of third-party data sources. The front end is almost the simplest part.

Data Sources and Aggregation

Skyscanner pulls from Global Distribution Systems (GDSs) like Amadeus, Sabre, and Travelport. These are decades-old systems running EDIFACT-formatted messages over private networks. You also have direct airline NDC (New Distribution Capability) APIs, which IATA has been pushing since 2012 and which bypass the GDS middleman entirely. Budget carriers like Ryanair and IndiGo largely operate outside GDSs altogether, so you need scraper pipelines or direct airline API partnerships for them.

For hotels, you're looking at aggregators like Expedia Partner Solutions, Hotelbeds, or direct property management system (PMS) integrations via channel managers like SiteMinder.

The realistic picture: you will never aggregate all sources from day one. Start with one GDS (Amadeus is the most developer-friendly, with a REST API and sandbox access), add NDC feeds for your highest-volume carriers, and build a normalisation layer that maps everything to a common schema.

Search and Caching Architecture

Live flight search is slow. A single multi-leg query can fan out into dozens of API calls across multiple GDSs, each with its own rate limits and latency profile. Amadeus's live pricing endpoint has a typical response time of 2 to 5 seconds under normal load.

The standard approach is to separate availability search from pricing. Run availability searches asynchronously, cache the results in Redis or a columnar store like ClickHouse, and trigger live re-pricing only when a user selects a specific fare. This is how every major aggregator avoids melting under load.

Cache TTLs matter enormously here. Flight availability can change every few seconds on busy routes. Most teams use short TTLs (30 to 90 seconds) for availability, longer ones (10 to 15 minutes) for ancillary data like seat maps.

How Do You Handle Pricing and Fare Logic?

Fare rules are genuinely one of the hardest problems in this domain. IATA fare filing runs on a system called ATPCO (Airline Tariff Publishing Company), and the rules are encoded in a notation that is essentially its own query language. A single fare can have hundreds of conditions: blackout dates, minimum stay requirements, advance purchase windows, combinability rules with other fares.

You have two options. Either you consume pre-processed fare data via a GDS, which abstracts most of this but costs more per transaction, or you ingest raw ATPCO feeds and process them yourself. The latter gives you more control and lower per-query costs at scale, but it requires a dedicated fare engine team. Skyscanner built their own. Most companies at Series A or B should not.

Currency conversion deserves its own paragraph. Fares are filed in the currency of the point of origin. When you display prices to a user in a different currency, you need a live exchange rate feed (Open Exchange Rates or similar), and you need to decide whether to apply a markup. This sounds simple. It creates accounting headaches at scale, especially with refund and chargeback handling across currencies.

What Does the Tech Stack Look Like in Practice?

There is no single right stack, but here is what works well at mid-scale.

Layer	Common Choices	Notes
API Gateway	Kong, AWS API Gateway	Rate limiting, auth, routing
Search Orchestration	Go or Java services	Latency-sensitive; avoid Python here
Caching	Redis Cluster, ClickHouse	Short-TTL for availability, columnar for analytics
Queue / Async	Kafka, RabbitMQ	Fan-out to multiple data sources
Frontend	React + Next.js	SEO matters; SSR is not optional
Mobile	React Native or Flutter	Share search logic via API
Data Warehouse	BigQuery, Snowflake	Route popularity, pricing trends

Python is fine for data pipelines and ML workloads (price prediction, demand forecasting), but it is the wrong choice for the hot path of a search request. Go handles the concurrency model much more cleanly.

Should You Build Your Own Booking and Payment Flow?

This is where a lot of teams make an expensive mistake. Building a full booking engine means holding PNR (Passenger Name Record) state, handling ticketing, managing payment reconciliation with airlines, and dealing with refund and reissue workflows. Airlines have strict timescales: a PNR typically needs to be ticketed within a few hours of booking or it auto-cancels.

The pragmatic path for most teams is to use a white-label booking engine from a GDS or a third-party like Kiwi.com's API, which handles booking, ticketing, and some disruption management. You lose margin but avoid building a 20-person operations team.

If you do build in-house, use Stripe or Adyen for payment processing rather than building your own gateway. Adyen is better for multi-currency and cross-border flows. Stripe has better developer tooling. Both handle PCI DSS compliance at the infrastructure level, which removes a significant regulatory burden.

How Do You Build the Search Experience Users Expect?

Autocomplete and flexible date search are table stakes. The interesting engineering is in the calendar view showing lowest prices per day, the "everywhere" search, and personalisation.

The calendar price grid requires pre-computed data. You cannot run live pricing queries for 30 days simultaneously without either enormous GDS costs or rate limit bans. The standard approach is to run a nightly batch job that queries fare data for your top city pairs across a rolling 90-day window, store the results in a fast read store, and serve them from there.

Elasticsearch works well for the destination search and autocomplete. IATA city and airport codes are well-documented and relatively static; a few thousand documents cover the vast majority of routes.

For personalisation, even basic collaborative filtering on search history (users who searched BLR to LHR also searched for these hotels) adds measurable click-through lift. You do not need a complex ML pipeline for this initially; a simple item-item similarity model built on BigQuery ML or scikit-learn gets you 80% of the value.

Conclusion

Building a travel aggregator is tractable if you are honest about what to build versus what to buy. Aggregate via a single GDS first, normalise aggressively, cache everything you can, and defer the booking engine until you have validated demand. The failure mode is building too much infrastructure before you have a user base to justify it.

If you are scoping this build and want a second opinion on architecture decisions or a team that has worked with GDS and NDC integrations, get in touch with us at Sodio.

---

FAQ

How long does it take to build a Skyscanner-like app? A minimum viable aggregator with flight search, one GDS integration, and a basic booking handoff takes roughly 6 to 9 months with a team of 5 to 7 engineers. A full-featured product with hotel search, price alerts, and mobile apps is closer to 18 months.

How much does it cost to build a travel aggregator? GDS access fees, cloud infrastructure, and a team of 6 engineers puts you in the range of $500,000 to $1.5 million for the first year, depending on geography and scope. GDS transaction fees alone can run $0.05 to $0.50 per search query at volume, which adds up quickly.

Do you need a GDS to build a flight search app? Not strictly. You can build a limited aggregator using airline direct APIs and NDC feeds, but coverage will be patchy for code-share routes and interline itineraries. For a consumer product that needs to compete on comprehensiveness, some GDS access is practically necessary.

What is the difference between NDC and GDS? GDS is the legacy distribution infrastructure (Amadeus, Sabre, Travelport) that aggregates fares from hundreds of airlines through standardised EDIFACT messaging. NDC is an IATA XML standard that allows airlines to distribute content directly to travel sellers, bypassing the GDS. NDC gives airlines more control over pricing and ancillaries; GDS gives you broader coverage from a single integration point.

Can you build this without airline partnerships? Yes, initially. GDS APIs do not require direct airline relationships; they license access to the aggregated content. Direct NDC partnerships come later, once you have enough booking volume to be commercially interesting to carriers. Most aggregators start GDS-only and layer in direct connections over time.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.