Onboarding without per-user pricing
Onboarding tools are priced by how many people use your product. You pay per thousand monthly active users, and the bill grows with your success rather than with your usage of the tool.
That pricing follows from what those tools do. They render inside your application, so they can count the people who see them, and what can be counted gets billed. It is a coherent model. It is also the reason a growing product pays more each quarter for a set of steps that has not changed since spring.
There is a second way to build the same thing, and the trade is honest enough to state in one sentence: you write the interface, and nobody counts your users.
What an onboarding tool actually gives you
Three things, and they are worth separating because only one of them is hard.
A visual editor for building steps without code.
A runtime that shows the steps in your product: the overlay, the highlight, the tooltip, the checklist.
Targeting and state: who sees which step, in what order, what counts as done, what happens when they skip it.
The first two are presentation. The third is the one that keeps you up at night, and here is the part that gets skipped in every comparison: the tool does not do it for you. You still decide that a user who has connected a data source but never published sees step four and not step two. Nobody can decide that for you, because it depends on your product.
So you are buying an editor and a runtime, and paying per user for them.
What changes when AI writes your frontend
Building a simple onboarding overlay used to justify buying a dedicated tool. With modern coding assistants, that trade-off has changed, and the result lives in your own components, matches your own design system, and loads no third-party script.
That shifts the calculation. If the runtime is cheap to build and the targeting was always yours, what remains is the content: the words of each step, kept somewhere a person can edit them without a release.
The setup that follows
Each onboarding step gets an address. Your application asks for the step it needs, by name, and renders it in your own interface.
- The sequence lives in your product, where your data is.
- The words live in one place, editable by whoever owns them, published without a deploy.
- The same explanation can also serve the tooltip and the help panel, so your onboarding stops contradicting the rest of your product. That is the larger prize, and it is the subject of one explanation, six copies.
What you give up is the visual editor. If nobody on your team writes code, that matters and you should buy the tool. If your product already has a frontend team, you are buying a screen builder for a screen you can build.
What it costs
A flat subscription for the seat that edits the content, and delivery that is not metered. A thousand new users and a hundred thousand cost the same, because nothing on our side counts them.
That is the structural difference, and it is the whole argument. Not that this is easier than an onboarding platform, because it is not. That your onboarding stops getting more expensive for the reason you wanted in the first place.
Where to start
Write down your onboarding as a list of steps with the exact words each one shows. Give every line an address and publish it.
Then build one step in your own interface that fetches its text by that address. If your team can do that in an afternoon, you have the answer about the other nine.