Building Onboarding Without Buying a Platform
Product onboarding has long been treated as a layer you bolt on after building – something you configure through a third-party dashboard and hope behaves consistently with the rest of your UI. Appcues built a sizable business on that assumption. Dopt is betting the assumption is wrong, and that engineering teams are finally fed up enough to agree.
Dopt positions itself not as an onboarding tool but as an onboarding infrastructure layer – a developer-first SDK that gives product engineers full control over flows, state, and logic without surrendering that control to a vendor’s visual editor. The pitch is quiet but pointed: stop paying for a platform your engineers resent, and start building onboarding like you build everything else.
What Appcues Gets Right, and Where the Cracks Show
Appcues earned its market position by solving a real problem. Non-technical teams – product managers, growth leads, customer success – needed a way to build and iterate on onboarding flows without waiting in an engineering queue. Appcues delivered that, and for many mid-sized SaaS companies, it still delivers it well enough. The no-code editor, the analytics layer, the segment targeting – none of it is broken. It just comes with tradeoffs that compound at scale.
The most common complaint from engineering teams using Appcues centers on consistency. When a tooltip or modal is controlled outside the codebase, it can drift visually from the product itself. Design system changes don’t automatically propagate into Appcues flows. Custom interactions hit hard limits. And because the logic lives in a dashboard rather than version control, debugging onboarding behavior becomes its own separate workflow. For small teams shipping fast, those tradeoffs are livable. For larger teams with strict design systems or complex conditional logic, they start to feel structural.
Dopt attacks exactly that surface area. Its SDK is built around the concept of “blocks” – composable units of onboarding state that engineers can query, render, and trigger from within their own components. There is no floating widget injected into the DOM from an external script. There is no visual editor managing state that your codebase doesn’t know about. The flow logic is defined in Dopt’s platform, but the rendering is entirely in the hands of the product team. That separation is the core of the value proposition.
The practical consequence is that a Dopt-powered tooltip looks exactly like every other tooltip in the product, because it is built with the same component library. A checklist, a modal, a spotlight – all rendered using the team’s own design system, with Dopt managing the state underneath. That might sound like more work, and technically it is more initial setup. But engineering teams that have priced out the long-term cost of maintaining a parallel design universe inside Appcues increasingly see Dopt’s approach as cheaper over time, not more expensive.
The Developer Sentiment Behind the Shift
There is a broader pattern playing out across the SaaS tooling market where developer-owned infrastructure is winning deals that product-owned platforms used to dominate. The same dynamic that has pushed some teams away from no-code analytics tools and back toward custom event pipelines is showing up in onboarding. Engineering teams that once tolerated black-box vendor tools are now negotiating harder for ownership, auditability, and control.
Dopt’s timing is deliberate. The company launched its SDK after watching product teams struggle with a specific class of problem: onboarding that needed to be deeply conditional, context-aware, or tightly integrated with application state. A user who has completed step three of a flow but abandoned before step four, mid-session. A flow that should only appear after a specific backend event fires. Branching logic that depends on a user’s account type, permissions, or usage history. Appcues can handle some of this through its targeting rules and integrations, but the more complex the condition, the more the implementation leaks back into engineering anyway.
Who Dopt Is Actually Competing For
Dopt is not trying to pull Appcues’ entire customer base. A growth team at a 40-person company that wants to ship a product tour by Thursday afternoon without writing a line of code is not Dopt’s prospect. Appcues – or Pendo, or Intercom’s product tours feature – still wins that scenario cleanly. Dopt is targeting teams where engineering is already involved in onboarding decisions, where design consistency is non-negotiable, or where the onboarding experience is complex enough that vendor abstractions have become obstacles rather than shortcuts.
That addressable market is meaningful. Many companies that started with Appcues outgrow it as their product matures. The first onboarding flows are simple – a welcome modal, a few tooltips, a checklist. Two years later, the product has grown, the user base has segmented, and the onboarding needs to branch across dozens of conditions. That is the moment Dopt has positioned itself to catch. The sales conversation it wants is not “why switch from Appcues on day one” but “why rebuild your onboarding infrastructure when you’re already rebuilding everything else.”
The open question is whether Dopt can build enough tooling around the SDK to reduce the engineering lift for teams that want control but don’t want to start from zero. Its flow builder and analytics are functional, but the ecosystem of templates, integrations, and pre-built patterns that Appcues has accumulated over years is a real advantage. Appcues also has strong customer success infrastructure – the kind of support that keeps mid-market buyers locked in even when competitors look attractive technically. A developer SDK wins benchmark comparisons; it doesn’t automatically win renewal conversations.
Dopt’s strongest near-term leverage is in new customer acquisition among developer-led companies, particularly those building B2B SaaS products where the engineering team has significant influence over tooling decisions. For those buyers, the SDK model isn’t just technically preferable – it fits the culture of how they evaluate and buy software. They want to read the docs, run a proof of concept, and own what they build. That pattern is well-established in adjacent categories, from headless browser infrastructure to authentication tooling, and it has a real track record of displacing incumbent platforms over an 18-to-36-month window. Whether Appcues has enough of a head start to hold its growth base through that window is the more interesting competitive question.
