I added monetization to four previously free apps in a day. For each app I first decided what to sell, then designed the paywall.
In all four, the thing I'd chosen to sell had already shipped for free.
Is the feature you're about to sell already usable, for free, in your live build?
Four instances of the same shape
- One app: larger grid difficulties — already in the library's board picker.
- One app: per-group accuracy stats — that block was already on the stats screen.
- One app: spaced-repetition review — that is what the session engine already does.
- One app: multiple saved routes — recent-route saving already held five.
The app description doesn't tell you what you can sell. Neither does your memory or your spec document. Only the live code does.
What would have shipped
All four would have been changes that take away something people already use.
That isn't selling a new feature. To existing users it reads as a downgrade. And in a fleet with thin rating samples, a handful of one-star reviews moves rankings.
So the downside wasn't "zero revenue." It was negative. Another case where a paywall's appearance and reality diverged: the paywall in the screenshots.
What would you do?
You need to add a paywall to a free app. In what order?
- Pick the high-value feature and design the gate — the natural order. I did it four times.
- Count what's already free in the live code, then choose from what's left — only sellable things become candidates.
- Do both and cross-check — compare design intent against actual state.
Start with the second. The only check that works: before fixing the paid boundary, grep the call sites of each candidate. If it's there, leave it free and go find something to build.
And I deliberately left always-true entries in the gate struct with a comment saying why. When someone — including me — later asks "why is this free?", the answer needs to sit next to the code.
Three checks
- Did you grep the call sites of your paid candidates? The spec and the live build differ. The code is the verdict.
- Does the change read as a downgrade to existing users? Then it's clawback, not monetization, and you pay for it in ratings.
- Is the reason for each "always free" gate entry written in the code? Without it, the next person promotes it back to a paid candidate.
The honest part
I made the same mistake four times in a row. Having hit it on the first app, I still designed before reading code on the second. Only on the third did I change the order.
Confirming "this already exists" costs a few minutes per app. Redesigning costs far more. And I still kept getting the order wrong. I think it's because designing is fun and grepping isn't.
Redrawing the paid boundary also meant finding something new to build in each app, which expanded the scope of the work. This was not a "just bolt it on" job.