Charging for access to your content

A one-off purchase is decided on what the reader has in front of them. A subscription is decided on what they think they'll find next month.

That's the whole difference, and it drives the rest of this guide. So the question isn't "what content is worth money", it's "what gives someone a reason to come back". An archive is often worth less than an appointment: ten years of articles available all at once are consumed in a week and don't justify a second month, whereas a weekly column, a series that keeps going, or a format your reader finds at a fixed time justify every renewal.

Your offer is prepared from Monetization › Memberships › Settings guide, a screen listing the six configuration steps with their status, which you come back to as long as one of them is still outstanding.

There's no way around them, and it's better to know them before you've built your app around memberships.

You need an app on the stores. Memberships rely on Apple's and Google's payment mechanisms: without an iOS or Android app, there's nothing to plug them into. The Standard plan only produces a Progressive Web App, so it doesn't allow selling memberships. That becomes possible from the Premium plan up. The membership system is an extension, and its listing shows the price that applies to your app.

And it commits the rest of your app. The in-app membership rests on an authentication flow of its own, and that flow is mutually exclusive with the other one. Switching memberships on makes everything described in "Building a community with your app" and "Creating a loyalty program in your app" unavailable: standard user accounts, groups, per-section rights, chat, the loyalty card, the club card and coupons. The back office warns you at the moment of switching, so that the choice is deliberate.

Settle it before you build, not after. On the economic trade-off itself, the store commission and what it buys, the guide "Making money with your content app" sets out the comparison with the other ways of monetizing.

This is the decision that makes or breaks a subscription, and it's the only one the back office doesn't take for you.

It sets a single rule, and it's a floor: you need at least ten restricted items for the extension to work, and the restriction screen states it in black and white. It says nothing about a maximum, because there isn't one. Everything above ten is your judgment.

The natural instinct is to lock everything, on the grounds that every item left open is a subscription lost. The opposite happens. A visitor who can't read anything has no way of convincing themselves your work is worth their money: you're asking them to pay in order to find out, which nobody does. Your free content isn't lost revenue, it's your argument.

The symmetrical risk exists too. If your paid content is just the same thing in greater quantity, it's judged on volume, and volume keeps nobody. What keeps people is a difference in kind: a format the free content doesn't have, earlier access, a depth you couldn't afford to give away.

A good way to settle it: your reader should be able to name what they're buying. "The Monday analyses", "the series on the trials", "the full episodes" are answers. "Some of the articles" isn't one, and restricting item by item produces exactly that. Choose by kind of content rather than piece by piece, even though the setting itself is applied one item at a time.

The scope is clear-cut, and it's worth looking at before you choose your content sources.

The middle row is the one that weighs most on a project. What you publish from your back office can be sold; what you pull in from elsewhere is displayed, freely. So an app fed by a WordPress feed or a YouTube channel serves content that stays open to everyone, and its subscription offer is built on what it publishes itself. Worth knowing before you choose your sources.

Restriction is applied from Content › Content list, in the Restriction column, by clicking the pill on the row, which toggles between Free and Paid. You can also tick several items and switch them all at once.

The same screen carries a restriction filter: free, paid, or all. That's your editorial dashboard, and the only place that tells you what someone who isn't subscribed actually sees. Get into the habit of opening it on "free" now and again: if the list is empty or trivial, your app isn't convincing anyone to subscribe any more.

You don't have to choose between showing everything and hiding everything. On an article, two settings decide what a non-subscribed visitor sees: they're in the Restriction tab, under the Free preview heading, and that's where desire is created.

The first lever is the number of visible elements, from zero to five. An element is a block of your content, a paragraph, an image, a video. The cap of five is structural: you never show half of a long article, only its opening.

The second is the summary in lists. The Display the summary in your list pages toggle decides whether the summary stays visible on your list pages while the content is paid. It's often the more profitable of the two, because it acts where your reader is moving around, before they've even clicked.

Other content is set as a whole. An event, a video, a podcast or a map point is free or paid, with no middle step: their Restriction tab carries only the choice between the two pills. If your offer rests on those formats, desire is built elsewhere, in the episodes you leave open and on your subscription page. It's also an argument for pairing a video or audio series with articles, which can open halfway.

Where to cut. The right stopping point is where the promise has been made but not yet kept: the reader knows what it's about, they don't yet know what you have to say about it. At zero elements you're putting up a wall, and a wall is only climbed on a reputation you've already made. At five on a short piece, you've given everything and the subscription serves no purpose.

That last remark has a consequence: a short format handles previews badly. If your paid content fits in six paragraphs, the useful lever isn't the preview but the summary, and your argument moves to the subscription page.

A reader who sees nothing misses nothing. That's the most common flaw in a badly tuned subscription: the paid content is invisible to non-subscribers, so nobody misses it, so nobody subscribes. Four surfaces exist to answer that, and the settings guide gathers them together.

The Subscribers sticker marks your paid content, in lists and in the content itself. In a list it takes the form of an icon or your logo. That's what keeps your offer visible at all times, without writing a word.

The Subscription block in the restricted content is what a reader meets at the end of their preview: a title, a description, a button to subscribe and a button to log in, all in your colors. Write that title as a promise, not as a barrier. "This article is for subscribers" describes a lock; "The rest of this analysis, and the ones to come" describes what you get.

The Subscription page is your sales page. It carries a title area with your logo, then a headline, a description and a button label per offer, which lets you say why the quarter beats the month rather than lining up three prices. Its footer carries the terms and the restore-purchases link, which lets someone changing phones find their subscription again.

Each offer's details are inserted through tokens. They give you a preview of the page while you're testing; once the app is published, the price and duration shown come from the stores, so they follow the real local price in each country without you having to keep them up to date.

The Progressive Web App version of this page has a different job. Since the subscription goes through the stores, it lives in the native app: so this page is there to take the visitor to it. It holds a title and a description, and the default title says it plainly, "Download our app and become a Premium member". It's your bridge from the web to the app, and it deserves the same care as the rest.

The Widget to promote the subscription offer displays your offer in the app's navigation, with its title, its description and its button.

One requirement ties all four together: they have to say the same thing. A sticker promising premium, a block talking about reserved content and a subscription page selling a community describe three different products. Write the promise once, then decline it.

The form for an offer asks for a name and a description, which will be read in the stores, a duration, a price, and if you want a trial period.

Five durations are offered, from a week to a year, taking in the month, the quarter and the half-year. The free trial runs from three days to a year, and the subscription starts at the end of it at full price, unless it's cancelled in the meantime.

The price is set separately for the two stores, because they don't ask for it the same way. Apple wants a price including tax, chosen from a grid of tiers. Google wants a price excluding tax and works out what the user will see itself. Both convert at the most recent exchange rates.

One last setting, in the additional options: disabling ads for your members. If your free content is funded by advertising, the subscription then sells two things at once, access and comfort.

A client account, though, is never mandatory. The Subscription process screen gives you two options: "An account is optional", which lets people subscribe as guests, or "An account is suggested", which offers account creation after subscribing without ever forcing it. It's a real trade-off. Asking for nothing removes friction at the exact moment your reader has decided; offering an account gives you an email address and a way to find them again, but only for those who accept. On a subscription bought on impulse, the friction costs more than the address earns.

You then follow your subscribers from Monetization › Memberships › Subscribers, which lists active subscriptions, expired ones and your users, with a data export. Expired subscriptions deserve a regular look: it's the only measure you have of your ability to keep your promise over time.

Two things to prepare, and the first one takes time.

Restrictions only take effect once the app has been published or updated on the stores. But the stores require content that's already restricted before they'll accept your app with its subscriptions. In between, during review, your restricted content isn't accessible and nobody can subscribe yet. That isn't an incident, it's the normal sequence, and it can be planned for: try not to have it land when you're expecting the most traffic.

The terms of service and the privacy policy are written in Settings › Privacy center, in the terms tab, and the settings guide takes you there. Both stores require them as soon as you sell a subscription.

The rest belongs to the step-by-step, and our help center covers it entirely: the contracts and bank details in App Store Connect, the payment profile in Google Play, creating the products on the store side, and testing your subscriptions before publishing. Open it when you get to the configuration; the "Monetize your app with subscriptions" section follows exactly the steps of your settings guide.