AirAsia super app case study: what happens when an airline tries to become everything

In October 2020, with its fleet largely grounded by the pandemic, AirAsia relaunched its booking app as the airasia Super App and declared that it would become the everyday app for Southeast Asia: flights, yes, but also hotels, food delivery, ride-hailing, groceries, shopping, payments, and parcel delivery. Its chief executive said the goal was to compete with Grab and Gojek. It was an audacious pivot for an airline, and it was made from the most difficult starting position in the category.

This case study tells the story in order: what AirAsia had going in, what it built and bought between 2020 and 2022, what it scaled back and why, and what the 2024 rebrand to MOVE actually means. It then extracts the lessons for anyone building a multi-service platform, because the AirAsia case is the clearest illustration of a principle that the anatomy of a super app states abstractly: a super app is a frequency machine, and everything else in the playbook depends on that.

It also gives the company its due. The platform engineering was largely right. Identity, payment, loyalty, and a runtime for partner services were built and worked. Teams planning a multi-service app of their own should study both halves: the architecture that was ready, and the habit that was not there to run on it.

What AirAsia had going in, and what it did not

AirAsia arrived at the super app decision with assets most would-be platforms would envy. Two decades as Southeast Asia's largest low-cost carrier had produced a brand recognized from Kuala Lumpur to Manila, a database of tens of millions of customers who had already handed over identity documents and payment cards to book flights, a loyalty program in BIG (later airasia rewards) with a large member base, and a fintech subsidiary in BigPay, launched in 2018 as a prepaid card and e-wallet. It also had, in 2020, a fleet sitting on the ground and a leadership team looking hard for revenue that did not depend on borders being open.

What it did not have was frequency. A leisure traveler in the region books an AirAsia flight a few times a year. That is a high-value, high-trust transaction, but it is not a habit, and a super app is built on habit: the reason WeChat, Grab, and Gojek could layer services onto their apps is that users already opened them daily for messaging, rides, or food. AirAsia's users opened the app when they had a trip to plan and closed it when the boarding pass was saved. Every other starting position in the category, messenger, payments, mobility, comes with a daily reason to open the app. Travel does not.

The company understood this, which is why the expansion moved so quickly into daily-use categories rather than adjacent travel ones. Food delivery, ride-hailing, and groceries were not chosen because an airline has an edge in them. They were chosen because they are the categories that produce daily opens, and the strategy was to buy frequency with them and then cross-sell the high-value travel products to the habit they created. The bet was coherent. It was also the hardest version of the super app bet anyone has made.

Four super app starting positions, compared on what matters

	Daily frequency	Payment rail	Verified identity	Transaction value
Messenger origin (WeChat, Zalo)	Yes	Partial	Partial	No
Payments origin (MoMo, Alipay)	Yes	Yes	Yes	Partial
Mobility origin (Grab, Gojek)	Yes	Yes	Partial	Partial
Travel origin (AirAsia)	No	Yes	Yes	Yes

The expansion, 2020 to 2022: what got built and bought

The pace of the expansion is the first thing to understand. In roughly two years the group launched or scaled airasia food, a delivery service in Malaysia that expanded to Thailand, Singapore, and Indonesia; airasia ride, an e-hailing service that launched in Malaysia in 2021 and expanded to Thailand; airasia grocer and airasia shop for groceries and e-commerce; hotels and activities through the travel arm; a Muslim lifestyle vertical in Ikhlas; and it built out Teleport as a logistics and parcel delivery business using the airline's belly cargo capacity and a ground network. BigPay grew from a card into a fuller wallet with remittances and lending ambitions. In early 2022 the parent company renamed itself Capital A to signal that it was no longer an airline with side businesses but a group of digital and aviation businesses.

The Gojek Thailand deal in mid-2021 is the most revealing move of the period. Capital A acquired Gojek's Thailand operations, a food delivery and ride-hailing business with an existing daily-use customer base, and paid for it with equity in the super app rather than cash. Gojek became a shareholder in airasia Super App; AirAsia got a running frequency business in a market where it had strong brand presence. Strip away the deal mechanics and it is a company that had correctly diagnosed its problem, no daily habit, and decided to buy one rather than wait for organic growth that was not coming.

Under the verticals, the platform layer was being built the right way. A single airasia ID carried across every service. BigPay and the in-app wallet provided the payment rail. The rewards program was re-based as airasia rewards and made to work across flights, food, rides, and shopping so that a burger earned points toward a flight. Partner services ran inside the host app with shared checkout and identity. This is the anatomy the WeChat and MoMo case studies describe, executed competently and fast. If the super app model were only an engineering problem, AirAsia would have solved it.

The airasia Super App timeline

1. Foundations2018 to 2019

   BigPay launches as a prepaid card and wallet. BIG loyalty program grows across the airline group.

   Done when A payment rail and a loyalty base exist before the super app is announced.

2. RelaunchLate 2020

   airasia.com app relaunched as the airasia Super App. Food delivery live in Malaysia. Hotels, activities, e-commerce added.

   Done when One app, one ID, multiple verticals, publicly positioned against Grab and Gojek.

3. Buying frequency2021

   Gojek Thailand acquired for equity. airasia ride launches in Malaysia. Food expands to Thailand, Singapore, Indonesia. Teleport builds ground logistics.

   Done when Daily-use categories live in the two biggest markets; ride and food operating.

4. Capital A2022

   Parent renamed Capital A. Super app, BigPay, Teleport run as distinct digital businesses. Some food markets exited as unit economics disappoint.

   Done when Group structure reflects the platform ambition; first pruning begins.

5. MOVE2023 to 2024

   App rebranded airasia MOVE, refocused on travel: flights across carriers, hotels, rides, and fintech in the travel journey. Non-core verticals wound down or deprioritized.

   Done when A travel platform with a payment rail and a loyalty base, which is roughly where it started, plus the pieces that fit.

Compressed from public announcements. Dates are approximate to the quarter; the point is the pace.

What got scaled back, and what the pullback reveals

The pruning began within two years of the relaunch. Food delivery, the category chosen precisely for its frequency, turned out to have the unit economics that every food delivery business has: thin margins, heavy subsidy requirements to acquire users from entrenched incumbents, and a cost per order that a late entrant without scale cannot bring down. Markets were exited, Singapore among the first, and the service was narrowed in the ones that remained. Ride-hailing faced a similar wall in Malaysia and Thailand against Grab, which had spent years and billions building driver supply and rider habit. Grocery and general e-commerce were deprioritized as it became clear that the airasia brand, strong in travel, carried little advantage in a shopping cart.

The pattern in what survived is instructive. Hotels and activities are travel; they attach to the flight booking and the customer is already in a planning mindset. Rides survived in a narrower form because a traveler landing in a city needs one, and an airline knows exactly when and where its customers land. BigPay survived and grew because a payment rail is useful independent of the app that hosts it, and because remittances and travel money are real needs for the customer base. Teleport survived because belly cargo is an asset the airline genuinely has and competitors do not. Everything that leveraged something the airline actually possessed, customers in transit, cargo space, payment relationships, held. Everything that required beating a daily-use incumbent at its own game did not.

The 2024 rebrand to MOVE, under the Capital A digital arm, formalized this. The app repositioned as a travel platform selling flights across multiple carriers, not just AirAsia, alongside hotels, rides, and travel fintech. Read cynically, it is a retreat to the booking app the company started with. Read accurately, it is a company that ran the full super app experiment, learned which verticals its assets could support, and kept those. The retreat was expensive, but the experiment produced a clear answer that most would-be super apps never get: this is what our frequency can and cannot carry.

What held and what did not, by whether the airline had an edge

Do this

• Hotels and activitiesAttach to the flight. The customer is already planning a trip in the app.
• Rides at the destinationThe airline knows when and where every customer lands. A narrow, defensible ride use case.
• BigPay and travel moneyA payment rail is useful on its own. Remittances and multi-currency spend are real needs for this base.
• Teleport logisticsBelly cargo capacity is an asset competitors do not have. The business had a moat from day one.

Not this

• Food delivery at scaleLate entrant, no cost advantage, subsidizing users away from incumbents with deeper pockets.
• General ride-hailingCompeting for daily commuters against Grab's driver supply and years of habit.
• Grocery and general e-commerceA travel brand carries no advantage in a shopping cart.
• Being the everyday appThe goal itself. Frequency could be bought in Thailand but not manufactured everywhere.

What AirAsia got right: the platform layer

It would be easy to file this case under failures, and that would miss the half of it that builders should copy. The airasia platform layer was designed the way a super app platform should be. A single identity spanned every vertical, so a user who had booked a flight could order food without another sign-up, and the identity carried the verified documents and payment methods the airline already held. The payment rail ran through BigPay and the in-app wallet, with a shared checkout that partner services plugged into rather than reimplemented. The loyalty layer was reworked so that points accrued and redeemed across every vertical, which is the mechanism that makes cross-selling work: earn on the burger, redeem on the flight.

Partner services ran inside the host application on a runtime that gave them the shared identity, payment, and loyalty without giving them the customer relationship. This is the same structure that lets WeChat host millions of mini programs and lets Grab onboard merchants in weeks. It is not trivial to build. It requires a permission model that lets a partner see what it needs and nothing more, a settlement system that splits money correctly across parties, a design system that keeps a dozen services feeling like one app, and a release process that lets verticals ship independently without breaking the shell. AirAsia built this, and the verticals launched at a pace that proves the platform worked.

For anyone building a multi-service product, the lesson is that the platform layer is necessary and not sufficient. A good identity, payment, loyalty, and partner runtime lets you add services fast. It does not make anyone open the app. The order of operations that works is habit first, platform second, and the AirAsia case shows what happens when a well-built platform is deployed before the habit exists: the services launch, the platform handles them, and users continue to open the app a few times a year. Teams working with fintech infrastructure in particular should note that BigPay, the payment layer, was the piece that proved most durable, because a rail has value even when the host app does not have frequency.

The platform layer AirAsia built, as a checklist for your own

• One identity across servicesVerified once, carried everywhere. Documents and payment methods from the core business reused by every vertical.
• A shared payment rail and checkoutBigPay and the wallet. Partners plug in; nobody rebuilds payments.
• Cross-vertical loyaltyEarn anywhere, redeem anywhere. The mechanism that makes cross-sell more than a banner.
• A partner runtime with a permission modelPartners see what they need. The host keeps the customer relationship.
• Split settlementMoney divided correctly across host, partner, and payment provider on every order.
• Independent vertical releasesFood ships without breaking flights. A shell that isolates its tenants.

The frequency problem, stated precisely

A super app monetizes attention it already has. The economics work because the host does not pay to acquire a user for each new service; the user is already in the app for a reason that recurs daily, and each added service is cross-sold to an audience the host owns at near-zero marginal acquisition cost. This is why messenger, payments, and mobility origins dominate the category: each comes with a daily open built into the core use case. The addition of food to a ride app is cheap because the rider is already there.

Travel inverts this. The core transaction is high value but rare, so the host does not own daily attention and must acquire it for each new service the same way any standalone competitor would, by paying for it. When AirAsia launched food delivery, it was not cross-selling to a daily audience; it was entering the food delivery market as a new entrant with a recognizable logo and a customer list, which is a marketing advantage but not a structural one. The incumbents had driver and merchant supply, delivery density, and rider habit. AirAsia had a brand and a list. Those buy trials, not habits.

The Gojek Thailand deal shows the company understood this precisely. Buying a running daily-use business is the only fast way to acquire frequency, and paying with equity in the super app rather than cash shows how the frequency was valued relative to the platform. It worked to a degree in Thailand. It could not be repeated in every market because there was no Gojek Thailand to buy in each of them, and building the equivalent organically meant subsidizing against incumbents indefinitely. The frequency problem was solvable where a frequency business was for sale and unsolvable where it was not, which is the whole story of the pullback in one sentence.

Lessons for builders: reading the case correctly

The first lesson is to be honest about your starting position before adopting the playbook. If your core product is used daily, you have the raw material for a super app and the platform layer is a good investment. If it is used a few times a year, however trusted and valuable, you do not, and adding daily-use verticals means competing as a new entrant in each one. That can be a legitimate strategy, but it is a market-entry strategy with a marketing advantage, not a super app strategy, and it should be budgeted as the former.

The second lesson is to add what your assets can carry. AirAsia's survivors were the verticals that leveraged something the airline actually had: passengers in transit, cargo space, payment relationships, a planning moment. A travel company adding hotels is using its assets. A travel company adding grocery is using its logo. The test for any proposed vertical is whether the core business gives it a structural advantage, supply, timing, data, distribution, or only a recognizable brand, and to prioritize ruthlessly toward the former.

The third lesson is about sequencing the platform investment. The identity, payment, loyalty, and partner runtime that AirAsia built are the right architecture for a multi-service product, and they take a long time to build well, which tempts teams to start them early. The AirAsia case argues for building the minimum platform that the first one or two adjacent services need, proving that users actually cross over, and only then generalizing. A partner runtime for a dozen verticals is a fine thing to own when there are a dozen verticals with users. Before that it is expensive optionality. The ride-hailing market analysis on this site makes the complementary point from the mobility side: the incumbents AirAsia ran into had spent years building supply density before they added a single extra service.

• Audit your frequency first. Daily opens make a super app possible. Yearly opens make each new vertical a cold market entry, whatever the brand.
• Add what your assets carry. Passengers in transit, cargo space, and payment relationships held. A logo on a grocery cart did not.
• Buy frequency only where it is for sale. The Gojek Thailand deal worked because there was a Gojek Thailand. There is not one in every market.
• Build the platform to the services you have. Identity and payments for two adjacent verticals first. The partner runtime for twelve when there are twelve.
• Keep the payment rail regardless. BigPay outlived the everyday-app ambition because a rail has value independent of its host.

MOVE and what comes next

As airasia MOVE, the app has settled into a coherent shape: a travel platform selling flights across multiple carriers, hotels, airport and destination rides, travel insurance, and the fintech services a traveler actually uses, foreign exchange, cards, and remittances through BigPay, wrapped in a loyalty program that still spans the group. It is a narrower ambition than the everyday app announced in 2020, and a more defensible one, because every service in it attaches to a trip and the airline knows when its customers are taking one.

The unanswered question is whether a travel platform can generate enough frequency to sustain a platform-scale cost base without the airline's traffic. Capital A's restructuring, which moved the aviation business toward a separate listed entity, makes MOVE's independence a live test. Multi-carrier flight search puts it in direct competition with online travel agencies that have spent two decades on exactly that problem, and the differentiator is the loyalty base and the payment rail rather than the search itself. Whether that is enough is what the next few years will show.

For builders, the case closes on a useful note. The company that tried the hardest version of the super app bet did not end up with nothing. It ended up with a well-built platform layer, a durable fintech business, a logistics arm with a real moat, and a travel app that does more than the one it started with. The everyday-app ambition did not survive contact with the frequency problem, but the pieces that leveraged real assets did, and that outcome is the realistic best case for anyone starting from a transactional-but-infrequent position. Aim for it deliberately rather than arriving at it after the expensive part.

Frequently asked questions

When a multi-service product is ready to be scoped honestly, AgileTech is an AI native software development company in Vietnam that has built identity, payment, and partner layers for platforms in this region.