Coins vs subscription: a pricing-design lesson from freemium apps

NanoReads — Mon, 06 Jul 2026 14:18:50 +0000

I've been paying close attention to how reading apps charge for stories, partly as a reader and partly because it's one of the cleaner real-world case studies in freemium pricing I've come across. The short version: the split between "buy a chapter with coins" and "subscribe for everything" isn't a billing detail. It's a segmentation strategy, and it maps onto almost any content or SaaS product you might build.

Here's the setup for anyone who hasn't seen it. You open a story, the first few chapters are free, and then you unlock the rest one of two ways: coins, bought in packs and spent per chapter, or a subscription that opens the gate on everything. Most apps offer both. At first that looks redundant — why sell the same access twice? — but the two options are quietly serving two completely different people.

Coins are for the low-intent, high-control user

This is someone who isn't sure they'll finish, doesn't want a recurring charge, and wants to feel like every payment is a deliberate choice. Coins turn "unlock the next chapter" into a tiny, low-stakes yes. The genius is that the unit is small enough that the decision barely registers as spending — it feels like turning a page, not opening a wallet. This is the same psychology as buying one more level's worth of lives, and it captures revenue from people who would flatly refuse a subscription.

Subscriptions are for the high-intent, low-friction user

Once someone's binged a few titles, the per-chapter tap becomes a nuisance, and the recurring price becomes the convenience option. Same product, opposite framing: for this person the subscription removes friction rather than adding commitment. Crucially, you don't have to guess which type a user is — you let them self-select, and many convert from coins to a sub on their own once the math tips.

The free front door is doing the real work

A hard paywall optimizes for the wrong number. It converts a few committed buyers immediately and silently loses everyone who wasn't sure yet — which is most of your funnel. Free-first inverts it: the top of the funnel stays wide, and the product has to earn the unlock by making the free tier genuinely good. That constraint is healthy. It aligns the business with the user's actual enjoyment instead of against it. You get paid only after you've delivered enough to make someone want more.

The transferable lesson

Don't force one price shape onto two different intent levels. Offer a micro-purchase for the tentative user and a subscription for the committed one, keep a real free tier as the top of funnel, and let people migrate between them at their own pace. The mistake I see most often is picking one model on principle — "we're a subscription business" — and leaving the entire other segment unmonetized and, worse, un-onboarded.

If you want to feel the mechanics from the user's side (the best way to understand any pricing model), you can get NanoReads on iOS and watch how the free-then-coins-or-sub flow nudges you — it's a tidy, live example of exactly this segmentation. Steal the structure; it generalizes far beyond books.

The engineering problem hiding inside "AI writes a book"

NanoReads — Sun, 05 Jul 2026 22:42:52 +0000

When people hear "an app that writes books with AI," they picture one giant prompt and a wall of purple prose. That's the demo version. The moment you try to ship a real reading-and-writing product, you find out the generation step is the easy part. The hard part is everything wrapped around it — and it's a genuinely interesting systems problem.

A book is a state machine, not a prompt

The first thing that breaks the naive approach is length. Ask a model for "a novel" and you get a vibe: a strong opening, a soggy middle, and an ending that forgot how it started. What actually works is decomposition. You split the job into an outline pass, a character and world bible, chapter-by-chapter drafting, and then reconciliation passes that check every new chapter against everything written before it.

Each of those is a smaller, tightly constrained task, and constraint is where quality comes from. A model is dramatically better at "write chapter 12 given this outline and these established facts" than at "write a good book." The interesting engineering is in the orchestration layer that decides what context each step gets, not in the call to the model itself.

Continuity is the real cost center

Readers forgive an ordinary sentence. They do not forgive a character whose eye color changes between chapters or a subplot that quietly evaporates. So most of the effort goes into state management: carrying forward names, relationships, timelines, and unresolved threads so chapter 20 still agrees with chapter 2.

A pattern that works well is to treat the "story bible" as a structured, append-only record that every drafting step reads from and writes back to. Before a chapter is accepted, a validation pass diffs the new facts against the canonical state and flags contradictions for a rewrite. It's closer to database integrity checking than to creative writing, and it's where a naive pipeline goes from "impressive" to "actually usable."

The delivery format shapes the prompt

Here's the lesson that surprised me most: what you're building for changes how you generate. A product built around short, serialized chapters — the kind meant to be read in 20 to 30 minutes on a phone — optimizes for hooks and clean chapter breaks, not sprawling literary arcs. The reading surface reaches back up the stack and rewrites your generation constraints. If you ignore that, you get technically-correct chapters that nobody wants to keep tapping through.

Where it lands for readers and writers

The reason to solve all of this is that it opens up a genuinely new product shape: an app where the same person can read fiction and write and publish their own with AI assistance, all in one place. That's the bet behind NanoReads, a personalized reading-and-writing app and book marketplace on web, iOS, and Android — the reader-facing side of exactly the pipeline described above.

If you're building anything that generates long-form structured content — legal drafts, course material, documentation, fiction — the takeaway generalizes: stop hunting for the perfect prompt and start engineering the stages and the state around it. The prompt is maybe 20% of the system. The other 80% is orchestration and consistency, and that's the part that's fun to build.

Happy to go deeper on the consistency-diffing approach in the comments if anyone's wrestling with the same problem.

DEV Community: NanoReads