Build vs buy user onboarding: run the break-even math

For most web SaaS teams, buying user onboarding wins, and it is not close. The build-vs-buy math only tips toward building when the tool you priced against costs several hundred dollars a month.

"Build" is doing a lot of work in that question. When a team says it will build onboarding, it means the first tour. That is about a week of work. The cost is the ten months after it.

So price the ten months, not the week.

What are you actually building?

Version one is small. A step list, a highlight ring, a next button. Any competent front-end engineer ships that in an afternoon.

Then the requests arrive, and they are all reasonable.

• Only show it to users who signed up after Tuesday.
• Do not show it again once someone finishes it, or dismisses it, on any device.
• Let them resume it tomorrow from step three.
• Tell us how many people finished, and where the rest stopped.
• Change step four's copy without a deploy.

Now you are not building a tour. You are building a small content management system with a rules engine, a state store and an analytics pipeline. The targeting rules alone usually outgrow the tour code that started it.

And there is a tour_v1_seen boolean in your users table that nobody will ever be brave enough to drop.

The cost that repeats is not the build

In-house onboarding has one recurring bill: engineering attention.

Your tour points at real elements in a real interface. Every redesign, class rename or component swap can break a step, and the break is silent. Nobody gets an alert. A user just sees a highlight ring around nothing. We wrote up why selectors break on deploy because it is the single most common way homegrown tours die.

Then there is the copy. In a bought tool, the person who writes the words also ships them. In a built one, a comma fix is a pull request, a review, a deploy and a QA pass.

That friction has a predictable end state. The PM stops asking. The onboarding stops changing. It sits there describing a version of the product that shipped fourteen months ago.

Most in-house onboarding does not get deleted. It gets frozen.

Where does the break-even actually sit?

Every vendor publishes a version of this math, and the numbers are worth reading even though the conclusion is never a surprise.

Appcues cites an analysis putting the point where building becomes financially competitive at roughly $60,000 a year of platform spend. Whatfix's build-vs-buy post puts onboarding tools for smaller teams at $200 to $1,000 a month, which is $2,400 to $12,000 a year. Hopscotch estimates 5 to 20 hours a month of ongoing maintenance on a build.

Put those together and the shape of it is clear. On the buy side, the highest number in the SMB range is still a fifth of the break-even. On the build side, the maintenance never stops.

Here is a worked example with round numbers. It is not a benchmark. Take 12 hours a month as a conservative working assumption. Assume an engineer costs your company $80 an hour fully loaded. That is $960 a month, or $11,520 a year, before you count the first build at all. Onbixo Growth is $79 a month, so the maintenance alone costs more than 12 times the software subscription.

Now compare it with a real invoice. Onbixo is $39 a month on Starter and $79 a month on Growth, flat, with a monthly active user cap on each plan. Free covers 1,000 monthly active users. Growth for a year is $948, and the invoice does not move because you had a good month.

At those numbers, the maintenance cost alone is already $881 more per month than the Growth subscription. The build starts behind and gets more expensive every month it has to be maintained.

That is the part the category math misses. The break-even is not a property of onboarding tooling. It is a function of the price you agreed to pay.

When is building the right call?

There are three cases, and they are real.

Onboarding is the product. If you sell a teaching tool, a course platform or an editor whose whole pitch is the tutorial, the walkthrough is your core loop. Nobody outsources their core loop.

It has to live in a native binary. Onbixo runs in web apps: React, Vue, Angular, Svelte or plain HTML, shipped with one snippet. Onboarding that has to sit inside an iOS or Android build is a different job.

You cannot load third-party code. Some regulated or air-gapped deployments settle this before anyone opens a spreadsheet.

Outside those three, I have not seen an in-house build pay for itself. I have seen plenty get frozen.

What is still unsettled

Every break-even model in this category is published by someone who sells a tool. That includes this one.

The inputs are estimates. Engineer cost, maintenance hours, how often your interface changes. Move the maintenance figure from 12 hours to 4 and the picture shifts by a year. Nobody has a clean dataset here, and anyone quoting one to two decimal places is guessing with confidence.

There is also a tension the spreadsheet cannot settle. A bought tool means your onboarding lives outside your codebase, and some engineering teams hate that on principle. That is a real preference, not a bad one. It is just rarely worth what it costs.

Run the math against your own price

Do this before you scope anything.

Open your last two quarters of deploys. Count the ones that touched a screen your onboarding would point at. That number is your maintenance load, and it is usually higher than anyone guessed in the meeting.

Then price the tool you would actually buy, not the category average. The whole argument turns on that one figure.

You can start on Onbixo free and have a flow live this afternoon, with no demo call in the way. If the build still looks better after that, you will at least have priced the right thing.