Most teams argue about how many screens an onboarding flow should have, and the evidence points somewhere else. In a study of over a thousand onboarding flows, the average app runs 25 onboarding screens, and some of the apps with the longest flows are also among the most successful. The useful question is how quickly a new user reaches the moment the product pays off, and what each screen does to get them there. Reach the aha moment, then sell the outcome Name the aha moment before you design screens The framework in the first study is short enough to put on a whiteboard: sign up, set up your account, then reach the aha moment. In the speaker's words, that is where you actually feel the product's value. For Airbnb it is making a first booking, for Netflix it is finding and watching a show, and for Mobbin it is finding a screen or animation you love and saving it. Each definition is specific enough to measure, which is the part a team can act on. You sign up, set up your account, you hit the aha moment. That's where you actually feel the product's value. [moment: 45] Outcome screens beat feature lists The welcome screens that held the speaker's attention shared one habit: they sold the outcome instead of listing features. Timehop's welcome screen shows the product in action on mobile and desktop. Runkeeper uses animation so a user gets a feel for the app without reading a word. Elma lets people try the core experience before creating an account, which the speaker calls rare among apps with AI features. The limit is that these are curated examples. The source reports no conversion numbers for any of them, so the claim rests on observation, not measurement. Length matters less than friction and value Long flows that feel short Duolingo runs about 60 screens before sign-up, and the presenter insists the flow does not feel long. The walk-through is concrete: choose a language, start a first lesson, finish it, then create an account. By the time you reach sign-up, you have already gone through 60 screens. Cake Equity faces a harder case. Equity and vesting schedules are dry, so it pairs plain copy and tooltips with small touches, such as a password field that checks off requirements as you type. The presenter's point is that these details make a long flow feel effortless, though the source does not say how much drop-off they prevented. [moment: 345] Paywalls inside the flow The second study's founder reports that every contextual paywall tied to a single feature failed his A/B tests, because users concluded they had to buy each feature separately. Moonly moved back to one consistent paywall. Timely shows a full page of social proof before its paywall. Grammarly's tailored pricing plans, based on quiz answers, are credited with almost a 20% lift in plan upgrades. That upgrade figure is the presenter's own, given without a published baseline, so treat it as a hypothesis to test rather than a benchmark. Ask at the right moment, and know when to skip Permission pre-prompts and friction Many apps show a custom screen before the OS notification pop-up. The speaker says it apparently improves accept rates significantly, but the source gives no percentage, so the size of the effect is unknown. Web onboarding is also 21% shorter than iOS, which the presenter attributes to mobile carrying more permission and paywall screens. House split its sign-up form into multiple screens and reports a 15% conversion increase. That result runs against the instinct to cut every step, and it suggests friction added in one place can remove friction in another. [moment: 477] When onboarding is the wrong answer The most useful disagreement in this material is with the default itself. The speaker says, 'I don't think there's one right or wrong way to design an onboarding flow that's best in class.' For Mobbin and AI chat apps, where the product speaks for itself and the first prompt is where users find value, the best experience may be to get out of the way. The source does not measure outcomes for that approach, so it remains a judgment. The Moonly founder applies the same skepticism to login, asking why it is needed before adding one. That question is a method, not a finding, and it works best when a team tests the answer. Name the aha moment for your product and measure whether new users reach it. Sell the outcome on welcome screens: Timehop and Runkeeper show the product rather than list features. Accept a long flow only when each screen moves the user toward value, as Duolingo's walk-through does across about 60 screens. Test one consistent paywall before any contextual paywalls; every contextual variant in Moonly's tests failed. Pilot a permission pre-prompt and measure accept rates yourself, since the source gives no effect size. Start with your current flow, screen by screen, and mark the point where a new user first feels the product's value. Anything after that point is a candidate for cutting. Anything before it should be defended with a number.