When does RevenueCat make sense instead of direct Google Play Billing?

When an app starts selling a “no ads” option, the first instinct is to protect every point of margin. If Google Play already offers Google Play Billing, why put RevenueCat in the middle?

The short answer: Google Play Billing processes the purchase, but it does not solve the whole monetization operation by itself.

RevenueCat adds a layer for managing entitlements, restoring purchases, validating receipts, handling inconsistent states, tracking revenue, and making a future iOS version less painful. That has a cost. The right question is whether that cost is higher or lower than building and maintaining the same system yourself.

The simple math

Use a simple product: no ads for US$ 1.00.

With a 15% Google Play fee, a US$ 1.00 purchase leaves roughly US$ 0.85 before taxes, chargebacks, currency conversion, and accounting.

In the model considered for this decision, RevenueCat costs US$ 0 up to US$ 2,500 in Monthly Tracked Revenue. Above that threshold, it charges around 1% of tracked gross revenue.

In practice:

• Before the free threshold: US$ 1.00 becomes roughly US$ 0.85.
• After the free threshold: US$ 1.00 becomes roughly US$ 0.84.

So RevenueCat does not change the initial economics of the product. When it starts charging, it reduces gross revenue by about 1 percentage point.

Monthly projection

With the product priced at US$ 1.00, the projection looks like this:

Purchases/month	Gross revenue	After Google Play	RevenueCat	Approx. net
100	US$ 100	US$ 85	US$ 0	US$ 85
1,000	US$ 1,000	US$ 850	US$ 0	US$ 850
2,500	US$ 2,500	US$ 2,125	US$ 0	US$ 2,125
5,000	US$ 5,000	US$ 4,250	US$ 50	US$ 4,200
10,000	US$ 10,000	US$ 8,500	US$ 100	US$ 8,400

The table shows the uncomfortable part: the store fee matters much more than RevenueCat. RevenueCat has a cost, but it is small next to the platform commission and, more importantly, next to the cost of breaking a purchase flow.

What looks cheap can become expensive

Integrating directly with Google Play Billing looks cheaper because it removes the intermediary fee. But direct billing adds work that must keep working after launch:

• Validate and persist receipts.
• Restore purchases after reinstalling or changing devices.
• Control local and remote entitlements.
• Handle refunds, cancellations, and pending purchases.
• Provide some form of operational audit trail.
• Test successful and negative paths.
• Repeat much of the work if the app reaches iOS.

In a small app, that work competes with product, acquisition, ASO, analytics, ads, and support. Saving a future 1% of revenue may not be worth delaying real market learning.

What RevenueCat does not replace

RevenueCat reduces operational work, but it does not remove Google Play from the critical path.

You still need to:

• Create products in Play Console.
• Configure prices, regions, and the correct product type.
• Register products and packages in RevenueCat.
• Configure Google Cloud for the Play Developer API integration.
• Connect a Google Play service account with enough permissions.
• Keep the service account JSON key out of the repository.
• Validate a real test purchase in Play Console.

One practical lesson: seeing prices in the app store screen does not mean RevenueCat credentials are validated. Better evidence is a successful RevenueCat credentials check and a Processed test order in Play Console.

That distinction matters. RevenueCat does not automatically create the trust bridge with Google Play. You still need to create or choose a Google Cloud project, enable the Google Play Android Developer API, enable Pub/Sub if you use Google developer notifications, create the service account, upload its key to RevenueCat, and grant permissions in Play Console. If that path is incomplete, checkout can open on the device while receipt validation still fails.

The indie app decision

For an indie app or a commercial MVP, RevenueCat is usually a reasonable trade: pay little or nothing at the beginning to reduce operational risk.

For Daily Sudoku, the decision was to keep RevenueCat while the app validates revenue. Google Play Billing remains the purchase processor on Android, while RevenueCat owns the product layer: who bought, what is active, how restore works, and how problems are observed.

This does not need to be a permanent decision. If purchase revenue reaches something like US$ 10k-20k/month, it is worth reopening the analysis:

• How much does RevenueCat cost per month?
• How much engineering time would a direct integration need?
• Does the app already need iOS or subscriptions?
• Is there a team to maintain payment edge cases?
• Can better terms be negotiated?

The decision is less about SDK size and more about operations

For a small app, the comparison is rarely just “which SDK is smaller?” Google Play Billing gives direct control and fewer moving parts, but it also leaves more operational work inside the app and backend. RevenueCat adds another vendor, but it centralizes customer state, restore behavior, product mapping, webhooks, and support tooling.

The right question is not whether a wrapper is elegant. The question is who will answer support when a purchase exists in Play Console but the app does not unlock the feature. If that person is also the developer, designer, support agent, and release manager, observability matters more than theoretical purity.

A direct Billing integration can still be right when the catalog is tiny and the app can tolerate a slower support loop. RevenueCat becomes more attractive when you need to inspect customer profiles, support multiple stores, recover from receipt edge cases, or add subscriptions later.

What to validate before choosing

Before committing, test the boring paths:

• product not available because the tester account is wrong;
• purchase cancelled midway;
• purchase succeeds but entitlement delivery fails;
• restore purchases on a fresh install;
• sandbox data visibility in the dashboard;
• customer identity when the app is reinstalled or migrated.

Those paths reveal the real maintenance cost. A purchase integration that works only on the happy path is not done; it is a demo.

A conservative default for indie apps

Our bias for indie apps is to buy back operational clarity when the cost is reasonable. If purchases are important to revenue and the team is small, the dashboard and customer history are not luxuries. They are part of the support system.

That does not mean every app needs RevenueCat. It means every app needs a clear place to answer: what did the store say, what did the SDK receive, what customer did we identify, and what local state did we unlock? Choose the stack that makes those answers cheapest.

The catalog shape changes the answer

A single lifetime purchase, a pack of consumable credits, and a subscription are not the same operational problem. A lifetime entitlement mostly needs reliable restore. Consumables need delivery tracking and idempotency. Subscriptions need renewal, cancellation, grace period, and account-state handling.

That catalog shape should influence the tooling decision. The more the app depends on ongoing customer state, the more valuable a dedicated purchase backend becomes. The simpler the catalog, the easier it is to justify staying closer to Google Play Billing.

This is also why teams should avoid designing monetization only from the UI. The purchase model should be judged by support and recovery paths, not only by the button label in the shop.

The best choice is the one that makes failed purchases explainable. If a tool reduces the time between a support message and a confident answer, that saving belongs in the decision, even if it does not appear in the SDK comparison table.

Conclusion

Does RevenueCat reduce margin? Yes, after the free threshold.

But the better question is: does that margin reduction buy enough time, safety, and focus?

For an app still validating revenue, it usually does. For an app already at scale, the decision deserves a fresh analysis.