Onboarding is a developer problem, not a product manager problem

Every no-code onboarding vendor pitches the same story: "Ship product tours in under an hour, no developers needed." It sounds great in a demo. Then three months later your Lighthouse score drops 15 points, screen readers can't navigate the tooltip overlay, and the PM who configured the tour has moved on to a different initiative. The developer gets the 2am page.

Onboarding isn't a configuration problem. It's a code problem. And code problems belong to developers.

npm install @tourkit/core @tourkit/react

Try a code-first approach with User Tour Kit and see how onboarding feels when you own the stack.

The argument: an accountability vacuum that nobody owns

No-code onboarding tools create a structural gap between who ships changes and who owns the consequences. PMs configure tours in a visual builder. Those tours inject third-party scripts into production. When the script causes a performance regression or breaks after a deploy, the PM doesn't get paged. The developer does.

ProductPlan put it plainly: "Product management may not feel the same level of ownership or accountability [for onboarding] as they do for other features" (ProductPlan). That's not a criticism of PMs. It's an observation about incentive structures.

PMs measure activation. Developers measure uptime, load times, and correctness. When those goals conflict, and they do every time a 200KB onboarding script lands on your marketing page, the developer's concerns lose. They're invisible until something breaks.

This isn't hypothetical. The pattern repeats at every growing SaaS company. You start with one welcome tour. A PM wants role-based onboarding. Customer success wants a checklist. Growth wants experiments. Leadership wants adoption metrics. As Chameleon's own analysis admits: "The library is rarely what breaks first, the operating model breaks first" (Chameleon).

The performance tax developers inherit

Third-party onboarding scripts carry real weight. As of April 2026, the average page already loads 20+ external scripts totaling roughly 449KB of third-party JavaScript (HTTP Archive via Crystallize). Each additional analytics, marketing, or onboarding tool adds 50KB to 500KB on top of that.

Google's own data shows that increasing page load from 1 second to 3 seconds drives a 32% bounce rate increase. And 79% of users who experience poor site performance won't come back (Crystallize).

No-code onboarding tools inject scripts at runtime. They bypass tree-shaking. They bypass your bundle analysis pipeline. They bypass your performance budgets. The PM who added the tour never sees the cost. The developer who reviews the Lighthouse report does.

Compare that to a code-first library. Tour Kit's core package ships at under 8KB gzipped. It tree-shakes. It's part of your build graph, your CI checks, your performance budgets. When the bundle grows, you know exactly why and can act on it.

Accessibility compliance is structurally a developer problem

Here's the argument that should end the debate for any team that cares about compliance. WCAG 2.1 Success Criterion 4.1.2 states: "This success criterion is primarily for web authors who develop or script their own user interface components" (W3C, WCAG 2.1).

Product tours are custom UI components. They create overlays, trap focus, auto-advance content, and intercept keyboard navigation. Every one of those behaviors has specific WCAG requirements:

• SC 2.1.1 (Keyboard): All tour navigation must be operable via keyboard alone
• SC 2.2.2 (Pause, Stop, Hide): Auto-advancing tours must provide a pause mechanism
• SC 4.1.2 (Name, Role, Value): Every interactive element needs proper ARIA attributes

No-code tools rarely expose these controls to the PM configuring the tour. Focus management? ARIA live regions? Keyboard trap prevention? These aren't checkboxes in a visual builder. They're implementation details that require a developer who understands the DOM.

The accessibility community has been clear about this. Section 508 guidance recommends teams "build accessibility into your project workflow rather than retrofitting it at the end" and treat it as "an acceptance criteria or definition of done for each story" (accessibility.build). Retrofitting accessibility into a no-code tool's output isn't compliance. It's a legal liability with extra steps.

The "build vs. buy" framing is outdated

The standard build vs. buy argument goes like this: building onboarding in-house costs $50,000–$150,000 in engineering time (Whatfix). Buying a SaaS tool costs $200–$1,000 per month. The math seems obvious.

But the framing ignores a third option that didn't exist five years ago: maintained open-source libraries that give you code ownership at near-zero cost.

// src/components/OnboardingTour.tsx
import { TourProvider, useTour } from '@tourkit/react';

const steps = [
  {
    target: '#welcome-header',
    title: 'Welcome to your dashboard',
    content: 'This is where you track your key metrics.',
  },
  {
    target: '#create-button',
    title: 'Create your first project',
    content: 'Click here to get started.',
  },
];

export function OnboardingTour() {
  return (
    <TourProvider steps={steps}>
      <TourControls />
    </TourProvider>
  );
}

function TourControls() {
  const { isActive, currentStep, next, prev, stop } = useTour();
  if (!isActive) return null;

  return (
    <div role="dialog" aria-label={`Step ${currentStep + 1}`}>
      {/* Your components, your design system, your rules */}
      <button onClick={prev}>Back</button>
      <button onClick={next}>Next</button>
      <button onClick={stop}>Skip tour</button>
    </div>
  );
}

That's a working tour. Your components, your design tokens, your ARIA attributes. No vendor script injection, no runtime bundle penalty, no surprise updates in production. The $50,000 build cost estimate assumes you're starting from scratch. With a headless library, you're not.

The real choice isn't "build vs. buy." It's "subscribe to a SaaS vendor and cede control, or use a maintained open-source library with full code ownership."

Check out a live demo on StackBlitz to see what developer-controlled onboarding looks like in practice.

Why someone might disagree (and where they're right)

The no-code camp has legitimate arguments. Dismissing them would be dishonest, so here's the steelman:

Speed to iteration. Teams using no-code tools who iterate on onboarding weekly see 25% higher activation rates than those waiting for quarterly engineering sprints (Whatfix). That's a real advantage. But the root cause is sprint cadence, not ownership. A developer-owned codebase with good CI/CD and feature flags can ship onboarding changes just as fast. The bottleneck isn't code. It's process.

Engineering is a scarce resource. A two-person startup can't dedicate an engineer to onboarding maintenance. Fair point. At the very earliest stage, a no-code tool might be the right call. But once you have real users and retention matters, onboarding quality becomes a core engineering concern whether you planned for it or not.

PMs understand the user better. Product managers should absolutely own onboarding strategy: what to show, when, to whom. Nothing in this article argues otherwise. The argument is about implementation. PMs define the experience. Developers build it reliably, accessibly, and performantly. Those roles aren't in conflict. They're complementary.

Where no-code advocates are wrong is in claiming that removing developers from the loop is a feature. It's a bug. One that shows up as inaccessible overlays, invisible performance costs, and technical debt that nobody owns.

What this means for your team

If you're a developer reading this, onboarding already is your problem. The question is whether you control it proactively or inherit it reactively.

Proactive ownership means:

• Onboarding tours live in your codebase, versioned and tested
• Accessibility is built in from the first step, not retrofitted
• Performance impact is visible in your CI pipeline
• Your design system extends to onboarding components
• Tour analytics flow through your existing stack (PostHog, Mixpanel, whatever you already run)

Reactive inheritance means:

• Debugging why a third-party script broke after a framework upgrade
• Explaining to legal why the product tour doesn't meet WCAG 2.1
• Writing CSS overrides with !important to make vendor tooltips match your design system
• Losing all onboarding analytics history when the company switches vendors

SensioLabs called it in their 2026 developer experience report: developer experience has gone "from a soft concern to a leading performance indicator" (SensioLabs). Onboarding is part of that experience, both the developer's experience building it and the user's experience receiving it.

What we'd do differently

We built User Tour Kit as a code-first onboarding library because we believe developers should own onboarding code. But we'd be the first to acknowledge it doesn't have a visual builder (PMs can't drag-and-drop tour steps), it requires React 18+, and the community is smaller than React Joyride or Shepherd.js. Those are real limitations.

What we'd recommend for any team considering this shift:

1. Audit your current onboarding stack. How much JavaScript does your no-code tool inject? Check with your browser DevTools Network tab. The number might surprise you.
2. Run a Lighthouse accessibility audit on a page with an active tour. If the score drops, you have a compliance gap that belongs to engineering.
3. Ask who gets paged when onboarding breaks. If the answer is "a developer," then developers should own the onboarding code. Full stop.
4. Start small. Replace one tour with a code-first approach. Measure the bundle size difference, the Lighthouse score difference, and the iteration speed.

Ownership doesn't mean doing everything alone. It means having control over the code that runs in your production environment. Onboarding is too important, and too technically complex, to delegate to a third-party script you can't inspect.

npm install @tourkit/core @tourkit/react

Get started with User Tour Kit, headless product tours you actually own. View source on GitHub.

FAQ

Is onboarding developer responsibility a new concept?

Onboarding developer responsibility isn't new, but it's gaining urgency. As of April 2026, React 19's strict mode, WCAG 2.1 enforcement trends, and Core Web Vitals ranking signals mean developers can no longer treat onboarding as "the PM's problem." The code that renders product tours runs in your bundle, affects your performance scores, and falls under your accessibility obligations. Tour Kit provides the code-first primitives that make developer ownership practical.

Should product managers have no role in onboarding?

Product managers should absolutely own onboarding strategy: defining what users see, when they see it, and why. The distinction is between strategy and implementation. PMs define the experience. Developers build it with accessible, performant, testable code. Code-first libraries like Tour Kit bridge this gap: PMs configure steps declaratively (JSON or component props), while developers control rendering, accessibility, and performance. Both roles stay in their zone of expertise.

What's wrong with no-code onboarding tools?

No-code onboarding tools inject 50 to 500KB of third-party JavaScript at runtime, bypassing tree-shaking and bundle analysis. They typically lack ARIA controls, keyboard trap prevention, and focus management required by WCAG 2.1 SC 4.1.2. Tour Kit's core ships at under 8KB gzipped with full accessibility controls, giving developers complete oversight of production code.

How does code-first onboarding handle PM iteration speed?

Code-first doesn't mean slow iteration. With feature flags (LaunchDarkly, PostHog), CI/CD pipelines, and declarative step configuration, developers ship onboarding changes in minutes. Tour Kit's step definitions are JSON-serializable, so a PM can update copy in a CMS or config file and CI deploys the change. The 25% activation advantage of weekly iteration applies whether changes flow through a visual builder or a code pipeline.

Is Tour Kit a replacement for Appcues or Userpilot?

Tour Kit replaces the UI layer that tools like Appcues and Userpilot provide, but with developer-owned code instead of vendor-injected scripts. Tour Kit is a headless React library: tour logic, step management, positioning, and accessibility primitives without prescribed UI. The tradeoff is no visual builder. The gain is under 8KB gzipped, full WCAG 2.1 compliance, zero vendor lock-in, and onboarding code that lives in your repo.

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