· Adam Foroughi, Giovanni Ge

How AppLovin Built a $100B Ad Machine

AppLovin went from a 92% post-IPO drawdown to $100B by letting a ~100-person, product-manager-free engineering team rebuild its core engine (Axon 2) and then using AI to elevate that same headcount onto harder problems, with success attributed to what they chose not to build.

applovinaxonrecommendation-systemsai-engineeringlean-teamsadtechtaste0% confidence

Why this is in the corpus

Rare CTO-level view (Giovanni Ge) of how a lean engineering org rebuilt a recommendation engine, onboarded juniors, governed AI-written code and stayed flat on headcount through hypergrowth; complements the existing Senra/Foroughi capital-allocation episode with the engineering side.

Summary for skimmers

CEO Adam Foroughi and CTO Giovanni Ge on Axon 2 (tree models to learned embeddings + deep nets, more accurate AND cheaper on GPUs), the napkin-born e-commerce data engine, no-PM engineering culture, ship-in-week-one onboarding, AI-on-top-not-next-to engineers, engineering taste as deciding what not to build, SBC in fixed dollars during a 92% drawdown, and the $30B cash flow math for a trillion-dollar AppLovin.

Briefing

What survives the editorial filter

This page should feel like a smart colleague already listened for you and left only the operating logic worth keeping. Not everything said in the episode makes it through.

Trust signal

Direct episode extraction

Best used for

Decision-grade retrieval metadata not yet added for this episode.

Hold lightly

No explicit downgrade reason stored yet for this episode.

Principles

Durable claims that survive beyond the speaker's biography — each with explicit limits, transferability judgment, and evidence.

Principle

You own every decision your AI made — "the AI did this" is not an acceptable answer

Grant total freedom in AI tool use but zero tolerance for disowning AI-generated decisions in core systems.

Gio says if an engineer explains an implementation with "I don't know, AI did this," he tells them it is not acceptable. He credits the rule with AppLovin's core code still being clean while many companies see AI-driven code rot.

Write the accountability rule into your engineering standards: any engineer must be able to defend every line in core systems regardless of who or what wrote it.

Principle

Be humble about what you built — when technology outruns it, throw it away and re-architect

Pre-commit, from day one, to discarding core technology whenever the frontier moves past it.

Adam says it was one of the first things he told Basel, the original lead engineer, and expected rebuilds every couple of years or faster. Axon 1 was on outdated ML techniques; the company hired Gio specifically to architect a replacement. The engineering creed: who cares about what we built, stay on something current.

Tell your engineering lead explicitly that the core engine is expected to be rebuilt every few years, so a rebuild is a success condition, not an admission of failure.

Principle

Show engineers how their work moves the business instead of assigning tasks

Context, not instructions, is what makes talented engineers productive.

On joining in November 2022, Gio saw the biggest problem was that junior people were not elevated — given low-level tasks without understanding the business or room to raise ideas. Part of his job became giving engineers full context; once provided, he says they have a much better sense of what to build.

Replace ticket-level assignments with a metric and a business explanation; let engineers propose the tasks.

Principle

AI changes how fast you solve the problem, never which problem you must solve

Anchor AI strategy on the unchanged customer problem rather than on the new capability.

Asked whether AppLovin must rebuild for the AI era, Gio says no: they understand the problem they need to solve, AI helps solve it, but it does not change it. That is why he rejects rebuilding everything simply because of AI.

Before any AI-motivated rewrite, write one sentence describing the customer problem; if it has not changed, build on top instead of rebuilding.

Principle

Design infrastructure for the valuation you intend to reach, not the one you have

Translate the company's stated ambition into concrete scale and vertical-expansion requirements for every system design.

Following Adam's trillion-dollar framing, Gio says engineering must be propelled for that growth: data infrastructure is designed to support the scale of a trillion-dollar company, and products are designed for whether they can support expansion into different verticals.

Add a design-review question: what would this system need to look like at 10x the current business, and across a new vertical?

Principle

Engineering taste is deciding what not to build — Axon's success came from omissions

Taste — including engineering taste — is the discipline of choosing what to leave out, and it matters more as AI makes building cheap.

Gio's hottest take is that taste is underestimated in an era where AI lets everyone build almost anything. He clarifies he means engineering taste, not just aesthetics. Knowing AppLovin's strengths, the team deliberately chose what to focus on and what not to work on when building Axon 2.0.

For every major system, write down the list of things you will explicitly not build and review it as seriously as the roadmap.

Principle

AI out of the box commoditizes output — alpha requires smart people directing AI with variance

AI raises the floor for everyone, so the edge moves to people who can make it produce non-consensus output.

Adam argues AI lets everyone write code and commoditizes it, so companies must create alpha somewhere. He applies the same logic to ad creative: if AI writes all creative, it will look the same and users stop responding. Smart people who run their own product management and direct AI a specific way are the source of variance.

Evaluate AI-assisted work for distinctiveness, not just speed; reward engineers who produce outputs a default prompt would not.

Principle

Engineers sit on top of AI, not next to it — the boundary moves, the human moves up with it

Frame AI as the substrate engineers stand on, and continually re-assign humans to whatever AI is not yet good at.

Gio walks through the moving boundary: AI once only corrected syntax, then completed paragraphs of code, and now can write an entire PR from an idea. AI is still weak at long-horizon planning, which much of AppLovin's work requires, so humans concentrate there. He credits this stance with dramatically multiplying per-engineer output over the last few years.

Audit quarterly which tasks AI now does well and explicitly move your engineers' time to the next rung up (planning, architecture, judgment).

Principle

High performers must become their own critics, because nobody around them will question them

The more trusted someone becomes, the more they must supply their own challenge.

Gio calls this a danger for high performers: people observe them as high performers, trust them, and stop questioning them. He has seen some do extremely well at self-challenge and others forget to.

When promoting or praising a top performer, pair it with an explicit expectation (and forum) for them to red-team their own work.

Principle

A hard revenue metric lets engineering self-direct without product managers

Pick business models whose success metric is a formula; that is what makes a PM-light engineering org viable.

Adam contrasts delivering audiences, where there is no measurement of what occurred, with a ROAS world. His lipstick example: $10 price, $5 cost, so the advertiser cannot spend more than $5 per sale. Then you tell engineering where you are and where you need to be for it to scale.

Define your engineering team's target as a single economic formula the customer also uses to decide spend.

Principle

Engineers must still be able to code — otherwise they cannot catch AI's bad decisions

For now, coding ability is the prerequisite for supervising AI that codes.

Asked whether people still need to learn to code, Gio says yes at this moment, while explicitly noting his answer may change in the future. He ties it to AppLovin's code remaining clean where many companies are seeing problems.

Keep hands-on coding ability as a hiring and review bar for anyone approving AI-generated changes to core systems.

Frameworks

Reusable systems and operating models — including when they help and when they break.

Framework

Top-of-funnel vs bottom-of-funnel: pick surfaces where the user does not know what they want

Classify every new ad surface by whether users arrive with intent (search-like) or without it (discovery), and only pursue discovery surfaces.

Bottom of funnel: user types what shoes they want; the search engine closes the transaction. Top of funnel: Instagram-style window shopping where the user discovers a want. AppLovin wants to start the funnel and close the loop. Because 99% of chatbot use is search-like, chatbot ads will look like search — so not well-suited; instead they look at CTV and open-web video.

Before entering a channel, ask whether users there already know what they want; if yes, expect an incumbent search-style business to own it.

Framework

Trillion-dollar math: work backward from $30B+ cash flow to which markets can carry it

Convert an ambition number into a required cash flow, then test every market against it.

Step 1: value = cash flow after SBC, projected, plus terminal value. Step 2: today AppLovin is over a $7B EBITDA run rate with ~75% cash conversion, about 20x where it was three years ago. Step 3: a trillion requires $30B+ of cash flow a year. Step 4: mobile gaming UA dollars cannot support it; consumer/e-commerce widens it but still cannot alone. Step 5: follow trillion-dollar B2C companies that extended from one product into adjacent categories.

Write your target valuation as a required annual cash flow and list which current and adjacent markets could plausibly deliver it.

Framework

Three hiring traits: intelligence, low ego, and response to adversity

Screen as hard for low ego and adversity response as for raw intelligence.

1) Intelligence (Gio): smart, learns fast, high standards, gets things done — what most companies look for. 2) Low ego (Gio): tends to listen, empower the team, help others, take feedback and proactively question themselves. 3) Adversity response (Adam): he always asks how candidates react to adversity; people who respond well do really well at AppLovin.

Add structured interview questions targeting ego (how they took hard feedback) and adversity (worst setback) alongside technical screens.

Framework

What / How / Why: the three questions before adopting any new technology

Do not staff up on a technology until you can answer how it applies to your product and why the product needs it.

Gio says his inspiration is just first principles. What: the technology (e.g., AI). How: how do you apply it in your product. Why: why does your product actually need it. He says this applied to previous technology generations too — for Axon 2.0 the team was very small and he filtered through the noise to focus everything on the most important 1%.

Require a written how and why before approving any AI headcount or project.

Framework

Prototype-vs-core split: anything goes for throwaway work, absolute cleanliness for core systems

Classify every piece of work as prototype or core and apply opposite quality regimes to each.

Tier 1 — prototypes: dashboards, temporary presentation projects; they do not have to be robust or maintainable and people can do whatever they want. Tier 2 — core infrastructure and core systems: AI allowed, but the human is accountable for every decision and the code must stay absolutely clean. Gio credits the split with AppLovin's code remaining clean.

Publish a written list of which repos/systems are core; everything else is explicitly prototype-grade.

Signals

What appears to be shifting, for whom it matters, and what happens if you ignore it.

Signal

~100 engineers held flat for three years while the business scaled ~20x and problems got harder

AI-era leverage is showing up as flat headcount against rising problem difficulty, not just faster shipping.

Engineering was about 100 people when Gio joined and roughly the same now; company around 400 after cutting from 600 two to three years ago. Gio says their growth was perfectly in sync with AI's advancement, and the team is now working on a new-generation model more powerful than the one built three years ago.

Track problem difficulty per engineer as a KPI, not just headcount-to-revenue; flat headcount on harder problems is the leading indicator of AI leverage.

Signal

99% of people still use AI as a search engine — the adoption gap is a marketing problem

Mainstream AI usage is still shallow and search-like, which shapes both the ad opportunity in chatbots and public sentiment.

Adam uses the 99% figure twice: to explain why organizations must push beyond search-style use, and in his hot take that animosity toward AI is a marketing failure. He parallels ads: framed as annoying, but actually creating transactions that would not otherwise happen and helping businesses hire.

Inside your company, measure AI usage by depth (agents, automation, code) rather than seat count; most seats are search.

Opportunities

Only included where there is a buyer, a real wedge, and a plausible revenue path — not vague idea theater.

Opportunity

Discovery surfaces beyond games: connected TV and open-web video where the user does not know what they want

Fragmented, low-intent video surfaces are the next large arena for discovery-style performance advertising.

Adam says they are doing R&D on CTV — if you can start the user down the flow and convert them, it is super high value — and on open-web video, where the less obvious, unrelated ad on a recipe site may create more value than a recipe-related one. He frames it on a 3, 5, 10 year horizon, and notes CTV and the open web are fragmented, unlike the mobile duopoly.

If you run a performance model, map which fragmented, low-intent surfaces your predictions could transfer to.

Opportunity

Early advertisers on a new platform get alpha by learning its native format instead of porting social creative

Early entry plus format-native creative on a new ad platform creates a temporary but real edge.

AppLovin entered e-commerce roughly 18 months ago, so the market must be educated. Advertisers who invest early and learn who users are and what ads work get larger campaigns and better metrics. Creative is one of the variables that can create alpha in an otherwise automated advertising system; roughly 30 ads a week might yield one interesting one.

When a new ad platform opens, budget for format-native creative testing (dozens of differentiated concepts) rather than reusing winners from other channels.

Lessons still worth keeping

Useful takeaways that did not fully clear the bar for durable principle status.

Lesson

E-commerce engine designed on a napkin at breakfast, prototyped before landing, validated with a premature model

A great engineering team replaces debate with a prototype.

About a year after scaling Axon 2.0, Basel, Gio and senior leaders at a Google conference in Vegas designed the first data-flow engine for e-commerce on a napkin while waiting for food; they had a first prototype before arriving back in San Francisco. A couple of months later, with a few test advertisers, even the premature model showed people purchasing and decent ROAS. Gio: there were reasons it would and would not work, so they just quickly built the prototype.

When a new-vertical debate stalls, time-box a prototype with a handful of real customers instead of commissioning more analysis.

Lesson

Billion, then ten billion, then a hundred billion — through a 92% drawdown

Set the next zero explicitly and keep it through a drawdown; scale makes later zeros easier than they look.

Adam: when they started the goal was a billion-dollar company, conveyed to the team with a plan; at a billion, $10B; at IPO, $100B. The stock then dropped 92% in 18 months and the dream seemed very far away, but post Axon 2 they recovered to $100B. He notes as you scale you matter more — technology more compelling, more data, network effects.

State the next order-of-magnitude goal to the team with a plan, and do not retract it during a drawdown.

Lesson

No investor relations for over a year at the bottom — rebuild the tech, buy the stock, and stay quiet

When mid-rebuild with no new story, skip the IR roadshow and let the rebuild plus buybacks speak later.

Adam: what were they going to convey — we are rebuilding our technology, the stock is dirt cheap? Nobody buys dirt cheap; they want a vision and growth prospects. So they became their own best investor. He says this was only possible because of conviction in what they were building and in future growth.

If you cannot yet show the growth story, redirect IR effort into shipping the thing that will become the story.

Lesson

Axon 2: replacing hundreds of thousands of if-else branches with learned embeddings made the model more accurate AND cheaper

Moving from tree-based to embedding + deep-net recommendation improved prediction and cut infrastructure cost simultaneously.

Axon 1 used a tree-based model with hundreds of thousands of if-else branches. Axon 2, architected by Gio and released roughly five to six months after he joined, encoded IDs into learned embeddings passed through a deep neural network. More accurate predictions meant better advertiser returns and business growth, and inference was cheaper on modern GPUs.

If your core model still relies on hand-structured clusters or trees, test whether an embedding-based architecture beats it on both accuracy and hardware efficiency — the two are not a trade-off.

Lesson

The CTO who joined on a 30% down day — and treated the drop as the reason to come

A stock drop during recruiting can filter for the right candidate rather than lose them.

Adam recounts that after the November 2022 earnings call, days before Gio's start, the stock fell 30% and he feared losing him. Gio instead saw more upside. Gio says if he just wanted to stay on the winning team he would not have left big tech. He then worked through a planned month-long Europe vacation, coding Axon 2.0 training infrastructure on a 12-hour flight with no internet, reading library source code.

In a drawdown, pitch hard to candidates motivated by making a difference; treat the ones who back away as a useful filter.

The Plays

Try these this week

Verb-first executable actions — each one tied to a stated outcome in the episode.

Extend a single-vertical data asset by pixeling advertiser websites — the users are people, not gamers

Outcome: Cross-vertical expansion needs a generalized model plus advertiser-shared data from the new vertical.

Context: Analysts pushed back that AppLovin only had gaming data. Adam's response: it is a billion people who do more than play games — skewing slightly female, 30 to 50, many heads of households. Following Facebook's playbook, they pixeled websites, understood users beyond games, and the model started working. Gio knew the architecture was not a verticalized model.

“started Pixeling websites, started getting data”
— Adam Foroughi

about a year after Axon 2 scaled; first model in a couple of months per

Before you start

· large engaged user base
· generalized model

Ask of every business-team process: could this be automated across the whole customer base?

Outcome: Automate every scalable process and redeploy business people into customer relationships.

Context: Adam: the business team stays lean; a central team builds tools, dashboards and automation. In a couple of years he hopes most processes are automated and interpersonal skills matter most — AI understands AppLovin's business but cannot understand advertisers' businesses. Their job is to be the advertiser's growth consultant, e.g. at a QBR.

“could this be automated and done across the whole advertiser base”
— Adam Foroughi

multi-year; goal of most processes automated a couple of years out per

Before you start

· central automation team
· AI-fluent business staff

Run engineering with almost no product managers — engineers write their own architecture and product

Outcome: Business-competent engineers plus a hard metric can replace most of a product management layer.

Context: Adam: no product org talking to clients, writing a spec, handing it to engineers. The e-commerce data engine was written on a napkin by engineers who never discussed it with a business person. Gio's org has probably a sub-handful of PMs. Gio adds that advertiser communication still goes through the business team, because scheduling engineer calls does not scale, but data and decisions sit with engineers.

“one of the cultural philosophies we had is almost no product management”
— Adam Foroughi

cultural default from founding per

Before you start

· business-competent engineers
· formula-able success metric

Let every new hire — intern included — push code to production in week one, with no training manual

Outcome: Replace months-long onboarding with guarded production access in week one and AI-assisted self-education.

Context: Adam contrasts the typical path — training, reviews, talking to 15 people over six months, first test a year and a half later — with AppLovin, where interns and new grads push an A/B test within a week. Controls prevent code from blowing up the system. On the business side too there is no training manual; new hires build their own by prompting AI and go to a teammate only when they hit a roadblock.

“they can push code within the first week of being here.”
— Adam Foroughi

first test live within one week per

Before you start

· safety controls on production
· lean team with high talent bar

Budget stock compensation in fixed dollars, not percentage of equity, so a crash does not become runaway dilution

Outcome: Fixed-dollar SBC plus a lean team is what makes buybacks rather than dilution possible in a crash.

Context: Adam: companies typically issue 2-3% of equity a year; if the stock falls 90%, would you issue 30% dilution? You would never recover. AppLovin pays people exceptionally well but does not overpay with a lean team, so it stayed manageable — and they deployed every dollar and more into buying back shares.

“So we, we always thought about that in fixed dollar terms”
— Adam Foroughi

annual grant cycle; tested across an 18-month 92% drawdown per

Before you start

· strong cash generation
· lean headcount

Rebuild the core engine with a tiny war room: CEO + two engineers in one Slack channel, racing each other in code

Outcome: Small, isolated, competitive build teams rebuild core engines faster than planned programs.

Context: Adam created a Slack room with Basel, Gio and himself for real-time feedback. Other assets — data platform, mediation software — stayed separate; only the core algorithm was rebuilt. Gio asked for a weekly one-on-one with Basel, who did not understand what that was; they cancelled it because they communicated with each other mostly with code, which was more efficient. Basel had written perhaps 60% of the company's code.

“they just went in and just started coding against each other and racing”
— Adam Foroughi

about 5-6 months from Gio joining to Axon 2 release per

Before you start

· hands-on CTO/CEO
· clear core-vs-peripheral boundary

Decision Moments

Actual decisions, real outcomes

Specific decisions narrated in the episode with their outcomes and transferable lessons.

At roughly a $5.5B valuation, AppLovin's core ad model (Axon 1) ran on outdated tree-based ML techniques; the stock fell 30% on the November 2022 earnings call days before the new researcher-CTO was due to start.

Did: Hired Giovanni Ge to architect Axon 2 and set up a three-person Slack war room (Adam, Basel, Gio) to rebuild only the core engine from scratch, ring-fenced from other assets, with Basel and Gio coding in parallel.Outcome: Axon 2 (learned embeddings + deep neural net) shipped about five to six months after Gio joined; more accurate and cheaper on GPUs; the company recovered from a 92% drawdown to a $100B valuation.

Rebuild the core engine with a tiny, isolated team of builders rather than a large program; a drawdown can be the moment to do it.

Part of an emerging decision pattern across multiple episodes

About a year after scaling Axon 2, analysts and investors doubted a model trained on gaming data could work for e-commerce; internal analysis produced reasons for and against.

Did: Instead of more analysis, engineers designed the first e-commerce data-flow engine on a napkin at a Vegas breakfast, prototyped it before returning to San Francisco, pixeled advertiser sites, and launched a premature model with a few test advertisers.Outcome: Even the data-starved model showed purchases and decent ROAS, giving confidence to build the e-commerce business.

When a strategic question is arguable both ways, a cheap prototype with real customers ends the debate.

Part of an emerging decision pattern across multiple episodes

The stock fell 92% in the first 18 months after IPO while the technology was being rebuilt; percentage-based equity grants would have implied massive dilution, and there was no new growth story to tell investors.

Did: Kept stock compensation in fixed dollar terms with a lean team, did no investor relations for over a year, and deployed every dollar and more into buying back shares.Outcome: Dilution stayed manageable; after Axon 2 the company recovered and reached a $100B valuation.

Fixed-dollar SBC plus strong cash flow turns a drawdown into a buyback opportunity instead of a dilution spiral.

Part of an emerging decision pattern across multiple episodes

Business scale and problem complexity grew sharply over three years, which would normally require growing the ~100-person engineering team.

Did: Held engineering headcount flat and used AI to elevate the same engineers onto harder problems, including a next-generation model beyond Axon 2, while refusing to rebuild existing systems just because of AI.Outcome: Same team size solving more challenging problems; per-engineer output multiplied and every team member grew with the company.

Let AI absorb growth in problem difficulty rather than adding headcount, and build on top of what works.

Part of an emerging decision pattern across multiple episodes

Tensions surfaced

Contradictions and trade-offs the episode raises — judgment calls a thoughtful operator has to navigate.

Tension

Rebuild when tech outruns you (Adam) vs. do not rebuild for AI, build on top (Gio)

The same leadership team holds both a rebuild-readily doctrine and a don't-rebuild-for-AI stance.

Adam told Basel early that you must be humble and rebuild every couple of years. Asked whether AppLovin must rebuild for AI, Gio says they built a lot they are proud of and AI is not a reason to rebuild; what AI helps with is building on top.

Test a rebuild decision by asking whether the new technology changes the problem (rebuild) or only the speed of solving it (extend).

Tension

Legacy orgs need to replace almost everyone to become AI-native — and almost none can

AI-native transformation of a legacy org has no clean path; lean companies that stayed high-bar have a structural head start.

Adam distinguishes AI-native startups, AppLovin (stayed lean with a high talent bar, so people should be AI native or will fall behind), and other companies whose people are not AI native. He says there is no clear answer for how those companies can get there.

If you are not AI-native, do not expect a budget or tool rollout to transform the org; plan for a deeper talent and culture change.

Tension

The desire to not disappoint drives performance but makes it hard to pause and enjoy achievement

The trait that makes top operators relentless also denies them fulfillment.

Gio attributes his success to a desire not to disappoint people, including Adam's expectations, and admits it becomes an obstacle. Adam calls it a common trait of highly competent people: once you reach one goal you are on to the next; A is not good enough, you need A plus. Adam separately says he manages out both excitement and being down.

When hiring for drive, recognize you are also hiring an inability to rest; build in deliberate recognition moments.

Corpus connection

Where this episode fits for retrieval

What kinds of decisions this briefing is best pulled into.

Primary decisions

• org-design
• strategic-bet
• hire
• technology-architecture