32 shadcn Onboarding Blocks: Welcome Screens, Setup Wizards, and Tailored First-Run Flows for Next.js

Onboarding is where the copy-paste component model usually runs out of road. A hero pastes in a minute because it is static. A first-run flow is not: it has a stepper that has to remember where the user is, selectable cards that change what happens next, form fields with validation, toggles that write real preferences, and a completion screen that has to summarize everything the user just did. So most teams skip the components and reach for a full onboarding SDK, inherit a product tour engine and its runtime, and then spend a week bending it back toward the design they actually wanted.

We think onboarding deserves the same treatment we gave landing pages and dashboards: real components you own, not a black box you rent. Today we are shipping thirty-two onboarding blocks. Welcome screens, progress trackers, setup wizards, personalization steps, configuration panels, and the completion screen that ties them together. Each installs with one command, renders a complete demo out of the box, and hands you every visible value as a typed prop.

What actually installs

Every block is a single React component, and the shadcn CLI resolves its whole dependency tree in one shot:

npx shadcn add "https://ui.beste.co/r/onboarding13?email=YOUR_EMAIL&license_key=YOUR_KEY"

That command lands three layers in your codebase:

1. The screen at components/beste/block/onboarding13.tsx. Plain TSX you own and edit.
2. The shadcn/ui primitives it composes (button, badge, card, input, switch, progress, and so on), installed only if you do not already have them.
3. Nothing else. There is no runtime dependency on us, no onboarding provider, no license check in your bundle, no state machine you have to learn.

If you are on Base UI instead of Radix, swap /r/ for /r-base/ in the URL and you get the Base UI build of the same component. For the full command and license setup, see the installation docs.

The whole arc of a first run

An onboarding flow is a sequence, so the set is organized as one. The thirty-two blocks map onto the stages a real first-run experience moves through: greet, orient, tailor, configure, and confirm. You do not install all of them. You pick one from each stage that fits your product and wire them into a route.

Stage one: the welcome

The first screen sets tone and expectation. There are four takes, from a full hero to a single line of copy.

onboarding1 is the classic guided-setup opener. If you want to sell the value before the setup, onboarding2 is a two-column layout with a feature checklist, a user count, and a star rating for social proof. onboarding3 strips it back to a branded icon, one heading, and one call to action for products that would rather not make a fuss. onboarding4 leads with a video thumbnail and a duration badge for a product tour that opens on a demo.

Stage two: showing progress

Once setup starts, users want to know how much is left. Five blocks answer that question in different visual languages.

onboarding5 is the horizontal stepper you have seen on every checkout. onboarding6 turns it vertical, with room for a description under each step, which suits a workspace setup that needs explaining. onboarding7 frames the whole thing as a percentage bar over a task checklist, the pattern that quietly gamifies completion. onboarding12 uses a circular percentage ring with completion stats for profile-strength screens, and onboarding9 presents each step as a numbered content card for a product walkthrough.

Stage three: the wizard itself

When onboarding collects data, it needs a container that holds several steps and moves between them.

onboarding8 is the multi-step form wizard: segmented progress, fields per step, and back and next controls. onboarding11 is the desktop-scale version, a side-navigation wizard with content panels for setups that span many configuration screens. onboarding10 takes the opposite stance with an accordion where each step expands to reveal its own instructions and action buttons, so users can complete tasks in any order and at their own pace. If you want to build the wizard's fields on solid footing, our forms deep dive covers the validation layer these pair with.

Tailored onboarding, not one-size-fits-all

The stages above are structure. The blocks that make onboarding feel personal are the ones that branch the experience based on who the user is and what they came to do. This is the difference between an onboarding flow and a tailored one, and it is where a good first run earns its retention.

onboarding13 asks users to pick their role or persona, which lets you send a marketer and an engineer down different paths from the very next screen. onboarding17 does the same with a primary goal, and each goal card previews the feature set it recommends, which is the cleanest way to tailor a multi-purpose platform. onboarding16 is an interest-tag picker for content platforms and newsletters that personalize their feed, and onboarding27 is a short attribution survey that captures how the user found you without derailing the flow.

The configuration screens nobody enjoys building

Every serious product needs a handful of setup screens that are pure friction to build and easy to get subtly wrong. The set covers the common ones so you do not rebuild them per project.

onboarding14 creates a workspace with a name and URL slug and pairs it with a team-invite section, the standard opening move for collaborative SaaS. onboarding19 is the profile step: avatar, display name, bio, and timezone. onboarding29 collects company name, team size, and industry for B2B context. onboarding18 is notification consent done with real toggles, onboarding23 is a security step for two-factor, recovery email, and backup codes, and onboarding25 lets users choose a theme and accent color before they ever see the app. For products that start from existing data, onboarding26 offers import options and CSV upload, onboarding20 is a starter-template picker, and onboarding22 and onboarding28 handle plan limits and billing setup when payment is part of the flow.

Two more round out the experience: onboarding24 is a keyboard-shortcuts cheat sheet for power tools, and onboarding30 is a feature-tour carousel with dot indicators for the first-time walkthrough.

Stage five: the finish line

onboarding21 closes the loop. It recaps what the user set up and hands them clear next actions, which is the difference between a flow that dumps users at an empty dashboard and one that points them at their first real task.

Editorial getting-started sections too

Not every onboarding lives behind a login. Two blocks are marketing-page "how it works" sections rather than app screens, for landing pages that need to explain the first three steps before signup.

onboarding32 is its counterpart, a reversed split that floats a live import dropzone over an image tile next to three numbered steps. Both are content sections you drop between a hero and a pricing table, not screens in a wizard.

Every value on the screen is a prop

The rule we held the whole set to is the same one behind the dashboard set: if you can read it, you can pass it.

Each block renders its full demo with zero props, so <Onboarding13 /> looks exactly like the preview above. Every prop is optional and falls back to the demo value, which means you replace demo copy with real content one field at a time instead of filling a config object before anything appears:

import { Onboarding13, onboarding13Demo } from "@/components/beste/block/onboarding13";

export default function ChooseRolePage() {
  return (
    <Onboarding13
      heading="What brings you to Ledgerline?"
      description="We'll tailor your setup to how you work."
      roles={[
        { id: "founder", title: "Founder", description: "Run the whole business" },
        { id: "finance", title: "Finance", description: "Own the books and reporting" },
        { id: "ops", title: "Operations", description: "Keep the team moving" },
      ]}
      primaryButton={{ label: "Continue", href: "/onboarding/workspace" }}
      currentStep={2}
      totalSteps={5}
    />
  );
}

Every block exports its demo object too (onboarding13Demo here), which doubles as documentation: the exact shape your data needs, in a file you can open. Because the demo is the default, the state machine stays yours to keep simple. Hold the current step in a useState, render one block per step, and advance through each block's own controls. There is no flow engine to configure and nothing proprietary to serialize.

The details you would have had to get right yourself

• Server rendering is safe. No Date.now() or Math.random() in render paths, so the screens hydrate without mismatch warnings.
• Mobile holds up. Steppers reflow, side-nav wizards collapse, and grids stack, because onboarding on a phone is not the edge case.
• Keyboards and labels work. Toggles, selects, and inputs are the accessible shadcn primitives underneath, and icon-only controls carry aria-labels.
• Theming is token-based. Everything reads from your CSS variables, so the blocks adopt your brand and your dark mode the moment they land. If you are still shaping those tokens, the anatomy of a shadcn theme walks through the variables these depend on.
• The code is yours. It is TSX in your repo, structured the way you would have written it, with no wrapper package to fork when a real requirement arrives.

The full set

Every block links to a live, full-screen preview on its page. Browse them all under the onboarding category.

Four of them, including the welcome hero and the minimal intro, are free to install and try before you commit. The rest are part of Beste UI Pro.

Where these get discovered

We publish the whole catalog as a structured, machine-readable feed so search engines and AI assistants can index it directly, which is how a query like "shadcn onboarding blocks" can surface the right category instead of a wall of screenshots. That is the idea behind engines like shoogle.dev, which discover and rank sites through structured signals rather than crawling rendered pages. If you want your own component library to be found the same way, our MCP server exposes the catalog to assistants over the same kind of structured data.

Wire your first flow this week

A practical route: pick a welcome (onboarding1 or onboarding3), a tailoring step (onboarding13 or onboarding17), one or two configuration screens your product actually needs, and the completion screen (onboarding21). Hold the step index in state, render one block per step, and store each result on the account as it comes in. Because every block ships complete, your flow looks finished from the first commit, and you refine copy and data field by field instead of staring at a broken screen in review.