
The $3.6B onboarding tax: how SaaS tools extract developer value
SAP paid $1.5 billion for WalkMe in June 2024. Not for the code. Not for the team. For access to the enterprises already locked into WalkMe's proprietary adoption scripts (TechCrunch).
That acquisition wasn't an anomaly. It was a price tag on a business model: sell onboarding to product managers, then bill engineering teams for the integration work that never ends.
As of April 2026, the combined digital adoption platform and onboarding software market sits around $3.6 billion annually. The DAP segment alone is valued between $1.59 billion and $3 billion depending on which research firm you ask (Fortune Business Insights, Market Research Future). Add the standalone onboarding software segment at roughly $550 million (Valuates Reports), plus the PLG tooling layer that wraps around both, and the total crosses $3.6 billion with room to spare.
That's $3.6 billion flowing from engineering budgets into vendor pockets. And the developers doing the integration work don't get a say in the purchase.
npm install @tourkit/core @tourkit/reactWho pays the onboarding tax
The onboarding SaaS tax isn't a subscription fee. It's the engineering hours, performance budget erosion, and recurring migration sprints that accumulate invisibly in every team that integrates a third-party onboarding tool. Product managers sign the contract, but developers absorb the cost over months and years of maintenance work that nobody tracks against the tool's ROI.
Here's how the money actually moves. A product manager evaluates Pendo, Appcues, or Userpilot. They see a demo. The vendor's sales team quotes a price: $300/month for Appcues Start, $299/month for Userpilot's entry tier, or $48,000/year average for Pendo (Chameleon 2026 comparison). The PM signs the contract.
Then the ticket hits engineering.
The developer installs a script tag, wires up event listeners, maps user properties, configures tour triggers, and debugs CSS conflicts with the existing design system. That "30-minute setup" the vendor promised in the demo turns into two weeks of integration work. And it recurs every quarter when the vendor pushes an update, every six months when you upgrade React, and every year when someone on the product team decides to switch from Pendo to Userpilot because the pricing changed.
Pendo pulled in $200 million in revenue in 2024 and secured a $100 million credit facility in September 2025 (CB Insights). That revenue comes from somewhere. It comes from the engineering hours your team spends maintaining an integration that could have been 200 lines of owned code.
Where $3.6 billion actually goes
As of April 2026, the onboarding market splits into three segments: digital adoption platforms ($1.6B-$3B), standalone onboarding software ($550M), and the PLG tooling layer ($500M+). None of these segments prioritize developer experience, because in every case the buyer is a product manager while the maintainer is an engineer.
| Market segment | 2026 estimated size | Key players | What developers get |
|---|---|---|---|
| Digital adoption platforms | $1.6B-$3B | WalkMe (SAP), Whatfix, Apty | Proprietary scripts, vendor CSS, zero tree-shaking |
| Onboarding software | ~$550M | Appcues, Userpilot, Chameleon | No-code builders that generate code developers can't modify |
| PLG tooling layer | ~$500M+ | Pendo, Amplitude, Mixpanel (onboarding features) | Analytics SDKs at 30-60KB each, limited export |
Every segment shares the same structural problem: the buyer isn't the user. Product managers buy onboarding tools. Developers maintain them. The vendor's incentive is to make the PM's life easier during the sale, not the developer's life easier during the next two years of integration maintenance.
This misalignment is why 65% of total software costs happen after the original deployment, according to multiple TCO analyses. Your subscription fee? Smallest part of the bill. Real cost lives in engineering hours that nobody tracks against the tool's ROI.
And the performance cost compounds silently. SpeedCurve's research shows pages with third-party scripts enabled can hit Largest Contentful Paint times of 26.82 seconds, compared to under 1 second without them (SpeedCurve). Twenty external scripts is the average. Stack an onboarding tool, an analytics tracker, and an NPS survey widget together, and they'll consume half of a 300KB JavaScript budget before your application renders a single component.
The counterargument: onboarding tools save engineering time
The $3.6 billion market exists because onboarding tools solve a genuine problem: product managers need to ship activation flows without filing engineering tickets, and building from scratch is expensive. Userpilot estimates $3.5 million for an enterprise-grade system (Userpilot). Even a startup version costs $60,000 for a designer and developer working two months. Most teams shouldn't build their own onboarding from zero.
Product managers genuinely need to ship onboarding flows without waiting for engineering sprints. No-code builders exist because the feedback loop between "we need a tooltip here" and "a developer will get to it in two weeks" is too slow for companies iterating on activation metrics.
And the data these platforms collect is real. Pendo's analytics, Appcues' flow completion rates, Userpilot's funnel tracking all provide signal that'd take months to build from scratch. PLG companies using self-serve onboarding reached value 18.3% faster and reduced customer acquisition costs by 30-50% compared to non-PLG peers (Mixpanel).
Nobody's arguing that onboarding tools don't create value. They do.
But does $3.6 billion of value need to flow through vendor lock-in and proprietary scripts? Or could most of it be delivered through open, composable libraries that developers actually control?
What this means for engineering teams
The onboarding tool market is heading toward the same unbundling that hit content management systems in the 2010s, when headless CMS tools let developers reclaim their architecture without removing content teams from the workflow. WordPress and Drupal dominated because they gave non-developers control. Then Contentful and Sanity appeared, and developers got their architecture back.
Onboarding is ripe for that same shift. Product teams still need to ship activation flows without a full sprint cycle. But the delivery mechanism doesn't have to be a 45KB proprietary script injected into your bundle.
Here's what engineering teams can actually do:
Audit the real cost. Track how many engineering hours your team spends on onboarding tool integration, maintenance, CSS overrides, and migration over a quarter. Compare that to the subscription price. The ratio will surprise you. (We cover the calculation method in our developer tax breakdown.)
Separate the concerns. Onboarding logic (step sequencing, progress tracking, conditional display) is a solved problem in 200-400 lines of TypeScript. Analytics integration? Also solved. Your design system already handles UI rendering. Vendor tools really only add a visual builder for non-developers, and even that is increasingly replaceable by AI-assisted code generation.
Own the core, rent the periphery. Use open-source libraries for tour logic and rendering. Use your existing analytics stack (PostHog, Amplitude, Mixpanel) for tracking. Give product managers a config-driven approach instead of a no-code builder. The total integration cost drops to hours, not weeks.
// src/components/OnboardingTour.tsx
import { TourProvider, Tour, Step } from '@tourkit/react';
// 200 lines of code you own vs. 45KB of vendor script you don't
function OnboardingTour() {
return (
<TourProvider>
<Tour tourId="activation-flow">
<Step target="#create-project" title="Create your first project">
Click here to get started with your workspace.
</Step>
<Step target="#invite-team" title="Invite your team">
Collaboration works better with teammates.
</Step>
</Tour>
</TourProvider>
);
}Full disclosure: we built User Tour Kit as an open-source alternative to proprietary onboarding tools. So yes, we have a stake in this argument. Every claim in this article is verifiable against the sources linked, and the market data comes from independent research firms, not our benchmarks.
Tour Kit doesn't have a visual builder. It requires React developers. It won't replace Pendo for a product team with zero engineering support. That's a real limitation, and it means the $3.6 billion market isn't going to zero anytime soon.
But for engineering teams already frustrated with vendor CSS conflicts, bundle bloat, and annual migration sprints, the math is changing. The onboarding tax is a choice, not a cost of doing business.
What we'd do differently if starting a SaaS today
Starting a new SaaS in April 2026, we'd split onboarding into three buckets: own the UI layer, rent the analytics layer, and skip anything that injects uncontrollable JavaScript into your bundle. Here's the specific breakdown.
Own: Tour logic, step rendering, progress tracking, survey display. These are UI components. Your design system should render them, not a vendor's iframe.
Rent: User analytics and behavioral cohort analysis. Tools like PostHog and Amplitude are genuinely difficult to replicate, and their value scales with data volume in ways that DIY solutions can't match.
Skip entirely: Any tool that injects JavaScript you can't tree-shake, ships CSS you can't override without !important, or stores your onboarding configuration on their servers instead of in your codebase.
The $3.6 billion onboarding market exists because vendors convinced product managers that onboarding is too hard to own. For most React teams with a component library and a state management pattern, it's 200 lines of TypeScript and a few hours of configuration.
The question every engineering lead should ask: is your team paying the onboarding tax because the tool creates irreplaceable value, or because nobody's done the math on what it actually costs?
npm install @tourkit/core @tourkit/reactGet started with User Tour Kit | GitHub
FAQ
How big is the onboarding SaaS market in 2026?
Approximately $3.6 billion in 2026. The DAP segment alone sits between $1.59 billion (Fortune Business Insights) and $3 billion (Market Research Future), with standalone onboarding software adding roughly $550 million. SAP paid $1.5 billion just for WalkMe in 2024.
What does the onboarding SaaS tax cost developers?
The onboarding SaaS tax includes engineering hours spent on integration, maintenance, CSS conflict resolution, and vendor migrations. These costs don't appear on the subscription invoice but typically exceed the license fee within the first year. One analysis found that 65% of total software costs occur after initial deployment, and integration complexity adds 20-30% to total project cost.
Can open-source tools replace paid onboarding platforms?
Open-source onboarding libraries like User Tour Kit replace the UI rendering and tour logic layers of paid platforms. They don't replace no-code visual builders or built-in analytics dashboards. For teams with React developers and an existing analytics stack, open-source tools eliminate vendor dependency and bundle bloat. Teams without engineering resources still benefit from commercial platforms.
Why do product managers choose vendor onboarding tools over code?
Product managers choose vendor tools because they provide immediate time-to-value without engineering sprints. No-code builders let PMs iterate on activation flows daily rather than weekly. The tradeoff is that developers absorb the long-term integration cost, performance impact, and migration burden that vendor tools create.
What's the difference between this article and "The developer tax"?
This article examines the $3.6 billion onboarding market from a market-sizing perspective, arguing that the industry structure extracts disproportionate value from engineering teams. Our related article on the developer tax focuses on calculating the practical engineering cost of SaaS tools at the team level, with formulas for measuring your own developer tax.
Related articles

How AI will change product onboarding (and what won't change)
AI will personalize onboarding timing, content, and sequencing. But trust, accessibility, and user control still require human decisions. A developer's take.
Read article
Why the best onboarding software in 2026 is a React library
Code-first React libraries beat SaaS onboarding platforms on cost, performance, and control. Pricing data, bundle sizes, and architecture compared.
Read article
GitHub stars don't pay the bills (but they help)
A solo developer's honest look at what GitHub stars actually do for an open-source library. Real numbers on the gap between stars and revenue.
Read article
From 0 to 1000 GitHub stars: the Tour Kit playbook
How I grew a React product tour library from zero to its first 1,000 GitHub stars as a solo developer. Real tactics, real numbers, no paid ads.
Read article