You ship the app. Someone signs up. They land on a dashboard with nothing in it. A sidebar they don't know how to use. Maybe a big empty white box in the middle with an icon and the words "No projects yet."
They leave. You never hear from them again.
This isn't a bug in the code. It's a missing spec. And it's the most common gap in every AI-built app, because no AI coding tool will design your app onboarding flow for you. Not Cursor, not Lovable, not Bolt, not v0. They'll give you authentication, a database schema, and some routing. The 90 seconds after a user first logs in? That part is yours.
The first 90 seconds matter more than almost anything else in your app. If a new user hits your dashboard and doesn't know what to do next, most of them won't come back. Not because the product is bad. Because they never got the chance to find out if it was good.
What a first-run user actually needs
There are three things a new user needs from the moment they hit your app for the first time. They need orientation, a quick win, and a reason to come back.
Orientation means knowing where they are and what the app does. This sounds obvious but most dashboards fail it. A header that says "Dashboard" tells them nothing. A one-line welcome message that says "Welcome to AppName!" tells them less. Orientation is answered by something specific: "You're here to track your job applications. Start by adding one."
A quick win means doing the thing the app is for, at least once, within the first few minutes. Not watching a demo of the thing. Not reading about the thing. Actually doing it. If your app helps freelancers send invoices, the quick win is sending a test invoice. If it tracks habits, the quick win is logging a habit. If the quick win takes more than five clicks, you've already lost most of your users.
A reason to come back means they leave knowing what happens next. A task they marked as incomplete. An email they'll get tomorrow. A number they want to improve. Without this, even a good first session ends with the tab closed and the memory fading.
Get all three right and you have an app onboarding flow. Get one wrong and you have a sign-up form and a dashboard.
Empty states vs seeded states vs guided tours: when each one works
The AI default is an empty state. A centered icon, a muted grey message, a single button. "No tasks yet. Create your first task." That's not terrible, but it forces the user to immediately make a decision in a context where they have zero orientation. They don't know if they're making the right choice. So many of them don't make any choice.
Seeded states are what you use when the empty-state decision is too heavy for a first-time user. Show them a sample item. A demo project, a placeholder invoice, a fake habit already in the tracker. This removes the blank-canvas paralysis and shows them what the app looks like when it's working. The risk is that the user mistakes the demo content for real data, so label it clearly ("This is a sample project. Edit it or delete it.").
Guided tours (the kind where a tooltip follows your cursor around the screen, highlighting things one at a time) almost never work for small indie apps. They require the user to pay attention before they're committed, which is backwards. Commitment comes from doing, not from being told about doing.
The heuristic: if your app's value is obvious in the first click, go with an empty state and strong CTA copy. If the value requires context or setup, seed the data. If you're tempted to build a tooltip tour, cut one step from your signup flow instead. That's where the friction actually is.
Why "Welcome! Let's get started" modals don't work
The welcome modal is the other AI default, usually appearing right after signup. A modal with a headline ("Welcome to AppName!"), two sentences about the product, and a "Get started" button that dismisses the modal and drops the user back on the empty dashboard.
It fails for three reasons.
First: it fires before the user knows what they want help with. The welcome modal assumes the user is oriented enough to know what "get started" even means. They're not. They just signed up, probably because a tweet made them curious or a friend sent them a link.
Second: it blocks whatever they were trying to see. The moment a user clicks a link and lands in your app, they have momentum. The modal interrupts that momentum. Most users dismiss it without reading it.
Third: the modal content is almost always the same content that's already on the marketing page. Which they presumably read. Which is why they signed up.
The fix isn't a better modal. It's removing the modal and doing the orientation work in the interface instead. A persistent banner that says "Start here: add your first client" is worth ten modals. An empty state with opinionated copy ("Your dashboard gets interesting once you have one invoice. Make one now.") is worth twenty.
If you must use a modal on first load, make it do one thing: collect one piece of information that personalises the experience. "Are you a freelancer, or do you work with a team?" That response changes what they see next. That's worth a modal. "Welcome! Here's some information!" is not.
Six lines in your spec that produce a real onboarding flow
This is the part most people skip, because writing spec is boring and building is exciting. But the spec is where the AI gets told what to build. If the spec says nothing about onboarding, the AI builds nothing about onboarding.
Here are six lines you can drop into any spec. Adjust the details to fit your app.
Onboarding:
- On first login (account.created_at within last 5 minutes), show a persistent top banner:
"Welcome. Your first step is [specific action]. [Primary CTA button]."
- Seed a sample [entity] on signup. Label it "Sample (feel free to edit or delete)."
- After user completes their first real [action], dismiss the banner permanently.
- Empty state for [main list view]: icon + "You haven't [done the thing] yet." + CTA button.
- On return visits, if no [entity] created in past 7 days, show a re-engagement prompt:
"Last time you [did X]. Ready to continue?"
That's 80 words. Every tool that can read a spec (Cursor, Lovable, Claude Code, Bolt) will implement this instead of the empty dashboard. The seeded entity, the dismissal logic, the return-visit prompt. All of it.
The [specific action] and [entity] are the parts you have to fill in. Nobody can write those for you. But once you've written them, the tool does the rest.
Measuring activation without a fancy analytics stack
"Activation" (the moment a new user does the core thing your app is for, enough that they're likely to come back) is the one metric that matters for a product at under 100 users. Revenue matters too, obviously. But revenue follows activation. If people activate and stay, revenue becomes a question of pricing. If they don't activate, nothing else matters.
You don't need Mixpanel or Amplitude to measure this. You need one query.
Pick one event that represents a user "getting it." For a habit tracker: logging a habit three days in a row. For an invoice tool: sending a second invoice (the first might be a test). For a project planner: coming back at least once after the first session. Whatever it is, it should be specific and it should not be "signed up."
Then count how many of your users from the last 30 days hit that event. Divide by signups. That's your activation rate.
At under 100 users, if you're under 25%, something is wrong with your onboarding. If you're at 50%+, you're doing something right. For context on what your first 100 users actually tell you and what to do with that information, activation rate is the clearest early signal you have.
You don't need a dashboard for this. A spreadsheet and one database query works fine until you have enough users to justify the infrastructure. The goal is to know the number, so you know whether the app onboarding flow you shipped is working.
The part the AI skips is the part that matters most
This pattern shows up in almost every AI-built app that ships without a design spec: the scaffold is correct, the features are present, and the first-run experience is an afterthought. The onboarding gap isn't a technical problem. It's a spec problem. The AI built what you told it to build, and you didn't tell it about the first 90 seconds.
The fixes are not complicated. Seed one entity. Write one opinionated empty state. Replace the welcome modal with a single actionable prompt. Spec six lines of onboarding logic.
Draftlytic's guided creation flow prompts you for the "first user action" field specifically because this gap is so consistent. You describe the app, answer a few questions, and by the time you're generating a spec, the first-run experience is in it instead of missing from it.
Write the onboarding into the spec. Then the AI builds the onboarding. That's the whole move.