◉ AI Models/2026-06-27Intermediate

Monetizing a Rork-Built App — Choosing Between Ads, Subscriptions, and Freemium

How to monetize an app built with Rork — from choosing between ads, subscriptions, freemium, and one-time purchase to the implementation details. Phased AdMob formats, treating ad-free as a single source of truth, and price anchoring, written from the indie-developer trenches.

Rork⁴⁶⁵ monetization⁴⁷ AdMob⁶⁶ subscription²⁸ indie developer²⁸

✦ Premium Article

Back around 2014, when I was shipping wallpaper apps as an indie developer, the wall I hit first wasn't building — it was that I had no idea how a published app turned into money.

Rork has all but erased the building side of that wall. Describe what you want in plain English and you get working code you can carry all the way to the store. But the monetization decisions still sit squarely with you. If anything, now that the tooling is fast, the quality of your design shows up directly in the results.

In this article I'll lay out monetization design in the order I wish I'd settled it — drawn from running both ads and subscriptions across my own indie apps.

Pick the model by working backwards from the shape of your app

Choosing a monetization model by "which one makes the most money" usually misfires. Start from how the app is used.

An app opened briefly every day and an app used deeply a few times a month reward completely different approaches. The former accumulates ad impressions; the latter has high per-session value, which suits paid access.

Model	Best-fit apps	Scale needed	Common pitfall
Ads (AdMob)	Lightweight daily tools, casual games	The larger the MAU, the better	Doesn't pay off at small user counts
Freemium	Value is clear for free, upper tier creates a gap	Needs a large free base	Too useful for free = nobody pays
Subscription	Apps with monthly renewing value (sync, AI, new content)	Retention is everything	No renewing value = instant churn
One-time purchase	Apps that are complete as a tool	Constant new inflow required	No recurring revenue builds up

In practice you combine them. I often build three layers: "free + ads" to grow the base, an ad-free purchase for people who want the ads gone, and a subscription reserved for genuinely renewing value. The key is deciding where these layer boundaries sit at design time. Slot them in later and you'll struggle to claw back features you already gave away for free.

If you monetize with ads, phased formats and mediation are the core

Ads started with "just slap a banner on it" almost always disappoint. For my first few years I ran banners only — the picture changed the moment I added interstitials and rewarded ads.

The sequence: lay the foundation with banners, place interstitials at natural breaks (after a stage clear, after a save completes), and finally add rewarded ads where "watching earns you something." Rewarded ads are watched by choice, so they rarely damage the experience and tend to show higher eCPM.

The other lever is mediation — instead of AdMob alone, you let several networks compete and serve the highest-paying ad.

// Anchor on AdMob, bundle multiple networks to lift fill rate and eCPM
// Shape of a react-native-google-mobile-ads + mediation adapter setup
import mobileAds, { MaxAdContentRating } from 'react-native-google-mobile-ads';
 
await mobileAds().setRequestConfiguration({
  maxAdContentRating: MaxAdContentRating.PG,
  tagForChildDirectedTreatment: false,
});
 
await mobileAds().initialize();
// After init, enable the Meta Audience Network / AppLovin /
// Unity Ads / Pangle adapters in the AdMob console and let them bid

eCPM swings a lot by country and time of day. From running these apps, the pattern I came to trust was that English-speaking users carry higher rates, and the late-evening-to-midnight window tends to lift the price per impression. The point isn't the exact numbers — it's that knowing where your users are and when they open the app changes revenue dramatically for the very same ad slot.

Ad format	Where to place it	Experience cost
Banner	Always-on. Bottom of lists or result screens	Low
Interstitial	Only at natural screen transitions	Medium. Cap the frequency or people leave
Rewarded	In exchange for extras, continue, bonuses	Low. Voluntary, so it lands well

One caution: AdMob is strict about policy, and a warning can pause delivery. I had one close call, and ever since, "no placements that bait mistaps" and "keep distance from content" come before any revenue trick. Operations you can't get shut down matter far more than squeezing out one more tier of income.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A decision framework for picking ads, subscriptions, freemium, or one-time purchase based on how your app is actually used

✦Implementation notes on rolling out AdMob ad formats in stages and reading eCPM by country and time of day

✦The 'ad-free as a single source of truth' design that lifts conversion, plus how to build price anchoring

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Freemium stays stable when ad-free is a single source of truth

The thing that tangles freemium most is managing "the right to remove ads" and "unlocking upper features" as separate flags. The conditionals scatter everywhere, and you get accidents like paying users still seeing ads.

I settled on holding "is this user ad-free?" as a single source of truth across the whole app, and deriving both ad display and feature unlocks from it.

// Make purchase state a single source of truth; derive ads and unlocks from it
type Entitlement = {
  adFree: boolean;     // right to remove ads
  proFeatures: boolean; // upper-tier unlock
};
 
function resolveEntitlement(purchases: PurchaseInfo): Entitlement {
  const hasPro = purchases.activeSubscriptions.includes('pro_monthly')
    || purchases.activeSubscriptions.includes('pro_yearly');
  const hasAdFree = hasPro || purchases.nonConsumables.includes('remove_ads');
  return { adFree: hasAdFree, proFeatures: hasPro };
}
 
// The view layer adds no branches; it only reads this result
const { adFree, proFeatures } = resolveEntitlement(purchases);
if (!adFree) showBannerAd();

In free-tier design, I aim for the fine line where "free is satisfying, yet the paid value is clearly visible." Too inconvenient and it goes unused; too convenient and nobody pays.

The best moment to prompt for payment is the instant a user hits a feature wall. Swapping a deducting message ("3 uses left") for a forward-looking one ("Go Pro to keep going right now") changes the response at the very same wall. If you're getting stuck on the ad-gate structure itself, I'd suggest reading designing a Rork app's ad gate as a parallel structure alongside this — it covers the implementation feel.

Set subscription prices with three tiers and anchoring

Subscription pricing settles more easily when you show three side by side and let people judge in relative terms, rather than agonizing over a single "fair" number. If you want the middle picked, just placing a slightly higher plan above it makes the middle look like a deal.

Plan	Monthly range	Yearly range	Intent
Standard	$3–$5	$28–$48	Entry point. Lowers the psychological hurdle
Pro	$6–$10	$58–$98	The target. Where you want people to land
Unlimited	$15–$30	$148–$280	The ceiling. An anchor that makes Pro look cheap

Set the yearly price at roughly 60–70% of twelve monthly payments so "annual is the better deal" reads at a glance. As the annual share rises, churn windows narrow to once a year, which stabilizes revenue.

For the Expo-based apps Rork generates, wrapping subscriptions in a manager like RevenueCat — rather than touching StoreKit or Google Play Billing directly — handled receipt validation, restores, and cross-platform consistency in one place for me. When bolting payments onto generated code afterward, it also keeps the purchase source of truth in one spot, which dovetails cleanly with the Entitlement design above.

Getting found on the App Store — practical ASO

However sharp your revenue design, nothing starts if you're not found. The realistic path for an indie developer is to win organic search traffic without ad spend.

For keywords, don't take generic terms the giants dominate ("notes," "calendar") head-on. Use one notch narrower phrasing — "notes for X," "tracking for X" — to reliably catch mid-volume searches with thin competition and real demand.

Your first three screenshots decide it. Showing "what changes when you use it" lifts install rate more than explaining features. Since I also do design work, I let AI rough out the base here and finish the single most persuasive shot by hand.

Reviews affect both ranking and install rate. Ask for them right after a user feels the value — the moment a task finishes, or at a milestone in a streak. Get the timing right and the same prompt converts noticeably better.

Cut the first six months after launch into months

Rush monetization and you'll raise a paywall before the base has grown, missing both. I think about it in segments.

For the first one to two months, set revenue aside and focus on building 100 people who keep coming back. During this window, pull your hypothesis about "which feature feels worth paying for" straight from how the app is actually used.

In months three to four, introduce ads and ad-free, or a subscription. An initial conversion of 1–3% is normal. Don't give up here — vary the timing, wording, and price of the prompt little by little.

In months five to six, tighten with data. Which inflow keeps users around, which features predict payment, at what moment churn happens. Only once you're here do you enter the stage of considering paid acquisition or expanding into companion apps.

The next move

If you're at the idea stage, before you write a line of code, go back to the first table and decide one thing: is your app opened every day, or used deeply a few times a month? Once that's set, ads vs. subscription and where to draw the free line fall into place on their own.

I'm still in the middle of figuring this out myself, but the fact that faster building frees up time for design is, for an indie developer, a genuinely big shift. Thank you for reading.

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.