The unbundling of onboarding: why all-in-one is over

Every SaaS category eventually unbundles. CRM did it. Analytics did it. The marketing stack did it a decade ago. And now, in 2026, onboarding tools are next.

The pattern is predictable. A category starts with a few all-in-one platforms that promise to handle everything. Teams adopt them because buying one tool feels simpler than assembling five. Then the costs compound, the bloat accumulates, and engineers start asking why they're paying $140K a year for a product tour widget they could own in 200 lines of React.

That question is getting louder. $285 billion in SaaS market cap evaporated in early 2026, and the pressure isn't theoretical anymore. According to SaaStr's Jason Lemkin, SaaS is moving through three stages of unbundling: seat compression (happening now), feature extraction (2026-2027), and workspace consolidation (2027 onward). Onboarding platforms sit squarely in the feature extraction phase, where teams pull out the pieces they actually use and replace the rest with code they control.

npm install @tourkit/core @tourkit/react

Tour Kit is a composable onboarding library built on this thesis. We're biased (we built it) so take everything here with appropriate skepticism. But the trend data is independent of any single product, and it points in one direction.

What does "unbundling onboarding" actually mean?

Unbundling onboarding means replacing a single all-in-one platform (Pendo, WalkMe, Appcues) with a modular stack of purpose-built tools that each handle one concern well. Instead of buying a platform that ships product tours, checklists, surveys, announcements, and analytics in one monolithic bundle, teams assemble their own stack from independent libraries and services. They choose the best option for each layer rather than accepting whatever the platform provides.

This mirrors what happened in frontend development broadly. Nobody installs a monolithic UI framework anymore. You pick a router (TanStack Router), a state manager (Zustand), a form library (React Hook Form), and a component system (shadcn/ui). Each tool is small, composable, and replaceable. The "all-in-one React framework" category barely exists. Onboarding is following the same trajectory, just five years behind.

The difference between a bundled and unbundled onboarding stack looks something like this:

Why all-in-one onboarding platforms are losing ground

All-in-one onboarding platforms are losing market share because the trade-offs that justified them in 2018 (speed over control, one vendor over many) no longer hold in 2026. Performance costs are measurable, vendor lock-in is expensive to escape, and most teams already own 60-70% of the stack they need. Three forces are pulling the model apart.

Force 1: the performance tax is measurable now

As of April 2026, WalkMe's injected script adds 180-350KB to your page weight depending on which modules load. Pendo's agent script runs between 150-250KB. Google's Core Web Vitals update in late 2025 made these numbers directly visible in search rankings, and engineering teams are noticing.

A composable approach changes the math entirely. Tour Kit's core package ships at under 8KB gzipped with zero runtime dependencies. You install only the packages you need (tours, hints, checklists, surveys) and tree-shaking removes the rest. Loading a 300KB platform script versus an 8KB library isn't a marginal difference. On mobile connections, it's the gap between a sub-100ms Interaction to Next Paint and a visible delay.

Force 2: vendor lock-in has a real exit cost

Proprietary onboarding platforms use custom terminology, custom SDKs, and custom data formats. When you build 50 tours in Appcues, your tour configurations live in Appcues. Your analytics data lives in their dashboard. Your targeting rules use their proprietary segment builder.

Leaving means rebuilding everything from scratch. We've talked to teams who estimated their Pendo migration at 3-6 months of engineering time, not because the new tool was complex, but because extracting tour configurations, rewriting targeting logic, and reconnecting analytics took that long. Multi-year contracts with hidden auto-renewal clauses make the situation worse. The switching cost isn't just technical. It's contractual.

A composable stack sidesteps this by using tools you already own. Analytics go to PostHog or Mixpanel, which you're already paying for. Targeting runs through LaunchDarkly or Statsig, which your feature flag system already handles. Tour configurations live in your codebase, version-controlled and portable.

Force 3: teams already have most of the stack

Here's the part all-in-one platforms don't advertise: most engineering teams already run 60-70% of an onboarding stack without realizing it.

Analytics? PostHog, Amplitude, or Mixpanel. Feature flags? LaunchDarkly, Statsig, or an open-source alternative. Component library? shadcn/ui, Radix, or your own design system. State management? Zustand, Jotai, Redux. The only piece missing is the onboarding-specific logic: tour sequencing, step positioning, highlight rendering, checklist progress tracking.

A composable onboarding library fills that gap. Not another analytics dashboard. Not another targeting engine. Just the onboarding primitives that plug into tools you already run.

The composable architecture pattern

Composable architecture, where systems are assembled from independent, interchangeable modules rather than deployed as monoliths, has moved from theory to mainstream adoption. Deloitte's 2025 technology trends report found that 46% of IT teams have already implemented it, with those teams reporting 37% shorter time-to-market and 30% higher ROI. The modular software market has grown past $39 billion.

In React, composable onboarding looks like this:

// src/providers/onboarding-provider.tsx
import { TourProvider } from '@tourkit/react'
import { ChecklistProvider } from '@tourkit/checklists'
import { AnalyticsProvider } from '@tourkit/analytics'
import { PostHogPlugin } from '@tourkit/analytics/posthog'

export function OnboardingProvider({ children }: { children: React.ReactNode }) {
  return (
    <AnalyticsProvider plugins={[PostHogPlugin()]}>
      <TourProvider>
        <ChecklistProvider>
          {children}
        </ChecklistProvider>
      </TourProvider>
    </AnalyticsProvider>
  )
}

// src/tours/dashboard-tour.tsx
import { useTour } from '@tourkit/react'

const steps = [
  { target: '#sidebar-nav', content: 'Your main navigation lives here.' },
  { target: '#search-bar', content: 'Search across all your projects.' },
  { target: '#create-button', content: 'Create your first project to get started.' },
]

export function DashboardTour() {
  const { start, isActive } = useTour({ id: 'dashboard-intro', steps })

  if (isActive) return null
  return <button onClick={start}>Take the tour</button>
}

Each package handles one concern. None of them require the others to function, and replacing any single piece doesn't break the rest. Compare that to a typical all-in-one integration:

<!-- Injected by Pendo/WalkMe/Appcues -->
<script src="https://platform.example.com/agent.js?key=YOUR_KEY"></script>

One script, loaded on every page, running all modules whether you use them or not. Tours, analytics, targeting, surveys, all coupled to a single vendor's runtime.

The counterargument: when all-in-one still makes sense

Composable onboarding isn't universally better than all-in-one platforms. The right choice depends on team size, technical capacity, and how much engineering time you can allocate to owning your onboarding stack. Some teams should absolutely stay on a platform.

If you're a 5-person startup shipping your MVP, spending engineering time assembling an onboarding stack is probably wrong. A no-code platform like Appcues or Userflow gets you tours in an afternoon with zero developer involvement. That's a legitimate advantage.

If your product team doesn't have React developers and needs to create tours independently, a visual builder matters. Tour Kit doesn't have one. Neither do most composable alternatives. You need engineers in the loop, and not every organization has that capacity.

And if you're already locked into a platform that works acceptably well, the migration cost might not justify the switch. "Good enough" is a valid engineering decision when the opportunity cost of rebuilding is high.

The unbundling trend doesn't mean all-in-one platforms disappear overnight. It means the default choice is shifting. Five years ago, the question was "which platform should we buy?" Now it's "do we need a platform at all, or can we compose this from tools we already have?"

What a modern onboarding stack looks like

A practical composable onboarding stack in 2026 uses six layers, each handled by a purpose-built tool that you can swap independently. Most teams already own four of these six layers through existing analytics, feature flags, component libraries, and databases. Here's the full picture:

The integration glue is minimal. Tour Kit fires events, your analytics plugin forwards them to PostHog, your feature flag service controls which tours show, and your database stores completion state.

We tested this stack on a B2B dashboard with 50+ interactive elements. Setup took about 4 hours, roughly the same as configuring Pendo for the same flows. The difference showed up at month 3: when the product team wanted to change analytics providers from Mixpanel to PostHog, they swapped one plugin. In an all-in-one platform, that's a migration project.

What this means for engineering teams

The unbundling of onboarding is already happening, not a prediction for next year. Gartner projected 60% of organizations would list "composability" as a strategic goal by 2026, and the composable commerce movement proved the pattern works at enterprise scale. Frontend development unbundled years ago. Onboarding is catching up.

For engineering teams evaluating onboarding tools today, three questions matter:

Do you own the code? If your tour configurations live in a vendor's cloud, you're renting your onboarding experience. If they live in your repo, you own it.

Can you replace one piece without replacing everything? If swapping your analytics provider means rebuilding your tours, your stack is coupled. If it means changing one import, it's composable.

What's the exit cost? If leaving your current tool requires 3-6 months of migration work, the tool owns you more than you own it.

The teams asking these questions are the ones unbundling. And the data suggests there will be more of them, not fewer.

Get started with a composable onboarding stack: Tour Kit documentation | GitHub

npm install @tourkit/core @tourkit/react

FAQ

What does unbundling onboarding tools mean?

Unbundling onboarding tools means replacing a single all-in-one platform like Pendo or WalkMe with a modular stack of purpose-built tools. Instead of one vendor handling tours, analytics, surveys, and targeting, teams pick the best tool for each layer, using existing analytics, feature flags, and component libraries alongside a focused library like Tour Kit.

Is a composable onboarding stack harder to set up than an all-in-one platform?

Initial setup takes roughly the same time, about 2-4 hours for a typical onboarding flow. The difference appears over time. Composable stacks are easier to modify because changing one piece doesn't require touching the rest. All-in-one platforms are faster for the first tour but slower for the 50th change.

How much can teams save by unbundling onboarding tools?

All-in-one onboarding platforms cost between $15,000 and $140,000 per year at 10,000 MAU. A composable stack built on Tour Kit (free MIT core, $99 one-time Pro) plus existing analytics and feature flag tools reduces onboarding tooling costs by 90% or more. Savings compound as MAU grows because composable tools don't charge per user.

Who should stick with an all-in-one onboarding platform?

Teams without React developers, early-stage startups that need no-code tour builders, and organizations already locked into a platform that works well enough. The migration cost from an all-in-one platform to a composable stack can take 3-6 months, so the switch only makes sense when the long-term benefits outweigh the transition effort.

What are the risks of a composable onboarding approach?

The main risk is integration responsibility. With an all-in-one platform, the vendor ensures all pieces work together. With a composable stack, your team owns that integration. Tour Kit mitigates this with pre-built analytics plugins and framework adapters, but you still need React developers who can maintain the setup. Tour Kit is also a younger project with a smaller community than established platforms like Pendo or WalkMe.

Related articles

Thought LeadershipApr 11, 2026 · 11 min read

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

Thought LeadershipApr 11, 2026 · 8 min read

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

Thought LeadershipApr 11, 2026 · 7 min read

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

Thought LeadershipApr 11, 2026 · 10 min read

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