+ FREE RESOURCE · BUILDER CRÉATIF

What makes a user pay. And what makes them leave.

Five entry structures that decide the revenue, before the first line of code.

The decision that weighs most on what an app brings in is not made in the code. It is made in the first two minutes of use: what you give before you ask, and what you ask before you have given.

That is where most of the loss happens, and it is decided at design time — not patched afterwards. This page lays out the five possible entry structures, what each one really costs, and the six mistakes that make people leave before price is even a question.

This page is not about technology. All five structures are built the same way. What changes is what you show, and when.

+ 01 · THE PATH

The path, and where it leaks.

Between the install and the payment there are four steps. People leave at each one, and never for the same reason. Three of those reasons are inflicted on you: the store listing, the mood, the time of day. Only one is entirely yours.

Four leaks, only one you truly hold at design time: the moment the app becomes visibly useful.

The “oh, I see” moment — the first time the app is visibly useful — is the only step you truly control at design time. You decide where it sits, how many screens it takes to reach, and what you are allowed to ask for before it. The rest of the path hangs on that one decision.

+ 02 · THE FIVE STRUCTURES

The five entry structures.

There are not thirty of them. There are five, and the choice is made before design, not after launch. Each fits a precise situation and carries a precise counter-effect. Choosing without seeing the counter-effect means meeting it six months later.

payment doesn't exist yet

Everything open, payment comes later.

Who it fits

A business that already sells and whose customers come back on their own: a network of shops, a service with regulars. The app has to be adopted first, monetised later.

What it gives

The most people get in and use it. You see who comes back before asking for anything — so you know who to ask.

The counter-effect

The app becomes a free service in people's minds. The day you introduce payment, you negotiate it with users trained to pay nothing.

value first, then price

Payment asked once the first value has landed.

Who it fits

Most cases. An established software product whose mobile version must prove in two minutes that it actually does the job, not just mirror the same menu.

What it gives

The request arrives when it is legitimate. The person has seen what they are buying: the question is no longer “what is this for”, it is “is it worth the price”.

The counter-effect

You must be able to name that first value and reach it fast. If nobody on the team can point to it, this structure silently becomes “everything open” without you deciding it.

no commitment at the door

The trial with no card.

Who it fits

A product whose value shows over several days of use, not on one screen: a business tool, activity tracking, team management.

What it gives

Lots of entries, no friction, and a trial base wide enough to see where people drop off — often worth more than the trials themselves.

The counter-effect

The end of the trial is a cold wall. The person never made a commitment; the day you ask for the card, the sale is still entirely ahead of you.

commitment, then reminder

The trial with a card, plus a reminder before the charge.

Who it fits

A high-ticket product sold to professionals, where you would rather have few serious trials than many curious ones.

What it gives

The people who get in have already decided. And the reminder prevents the charge nobody saw coming — that is what actually protects your store rating.

The counter-effect

Far fewer entries, so far less to learn. And without the reminder, you build revenue on people who feel trapped: they write it in the reviews, and you pay for it again in refunds.

nothing before payment

The wall: paid from the very first screen.

Who it fits

An already-known brand whose promise is sold elsewhere: in store, by a sales team, by content that has already done the work before the install.

What it gives

The highest revenue per install, and a user base that chose to be there. Nothing to convert later, nothing to renegotiate.

The counter-effect

Everything rests on what happens before the install. If the store listing carries the promise alone, the payment screen will not save anything — it only records the outcome.

Technical note, once and for all: all five plug into the same billing tooling — RevenueCat, Stripe. The choice is not made there.

+ 03 · WHAT MAKES THEM LEAVE

The six mistakes that make people leave.

None of them show up in a spec. They show up in the numbers three months later, when going back is expensive.

Asking for an account before anything has been given.

An account is a price. You are charging it before showing the goods.

Asking for the store rating at the wrong moment.

The question lands during a load, an error, a hesitation. The rating that comes out follows you for months.

Claiming notification permission before earning it.

A refusal cannot be re-asked. You lose the channel for the entire life of that install.

A payment screen that does not show the price.

Hunting for the price is doubt. And doubt, at the moment of paying, is settled by closing the app.

A subscription nobody can figure out how to cancel.

A hidden exit holds nobody. It turns a quiet departure into a one-star review and a refund request.

A loading screen with nothing to look at.

Empty waiting feels twice as long. Show what is being built, or show the result before it is finished.

+ 04 · THE PROOF

The proof.

Two figures, one product, Evolum. We built it and we ran it.

Evolum: from 0 to €120,000 in monthly revenue, with no fundraising.

Evolum: 4.8/5 across 11,000 reviews, obtained by moving the moment the app asks for the rating. It was asking at the wrong moment; changing that moment changed everything.

Nothing changed in the product. Only the position of the question on the timeline changed.

The second one is the cleanest demonstration on this page. Same app, same users, same feature: one moment moved. That is exactly what the five entry structures are about — not what the app does, but the order in which it does it.

+ TAKE IT WITH YOU

Get the grid by email.

The five structures and the six mistakes, on one page you can put on the table before the design workshop. One email, nothing else.

+ WHAT'S NEXT

Which of the five applies to your app?

Thirty minutes on your product: where your “oh, I see” moment sits, which entry structure it allows, and what to change before writing code. If your current model already holds, we will say so.

Let's talk about your app