How do free apps make money? The 9 revenue models explained

Free apps make money through advertising, purchases, subscriptions, transaction fees, referrals, partnerships, paid companion products, data-related services, or licensing. The strongest model depends on what users value, how often they return, and whether the app participates in a financial transaction, and this guide walks through all nine models with the fit, the failure modes, and the engineering each one quietly demands.

Free does not mean the product has no cost. It means someone other than the user, or a smaller group of paying users, finances development and operation, and the interesting question in every case is who that someone is and why paying makes sense for them. Sometimes it is an advertiser buying attention, sometimes a subscriber buying depth, sometimes a merchant buying transactions, and sometimes a hardware company buying a better product experience.

One principle organizes everything that follows: monetization should be selected before development. Advertising requires consent and ad delivery systems, subscriptions require entitlements and renewal handling, and marketplace commissions require payment splitting, refunds, and financial reconciliation. Teams planning a mobile product build who defer the revenue decision are deferring architecture decisions they will later pay to reverse, a pattern the super app playbook illustrates at maximum scale: the winners built the wallet spine early because they knew where revenue would live.

The nine models, mapped to what they demand

Free apps convert attention, activity, transactions, or premium demand into revenue, and each conversion path is a distinct model with distinct machinery. Most sustainable products combine two or more models instead of depending on one source: Spotify pairs advertising with subscriptions, Tinder pairs consumable purchases with plans, and every marketplace pairs commissions with fees. The combinations are deliberate, because each model covers a weakness of the other.

No model is automatically superior, which is the first honest thing to say in a category full of forecasts. A predictable subscription can fail if users do not need the app every month, while an advertising model can work well when usage is frequent and broad. The table below maps each model to its best category fit, its revenue predictability, and its main risk, and the rest of this article takes the nine in turn.

Reading the table, notice the pattern in the predictability column: the models that involve a business payer, transaction fees, white-label licensing, companion products, tend to be steadier than the models that depend on consumer attention or impulse. That is not a reason to prefer them; it is a reason to know which kind of revenue volatility the chosen model imports into the business plan.

The nine revenue models at a glance

Revenue model	Best category fit	Revenue predictability	Main risk
Advertising	Media, games, social, utility apps	Low to medium	Weak revenue without scale
In-app purchases	Games, dating, creator tools	Low to medium	Unpredictable user spending
Subscriptions and freemium	Productivity, education, fitness, media	Medium to high	Churn and weak premium value
Transaction fees	Marketplaces, fintech, booking	Medium	Thin unit economics
Data monetization	Analytics, mobility, research	Varies	Privacy and regulatory exposure
Affiliate and referral	Shopping, travel, finance, content	Low to medium	Dependence on partner conversion
Sponsorships	Media, communities, events	Low to medium	Limited repeatability
Companion paid product	Hardware, enterprise, professional tools	Medium	Free app becomes a support cost
White-label licensing	B2B software, platforms, infrastructure	Medium to high	Customization and support burden

Predictability describes revenue behavior at product-market fit, not a guarantee. The main risk column is the one to read before choosing.

Advertising: selling attention, honestly priced

Advertising pays the app owner for displaying or facilitating interactions with sponsored content, and it fits products that attract frequent use but have limited willingness to pay. The format menu runs from display banners and native feed placements through video, rewarded ads, sponsored search results, audio ads, and brand placements, each trading differently against user experience. Spotify is the clean example: free access supported by advertising alongside paid Premium plans that remove it, and Duolingo runs the same structure, free access with subscriptions that remove ads and add features.

Advertising works best in media, entertainment, games, social platforms, and high-frequency utilities, because the product needs enough sessions or attention to create meaningful inventory. The main failure mode is adding ads before the app has that engagement: revenue stays small while intrusive placements damage retention, and more impressions do not help if users abandon the product. The arithmetic is unforgiving, which is why ad-supported products obsess over session frequency before they obsess over fill rates.

Advertising also adds technical and legal work that the forecast rarely includes: ad SDK integration, consent management, age-appropriate controls, analytics, placement rules, and performance monitoring, and a poorly implemented SDK can slow startup time or increase crashes, taxing the very engagement the model depends on. The decision rule is simple to state and demanding to meet: use ads when nonpaying users create enough repeat attention to justify the experience cost.

In-app purchases, subscriptions, and the freemium balance

In-app purchases let users buy digital goods, capabilities, or one-time upgrades, common in games, dating products, and creative apps where users want immediate optional benefits. The two broad categories behave differently: consumables, virtual currency, temporary boosts, hints, can be purchased and used repeatedly, while durables, permanent unlocks and content packs, remain available after purchase. Tinder's Boosts and Super Likes are recognizable consumables, layered alongside subscription plans, and the pattern generalizes: the purchase works when it connects to a clear moment of intent, a dating user wanting visibility now, a player wanting an item mid-session, a creator needing a specific export. It fails when purchases are arbitrary obstacles, because deliberately damaging basic usefulness to force payment shows up directly in ratings and retention.

Implementation is more than a checkout button: store integration, purchase validation, restoration, entitlement tracking, refund handling, fraud controls, and customer support, with Apple and Google policies dictating which digital purchases must use platform billing. The practitioner rule is to maintain entitlements on a secure backend when they have material value, because trusting the device alone makes manipulation and account recovery harder to control, a lesson teams learn either from this paragraph or from their support queue.

Subscriptions charge users repeatedly for continued access to premium features, content, capacity, or service, and freemium products keep a useful free tier while reserving added value for subscribers. The model fits products with recurring value: productivity, education, fitness, music and video, cloud storage, professional tools, business software, ongoing content or analysis. The strongest subscription products solve a repeated problem; the app does not need daily use, but users must expect continued value, and they cancel when the premium difference is unclear, onboarding is weak, or the problem occurs only occasionally.

The freemium balance is the model's hard design problem. A free tier must be useful enough to support adoption but limited enough to create a reason to upgrade: give free users nearly everything and conversion suffers, make the free tier unusable and acquisition and trust suffer. The architecture underneath needs plan definitions, trials, renewals, grace periods, cancellations, upgrades, downgrades, family or team access, and entitlement synchronization across devices. The decision rule: map each premium feature to recurring user value, and never adopt a subscription merely because recurring revenue looks better in a forecast.

Purchase and subscription design that survives contact with users

Do this

• Tie purchases to moments of intentVisibility now, an item mid-session, a specific capability at the moment of need. Intent is what converts.
• Keep entitlements server-sideAnything with material value is validated and stored on the backend, restorable across devices and account recovery.
• Map every premium feature to recurring valueIf the value is one-time, sell it once. Subscriptions that bill for stale value churn on schedule.
• Design the free tier as a productUseful enough to adopt and recommend, bounded enough that upgrading is a natural next step.

Not this

• Damage the free product to force paymentArbitrary obstacles convert a little and cost ratings, retention and word of mouth a lot.
• Trust the device with valuable entitlementsClient-side unlocks invite manipulation and make support cases unresolvable.
• Choose subscriptions for the forecastRecurring revenue recognition is not recurring value. Users cancel what they do not repeatedly need.

Transaction fees: earning when the marketplace moves

Transaction fees let an app earn money when buyers and sellers complete an exchange, the standard model for marketplaces, booking platforms, payment products, delivery services, and investment applications. The platform may charge a percentage commission, a fixed service fee, a payment processing markup, a provider fee, a buyer fee, or a combination. Uber uses marketplace and service fees across parts of its platform, with structures varying by product and market, which illustrates the model's defining property: marketplace monetization is tied to local operations, not just software, a dynamic covered in depth in the ride-hailing market economics.

The model's appeal is alignment: revenue grows with completed activity, so the platform earns more when participants transact more. The challenge is unit economics, because revenue per transaction must cover payment costs, support, refunds, incentives, disputes, fraud, insurance where applicable, and marketplace operations. Taking a larger commission is not always a solution: providers may leave, raise prices, or move transactions off-platform, and buyers compare the final price with direct alternatives. The commission rate is a negotiation with the whole marketplace, held continuously.

The engineering requirement that separates functioning marketplaces from spreadsheets is the financial ledger. The platform must track what the customer paid, what the provider earned, what the platform retained, and how refunds or adjustments changed those amounts, with every event carrying a reason and a timestamp. The practitioner rule follows: calculate contribution margin per completed transaction before scaling acquisition, because gross transaction value is not platform revenue, and celebrating GMV while losing money per order is the category's most documented failure.

Data monetization and affiliate revenue: the trust-bounded models

Data monetization means creating commercial value from information generated or organized by the product, and it emphatically does not mean secretly selling personal data. Legitimate forms include aggregated market insights, operational benchmarks, trend analysis, business intelligence products, research datasets with appropriate controls, fraud or risk signals, and paid reporting for business customers: a mobility platform producing aggregated traffic patterns, a business platform selling benchmark reporting to participating companies. The model carries significant privacy and regulatory responsibility, because GDPR, state privacy laws, sector rules, and contracts restrict collection, combination, retention, sale, and sharing, and removing names is not always enough when detailed location, behavior, health, or transaction records can be re-linked to individuals.

Consent must also be meaningful rather than buried, because hiding broad data rights inside a long privacy policy does not create user trust, and the failure mode is treating data as a byproduct that can automatically be sold. If monetization depends on a use users would consider surprising, the business faces legal and reputational risk simultaneously. The decision rule: define permitted data uses before collection, minimize personal data, aggregate where possible, and give customers clear contractual and product controls. Products built on serious data infrastructure have an advantage here, because aggregation, anonymization, and access control are engineering disciplines, not policy paragraphs.

Affiliate revenue pays the app when a user follows a tracked recommendation and completes an action with another business, a purchase, booking, registration, or approved application. It fits shopping comparison, travel planning, financial education, review platforms, deal discovery, creator content, and software directories: a travel app earning a referral payment on a partner hotel booking, a shopping app earning commission after directing a user to a retailer. The advantage is that the app never processes the full transaction; the partner manages inventory, payment, and fulfillment. The disadvantage is limited control, since revenue depends on partner attribution, commission rules, conversion rates, tracking restrictions, and program availability, and a partner can change terms or end a program unilaterally.

The trust boundary is the same as in data monetization, just consumer-facing: recommendations must remain useful, because an app that consistently promotes the highest-paying partner rather than the best match watches its authority erode. Implementation requires tracking, attribution, disclosure, partner feed management, and reconciliation, with broken links and expired offers damaging the experience fast. The practitioner rule: treat affiliate revenue as a monetization layer, not the reason the product exists, and make sure users receive value even when they do not convert.

Sponsorships, companion products, and white-label licensing

Sponsorships let a brand or organization fund content, access, events, features, or community activity, and they work best when an app reaches a specific audience sponsors value: a fitness app running a branded challenge with a sports brand, an education product funded by an institution to serve a defined user group, sponsored educational programs, industry reports, community events, employer-funded access. Sponsorship can generate more revenue per placement than standard advertising because it integrates into a broader campaign, and it keeps the core app free. The risk is scalability: sponsorships require sales work, campaign planning, custom reporting, legal review, and manual delivery, revenue concentrates in few partners, and the engineering failure mode is allowing each sponsor to request custom product behavior until the team maintains a museum of one-off campaigns. The rule: standardize sponsorship packages, reporting, and placements before selling them.

A free app can also exist to sell something else. The companion model puts a free app in service of a paid product, a free app for paid hardware, a mobile controller for connected devices, a free client for enterprise software, a reader for purchased content, a customer portal for a paid service, and the app is not expected to generate direct revenue; it increases the paid product's value or reduces service costs. It is the right model when charging separately for the app would weaken the overall offer, because a connected device is simply more useful with setup, monitoring, and control included. The failure mode is treating the companion app as secondary: customers judge the complete product, and a weak app makes good hardware feel unreliable. The financial fix is attribution, assigning part of the main product's revenue or retention value to the app so its team is not permanently underfunded, with its own reliability targets and maintenance budget.

White-labeling lets another company offer the software under its own brand, with the original developer earning licensing, implementation, usage, or support revenue. It fits products with reusable workflows across organizations: appointment platforms, learning systems, delivery software, loyalty programs, fintech infrastructure, property management, field service tools, customer portals. One scheduling platform licensed as branded versions to several clinic groups gives end users a free app while organizations pay for the technology, and the contract structure, setup fees, subscriptions, usage charges, support, can make this steadier than consumer advertising. The cost is product complexity: customers request different branding, workflows, integrations, permissions, and release schedules, and the critical architecture decision is whether differences are configuration or custom code, because a separate branch per customer eventually makes every update slow and risky. The rule: establish a shared product core, configuration system, tenant isolation, and clear customization boundaries before pursuing many white-label customers.

The B2B-payer vocabulary

Sponsorship package

A standardized, repeatable offer of placements, reporting and terms. The alternative is a custom campaign per sponsor, which does not scale.

Companion product

A free app whose job is making a paid product, hardware, enterprise software, a service, more valuable or cheaper to support.

Revenue attribution

Assigning part of the paid product's revenue or retention value to the companion app, so the app team has a budget proportional to its contribution.

White-label licensing

Selling branded instances of one product to many organizations, priced by setup, subscription, usage or support.

Tenant isolation

The architecture keeping each white-label customer's data, configuration and users separate inside one shared product core.

Configuration boundary

The declared line between what customers may configure and what would be custom code. The decision that keeps updates shippable.

How do apps make money without ads?

Apps make money without ads through subscriptions, purchases, commissions, referrals, paid companion products, sponsorships, and B2B licensing, and the best choice depends on whether the app creates recurring value, facilitates transactions, or supports another commercial product. A productivity app fits subscriptions, a marketplace fits transaction fees, a hardware company uses its app to support device sales, and a platform with reusable workflows sells white-label access. The mistake to avoid is choosing a model only because competitors use it, since two similar apps can have different acquisition costs, user frequency, and willingness to pay.

A useful selection process asks seven questions in order: who receives the most value, who has the ability and incentive to pay, does value occur once, repeatedly, or during transactions, how frequently do users return, what variable costs increase with usage, does payment create regulatory or platform obligations, and can the model support customer acquisition and maintenance. Worked honestly, the questions usually eliminate most models quickly and leave one or two genuine candidates, which is exactly the outcome a selection process should produce.

The question that unlocks the most products is the second one, because the party receiving value is not always the end user. Employers, merchants, providers, sponsors, or institutions may pay while consumers use the app for free, and some of the most durable free apps in every category, corporate learning tools, employee benefits products, merchant-funded loyalty programs, run on precisely this structure. When the consumer model looks thin, the B2B payer question is the next place to look, not a bigger ad load.

The seven-question model selection, in order

1. 1

   Who receives the most value?Start here

   Users, merchants, employers, sponsors, or a paid product the app supports. Name the beneficiary before the model.

2. 2

   Who can and will pay?The unlock

   Ability and incentive together. The payer is often not the user, and that is a feature, not a compromise.

3. 3

   When does value occur?The filter

   Once, repeatedly, or during transactions. This single answer eliminates most of the nine models.

4. 4

   How often do users return?The reality check

   Frequency decides whether advertising inventory or subscription habit can exist at all.

5. 5

   What costs scale with usage?Unit economics

   Media minutes, support, payment fees. The model must outgrow its own variable costs.

6. 6

   What obligations does payment create?The fine print

   Store billing rules, consent, financial regulation, tax. Each model imports its own compliance.

7. 7

   Does it fund acquisition and maintenance?The verdict

   A model that cannot pay for growth and upkeep is a hobby with revenue.

Why must the revenue model be chosen before development?

The revenue model changes the product architecture, data model, user experience, and legal obligations, and adding monetization after launch can require substantial reconstruction rather than a settings change. The specifics are concrete: advertising requires consent flows, ad placements, SDK governance, and controls for different user groups. Subscriptions require products, plans, receipts, renewals, entitlements, trials, account recovery, and cancellation handling. In-app purchases require store billing integration and server-side purchase verification. Transaction fees require payment orchestration, internal ledgers, refunds, reconciliation, provider onboarding, and potentially identity verification. Affiliate models require attribution, disclosure, partner feeds, and conversion reporting. White-label products require tenant isolation, configuration, branding controls, permissions, and customer-specific administration.

Monetization also decides what the analytics must measure. A subscription product needs retention and churn information, a marketplace needs completed transaction economics, and an advertising product needs engagement and inventory quality without sacrificing retention. Teams that choose the model late discover their analytics measured the wrong things for a year, which is a quieter cost than reconstruction but often a larger one, because the decisions made on the wrong metrics do not refund themselves.

The practitioner insight that ties the section together: model financial events separately from interface states. A button that says subscribed is not evidence that payment, renewal, refund, and entitlement records agree, and every monetization model on this page eventually reduces to a ledger of financial events that must reconcile independently of what any screen displays. Products that build that ledger early debug their revenue with queries; products that do not debug it with customer complaints.

What does it take to build a monetized free app?

A usable monetized MVP typically requires one core revenue model, reliable analytics, and a focused user journey, because building several monetization systems before product validation increases cost without proving demand. The consumer MVP checklist is stable across categories: account management, the core free experience, one monetization mechanism, payment or ad provider integration, entitlement or transaction records, basic administration, product analytics, consent and privacy controls, and customer support tools. Each item is modest; their sum is the difference between an app and a business.

A focused custom MVP may cost roughly USD 30,000 to 80,000, depending on platforms, backend complexity, integrations, design depth, and compliance, while a marketplace or regulated fintech product can exceed that range because monetization is connected to financial operations, ledgers, reconciliation, identity, and sometimes licensing. A typical initial team includes a product manager, a designer, two to four engineers, and a QA specialist, with DevOps, security, and compliance support joining for products involving payments, sensitive data, or high availability.

The first goal should not be maximizing revenue per user. It should be proving that users receive value, return, and accept the proposed exchange, because every model on this page is an exchange, attention for content, payment for depth, commission for transactions, and the MVP's job is demonstrating that the exchange feels fair to the people on the other side of it. Revenue optimization is what you do to an exchange that already works; applied earlier, it optimizes the product out of its own market.

The monetized MVP checklist: nine items, one model

• Core free experienceThe value that earns attention and retention before anyone pays anything. Without it, no model has raw material.
• One monetization mechanismChosen by the seven questions, built with its full machinery: consent, entitlements, or ledger as the model demands.
• Provider integration done properlyStore billing, payment orchestration, or ad SDK, including validation, restoration, refunds and failure states.
• Entitlement or transaction recordsServer-side, event-based, reconcilable. The financial truth that interface states are checked against.
• Analytics matched to the modelChurn for subscriptions, transaction economics for marketplaces, engagement quality for ads. Measure what the model lives on.
• Consent, privacy and support toolingConsent flows sized to the model's obligations, and support tools that can see and fix entitlement problems.

One revenue mechanism, instrumented end to end, beats three mechanisms half-built. The records items are what make revenue debuggable.

Frequently asked questions

When the model is chosen and the build begins, AgileTech is an AI native software development company in Vietnam that has shipped the entitlement, ledger and consent machinery behind every model on this page.