The mobile app onboarding system I reuse across my apps

Someone who opens your app for the first time has already shown enough interest to download it. Before they decide to subscribe, onboarding has three jobs: show the value, get them involved, and relate the app to the problem they came with.

This is the onboarding system I reuse across my apps, from the first screen after install to the paywall, plus the prompt I give a coding agent to build it. To show it end to end I built a demo with it: Leafkeep, a fictional plant-care app. Its prices are examples and it makes no real purchases.

The five stages

Each stage has one job, and a stage can take more than one screen. In Leafkeep the five stages span 12 screens, including the paywall.

1Establish the valueShow what the app does before asking for anythingWelcomePlant check2 screensPrompt: 1 · Welcome and value
2Get them involvedA few relevant questions, one at a timeNameExperienceHardestPlantsGoalRoutine6 screensPrompt: 2 · Identity and 3 · The quiz
3Reflect their answersShow that what they said shaped the experienceHere's what we heard1 screenPrompt: 4 · Reflect
4Build a personalized resultSomething concrete made from their answersBuildFirst week2 screensPrompt: 5 · Build and payoff
5Connect it to the offerA paywall that refers back to the resultPaywall1 screenPrompt: 6 · Paywall

The five stages, the Leafkeep demo's screens for each, and the phase of the prompt that builds it.

Establish the value. Show what the app can do for them before you ask for anything. Leafkeep opens on a promise, feel more confident caring for your plants, then lets you try a quick check on a sample plant: tap the soil, the light and the leaves, and each tap adds an observation.
Get them involved. Ask a few relevant questions, one per screen: their name, their experience, what they find hardest, how many plants they have, what they want help with and when they usually have a minute.
Reflect their answers. Show them that what they told you shaped the experience. “Maya, here’s what we heard”: six plants, just getting started, watering and light, weekends. Each answer is a chip they can tap to change.
Build a personalized result. Use the answers to make something concrete they can explore before subscribing. Leafkeep builds a first week of care: watering and light lead the checks, weekends set the routine days and the experience level sets how detailed the notes are. The short build animation is a design choice, not how long anything takes.
Connect the value to the offer. The paywall refers back to what they just saw: “Maya, keep your routine going”, their answers, and benefits that follow from the difficulties they picked. Then the plans and a clear decision.

The prompt builds this in six phases. Identity and the quiz are separate phases, but both serve stage 2.

The personalization contract

This is the rule that makes the questions part of the system rather than a survey. Every answer has to visibly change something before or at the paywall: the reflection, the preview or the paywall framing. If an answer changes nothing, cut the question; every question costs the person effort. And never vary prices, eligibility or terms by answer.

NameMayaReflectionPaywall headline
ExperienceJust getting startedBeginner notes in the plan
Hardest · pick 2Watering, lightWhich checks lead the planPaywall benefits
Plants · slider6Plan covers 6 plantsPaywall subtitle
GoalBuild a routine I can keepPaywall headline
RoutineWeekendsRoutine days in the planWeekend reminders

!If an answer changes nothing, cut the question. Prices never change with answers.

In the Leafkeep demo, every answer is saved and shows up again before or at the paywall.

Reuse the structure, change the content

The structure carries across apps. The audience, the questions, the examples and the offer change with the product. A fitness app might ask about experience and goals; Leafkeep asks about confidence with plant care and the help someone wants.

How long should onboarding be?

Leafkeep uses 12 screens including the paywall, and that isn’t a rule. A short flow can leave important questions unanswered. A long one can ask people to do too much before they’ve seen enough value. Review what each screen contributes, then measure where people drop off.

Reported example · one app

+16%trial starts

Coconote founder Brett Bauman said on Sub Club, RevenueCat's podcast, that roughly doubling their onboarding to about 15 screens increased trial starts by 16%.

One founder's own report, not a study. They also added personalization and social proof at the same time. Listen to the episode ↗

Useful when you're testing longer and shorter flows. Results vary by app, so test in yours.

What to measure

The goal is subscriptions, not finishing onboarding. Track how many people start onboarding, reach the paywall and subscribe, on the same group of people. If you offer a trial, count trial starts and paid conversions separately.

TrackStart onboardingeveryone who sees screen one

TrackReach the paywallthe offer is seen

The resultSubscribestart → subscription, same cohort

With a trial Trial starts Paid conversions count them separately

!Finishing onboarding isn't the result. Subscribing is.

What to track, on one cohort. Illustration only: no real numbers.

The prompt

Fill in the bracketed fields, then give the whole prompt to the coding agent working in your app’s repository. Review the screen-by-screen plan it returns before it builds anything. Whether it lifts conversion is something you measure in your own app.

I used it with Claude Code to build the Leafkeep demo shown above.

Onboarding prompt65 lines

Build the first-launch onboarding for my subscription app [APP], from the first screen after install to the subscription decision.

App: [ONE-LINE CONCEPT]
Audience: [WHO DOWNLOADS IT, AND THE PROBLEM THEY ARRIVE WITH]
Core promise: [THE OUTCOME THEY CAME FOR]
Paid value: [WHAT THE SUBSCRIPTION ACTUALLY INCLUDES - VERIFIED FEATURES ONLY]
Offer: [PRODUCTS, PRICES, TRIAL TERMS, PAYWALL PLACEMENT (END OF ONBOARDING / AFTER ACCOUNT CREATION / DISMISSABLE), ACCOUNT RULES]
Stack and design system: [STACK, THEME, EXISTING COMPONENTS]
Screen budget: [E.G. 10-14 SCREENS INCLUDING THE PAYWALL, OR ASK FOR A RECOMMENDATION]

First, inspect the existing onboarding, theme, subscription setup, persistence and analytics. Preserve current work and running experiments.

Build a first-launch sequence that ends at the subscription decision.
Keep the work to the screens before and including the paywall. Don't turn it into a home-screen tour or a tutorial for the whole app.

THE ARC - six phases, in this order. The order is the method.
1. Welcome and value. 1-3 branded screens that land the outcome before asking for anything. Warm, outcome-first, no feature jargon. Make the benefit concrete with a short visual example.
2. Identity. Ask for a first name if later copy will use it. Add a profile question only if the app needs that context.
3. The quiz. 2-5 screens that make the person feel understood:
   - their difficulty or pain (multi-select, "pick up to 2")
   - the outcome they want (multi-select, "choose up to 3")
   - their starting point or level (single-select)
   - their rhythm or commitment (single-select, or a slider)
   One question per screen. Icon option cards with an obvious selected state (accent fill and a checkmark). State the selection cap in the subtitle. Add a reassurance line where a choice feels binding ("You can change this later"). Use sliders only for continuous or emotional inputs.
4. Reflect. Echo their answers back so the app has visibly listened: "{name}, so the hardest part is X." The strongest version takes something they entered and transforms it in front of them, if your core loop can run on their data.
5. Build, then the personalized payoff. A short "building your [plan]" moment of 2-4 seconds, with captions naming their actual choices, that lands on a real artifact made from the answers: a first plan, starter tasks, their library, a first session. The answers must shape that artifact. A loading screen over nothing is lying, and so is claiming AI analysis or scanning that isn't happening.
6. Paywall. The headline refers to what was just built for them. Then the real offer and a clear decision.

THE PERSONALIZATION CONTRACT - non-negotiable
Use the answers to change the reflection, value preview or paywall framing.
For every question, map: answer -> saved field -> visible change before or at the paywall. If a question's answer changes nothing, cut the question; every question costs the person effort. Never vary prices, eligibility or terms by quiz answer.

MAKE IT INTERACTIVE - pick 2-3 that fit the brand; don't stack all of them
- Staggered entrance reveals and spring transitions, respecting Reduce Motion. Default yes.
- Let them do the core action once inside onboarding, with haptics and a small celebration. This is usually the strongest moment in the flow.
- A mascot or guide character, if the brand has one.
- A first result already visible at the end, such as a lit first day or a first saved item, only when they did something in onboarding to earn it.
- A fear-to-hope reframe, only where it's honest.
- Social proof only if it's real: verbatim, attributed reviews. No invented testimonials, ratings, user counts or "most popular" tags without data behind them.

BEFORE YOU BUILD
Return a screen-by-screen plan: exact copy, purpose, input, selected states, answer mapping, transition and CTA. Explain how each screen sets up the next one and how the paywall follows from the payoff. State the total screen count including the paywall. Flag any benefit you can't verify in the product. Wait for my review.

IMPLEMENTATION
- A step enum driving an index-based paged flow, back navigation, a segmented progress bar and spring transitions.
- One reusable option card and one screen scaffold with a pinned bottom CTA and a quiet secondary action.
- Save the answers and current step after every screen, so the flow resumes where they left off. Editing an earlier answer updates everything downstream.
- Design tokens from the app's theme; no one-off styles.
- Put the flow behind a variant flag from day one, so you can A/B test it.
- Don't ask for permissions such as notifications or the camera before they have a clear purpose.

PAYWALL AND PURCHASES
Keep the existing subscription provider and its localized prices. Show the price, billing period, renewal and trial terms, plus restore, terms and dismissal paths. Handle loading, unavailable offers, pending purchases, cancellation, failure and restore without unlocking access before the entitlement is confirmed. Keep purchase state separate from onboarding completion.

ANALYTICS - every screen
onboarding_started {variant} - onboarding_screen_viewed {screen, index, count} - onboarding_backgrounded / onboarding_resumed - onboarding_completed {key answers, nothing sensitive} - paywall_viewed {placement, dismissable, variant} - plan_selected - purchase_started / purchase_cancelled / purchase_failed - trial_started - subscription_confirmed.
Report start -> paywall, paywall -> subscription and start -> subscription on the same cohort. Count trial starts and paid conversions separately.

PROOF IT'S DONE
Fresh install, then the full flow on a device or simulator. Show me:
- every answer reflected in the reflection, payoff and paywall;
- resume working mid-quiz, and edited answers updating downstream;
- the debug log of every event;
- a sandbox purchase and a restore at the paywall.
A working build doesn't prove a conversion lift; measure that in production. Don't publish or release the app.