Trap: Indecision Costs a Rewrite
Adding ads and purchases without a clear model creates cluttered free tiers and confused store listings. This guide explains how to pick one model using four questions before writing code.
Most new Android developers treat the business model as an afterthought. They add AdMob "for now" and promise a purchase "later," assuming they can sort out the payments logic once the code works. That is the trap. The result is an app whose free version is either so generous nobody pays or so cluttered nobody stays, a purchase that nobody can describe in one sentence, and a store listing that cannot honestly say what the user gets. Changing the model after launch is possible but expensive: users who installed a free app do not enjoy discovering a paywall, and an app that sold a lifetime unlock cannot easily turn that into a subscription. Ten minutes of deciding now saves a rewrite later.
The book opens its first chapter with exactly this warning under the heading "Pick a Business Model Before You Write Code." It argues that the business model decides your dependencies, your consent obligations, your Data safety answers, your store listing wording and whether you need a server. This post covers the five common models, the four questions to help you choose, and the one-paragraph statement you must write before adding any SDKs.
The trap: mixing models without a plan
The usual way people fall into this trap is by combining ads and purchases without defining the boundary between them. You might think that showing ads and offering a remove-ads purchase is simple, but the book notes that "most small apps end up as 'ads plus a remove-ads purchase', which is two models in one." This hybrid approach needs both halves done properly. If you do not decide what the free experience is upfront, you risk creating an app where the free tier feels like a trap or the paid tier offers no clear value. The book states that the result of this indecision is an app whose free version is either so generous nobody pays or so cluttered nobody stays. You must define the boundary before writing code, not after.
The five models compared
Before choosing, you need to understand what each model requires in terms of user payment, backend work, and disclosure. The book lists five common models:
- Paid app. The user pays once on Google Play before installing. There is nothing to build in the app, but the listing has to sell the app without a trial.
- Free with ads. The app is free and shows AdMob ads. You need the ads SDK, a consent flow (Chapter 3) and honest ad placement (Chapter 4).
- One-time unlock. The app is free and a single in-app purchase unlocks a feature set or removes ads permanently. You need Play Billing (Chapters 5 and 6).
- Subscription. The user pays on a recurring schedule for continuing value: content, sync, a hosted service. You need Play Billing, a way to handle renewals, holds and cancellations, and in practice a backend (Chapter 7).
- Hybrid. Ads for free users plus a purchase or subscription that removes them. This is what most small utilities do. It needs both halves.
Most developers gravitate toward the hybrid model because it seems to capture both casual and power users. However, the book warns that this requires implementing two distinct revenue streams correctly. If you choose a paid app, you avoid backend complexity but must convince users to pay upfront. If you choose a subscription, you accept recurring billing complexity and likely need a server.
The four questions to decide
The book provides a decision framework consisting of four questions, asked in order. The first "yes" usually decides the model. If the answer to all four is "no," a free app with a few well-placed ads and a remove-ads purchase is the honest default. You should ask these questions before writing any code:
- Does the app cost you money every time it is used (a server, an API, storage)? Then a subscription matches cost to revenue. A one-time price will eventually be paid off by heavy users and keep costing you.
- Is the value one complete thing (a tool that just works)? A paid app or a one-time unlock is simpler for everyone.
- Is the audience large and casual (a flashlight, a QR scanner, a timer)? Ads fit, because few people will pay for something they use for ten seconds.
- Would ads damage the core use (a journal, a medical log, a focus app)? Then do not use ads at all; sell an unlock or a subscription.
These questions force you to align your technical constraints with user expectations. For example, if your app requires a server that costs money per request, question one dictates a subscription. If your app is a simple utility used for seconds, question three suggests ads are more appropriate than a paywall.
The Google Play Billing requirement
Once you have selected a model involving digital goods, you must comply with Google's Payments policy. The book states that at the time of writing, the policy page in Play Console Help ("Payments") says that apps charging for downloads must use Google Play's billing system, and that in-app purchases of digital features, content or services must use it too (with specific exceptions listed in the policy). The examples it lists include virtual items, subscription services and, word for word, "app functionality or content (such as an ad-free version of app or new features not available in the free version)."
The same page says Play billing must not be used for physical goods, physical services (transport, food delivery, event tickets and similar) and bill payments. So: a remove-ads purchase goes through Play Billing; selling a T-shirt from your app does not. You must read the current policy page before planning anything other than plain Google Play Billing, as regional programs and exceptions come with their own requirements and fees.
The one-paragraph model statement
The final step is to write down your decision in a single paragraph before you start Chapter 2 of the book or begin coding. This statement becomes your consent message settings, your Data safety answers, your paywall text and your store listing's first line. If you cannot write it, you are not ready to add an SDK.
For example: "Free, with a banner on the main list and an interstitial after every third saved item. A one-time Remove Ads purchase removes all ads forever. No other purchases."
Checklist
- [ ] Answer the four decision questions in order and identify the first "yes."
- [ ] Select one of the five models (Paid, Free with ads, One-time unlock, Subscription, or Hybrid).
- [ ] Verify that your chosen model complies with Google Play's Payments policy for digital goods.
- [ ] Check if you need a backend server for subscriptions or recurring value.
- [ ] Write a one-paragraph model statement describing the free experience and the paid upgrade.
- [ ] Ensure your Play developer account is linked to a Google payments profile.
- [ ] Ship an internal build with the Play Billing Library before configuring products in Play Console.
