Your vibe-coded app needs four things before its first session can convert: a short set of screens that frame the value, two or three questions that personalize the experience, a primer before any permission prompt, and a paywall placed deliberately rather than wherever the template put it. None of that is hard to design. The trap is hand-coding it, because onboarding is the part of your app that needs the most iteration, and native release cycles make iteration slow. Here is the minimum first session, and the fastest honest way to ship it.
Why working apps still lose their first users
Vibe coding got you a real app. Cursor, Claude Code, or an Expo starter turned an idea into something on the store in days. But AI coding tools optimize for making features work, not for making strangers care. So most vibe-coded apps open cold: the user lands on the home screen with no context, gets hit with an OS notification prompt within seconds, and never hears why the paid tier exists. Then they leave, and you have no idea where or why, because nothing in the first session is instrumented. The product is not the problem. The first sixty seconds are. And unlike your core features, this part was probably never in your prompt.
What the first session needs at minimum
You do not need a long guided tour. You need four jobs done, in roughly this order. This is the skeleton behind almost every well-built onboarding flow in consumer apps:
- Value framing. One to three screens that state the outcome your app delivers, in the user's words, before any real UI appears. Not features. The result.
- Two or three personalization questions. Ask what the user is here for, then visibly use the answer. Even one question makes the product feel intentional, and the responses become audience data you can target with later.
- A permission primer. Never let the OS dialog be the first mention of notifications or tracking. Show one screen explaining what the user gets, then trigger the prompt. Declines on the native dialog are expensive because you rarely get a second chance, so prime before you ask.
- A paywall with deliberate placement. Decide where payment enters the story. After value framing and before the home screen is the most common pattern for subscription apps, but the point is that it is a decision, not a default.
Where should the paywall go?
Placement matters more than most builders expect. RevenueCat's State of Subscription Apps 2026, based on over 115,000 apps, found that hard paywalls convert about 5x better than freemium: a 10.7% median versus 2.1%. That does not mean you should wall off your app tomorrow. It means the gap between paywall strategies is large enough to swamp most other optimizations, so shipping whatever your starter template happened to do is leaving real money on the table. Start with a paywall at the end of onboarding, after the value framing has done its work, and treat everything about it as testable: position, framing, trial or no trial. For a deeper breakdown of the options, see where the paywall belongs in onboarding.
Why hand-coding onboarding is a solo-dev trap
The whole advantage of vibe coding is iteration speed. Hand-coded onboarding takes that away. Every copy tweak, reordered screen, or paywall experiment becomes a native build, a store submission, and a wait for users to actually update. Apple now reviews 90% of submissions in under 24 hours, but review was never the real bottleneck: rollout and update adoption are. A one-line headline change can take a week to reach most of your users, which means you will run one experiment a month at best, and in practice you will run zero. Onboarding is precisely the surface that needs dozens of small, data-judged iterations. Building it as static native screens locks your most change-hungry code behind your slowest release path.
The fastest honest path: generate, publish, measure
This is the problem Setgreet is built for. You install a native SDK once, with support for iOS, Android, React Native, and Flutter; screens render as fully native UI, SwiftUI on iOS and Jetpack Compose on Android, with no web views. Then Build with AI drafts the flow: describe what you want, answer a short set of intake questions, and the assistant, which can pull context from your App Store listing, proposes a screen plan before generating anything. Only after you confirm does it produce a draft with real, editable native screens. You stay in control the whole way: nothing goes live until you publish, and every screen is editable in the visual flow builder. From then on, onboarding changes publish to your live app without an App Store release, so your iteration loop finally matches the speed you built the app with. The free tier covers the full loop: build flows, publish them, and measure how users move through them. And pricing is flat by monthly active users, never a percentage of your revenue.
Frequently asked questions
How many onboarding screens should a vibe-coded app have?
Enough to do the four jobs above and no more. In practice the right length varies a lot by category: health, fitness, and finance apps typically run much longer onboardings than utilities or entertainment apps, because personalization questions carry more of the value. Do not copy a screen count from another app. Decide which questions genuinely change the user's first session, cover value framing and permission priming, and cut everything else. For how screen counts differ across categories, see how many onboarding screens you actually need.
Do I need a paywall from day one?
If you ever plan to charge, yes. A paywall in the first session is not just revenue; it is the cleanest signal you can get about whether strangers value what you built. Even a soft paywall with a dismiss option gives you a conversion baseline, and you cannot improve a number you never measured. Adding one later is also harder than it sounds, because your early users will have anchored on free.
Can I update onboarding without an App Store release?
Yes, if the screens are delivered remotely instead of compiled into your binary. With Setgreet, the SDK ships in your app once; after that, flows are created, edited, and published from the dashboard, and changes appear in the live app without a new store submission. The initial SDK install is the only change that requires a release, and drafts never reach users until you explicitly publish them.