Onboarding is a product, not an afterthought
Onboarding is the first time a user sees whether your product is coherent. Most teams build it last.
I built the onboarding flow last. By the time I finished it, I had rewritten two other features and renamed half the concepts in the product.
The decision to build onboarding last feels logical when you're in it. You need the core product first. You need to know what you're onboarding people into. What you discover, if you wait, is that building onboarding forces you to explain the product from the outside. And the outside view reveals things the inside view hid.
What you're really doing when you build onboarding
Onboarding is the moment the product has to speak for itself. No context, no prior understanding, no second chance. Building it forces you to ask: can this product be explained in three steps? Is the first thing a user does actually the most valuable thing they can do? Does the language I use inside the product match what a new user would expect?
For Unsaid, building the onboarding wizard meant walking through the product as if I'd never seen it. The first step was obvious. The second relied on a concept, 'an insight cluster', which made sense to me after months of building and made no sense to anyone who hadn't. I renamed it. Then I found three other places in the product using the same wrong term.
The preview generation moment
The highest-value part of Unsaid's onboarding is a preview: before a user commits to their first journal entry, they see an example of what the AI analysis looks like. It's generated from a synthetic journal. The user gets to see what they're signing up for before they give anything.
Building that preview required me to make the AI pipeline work on synthetic data. That exposed a bug I hadn't found: the pipeline assumed a minimum of three entries before producing output. One entry, and it failed silently. I wouldn't have found that bug without the preview flow. The preview was onboarding work. The bug was a core product bug.
What onboarding reveals about your data model
Onboarding forces you to think about what state a new user is in. No entries. No history. No patterns detected. Most of the product assumes data exists. Building onboarding means explicitly handling the case where none of it does yet, and finding that you hadn't.
Two of the empty states in Unsaid were missing entirely. The analysis view with no entries showed a spinner that never resolved. The insights page showed a layout that only made sense with data in it. These weren't onboarding bugs. They were product bugs that onboarding exposed.
Onboarding is the first test of whether your product makes sense to someone who doesn't already understand it.
The rule I use now
The rule I'd use now: design onboarding before you design the main product, even roughly. Not because you'll get it right. You won't. But because the act of designing it forces questions about structure, language, and empty states that are much cheaper to answer at the start than after the core product is built.
If you build onboarding last, you'll finish it. You'll also spend a week fixing the things it found that you thought were already done.