Your product tour shouldn't be a hostage situation.
Right now, if you're using most tour builders, your onboarding flows live in someone else's dashboard. You can't see them in git. You can't code review them. You can't roll them back with a simple revert. You're one pricing increase, API change, or outage away from scrambling to save your work.
It shouldn't be this way.
The Problem with Vendor-Locked Tours
When your tours live in a dashboard, they're disconnected from your actual product. Your developer ships a UI change, but the tour still points to the old button. You realize the onboarding is broken three weeks later when support gets complaints.
No git history means no way to know who changed what, when, or why. No pull request means you can't discuss tour changes with your team before they go live. And if the vendor raises their prices by 300 percent? You're either paying or rebuilding from scratch.
This is backwards. Your onboarding is part of your product. It deserves the same treatment: version control, code review, CI/CD integration, and permanent ownership.
The Better Way: Tours as Code
Imagine if your tour was just JSON in your repo, reviewed like any other pull request, deployed with your code.
When your designer wants to update the copy on step three, they open a PR. Your product manager reviews it. Your engineer checks that the selectors still match the DOM. It merges. It ships. Everyone knows exactly what happened and when.
Rollbacks are git reverts. Backups are free. Vendor lock-in is zero.
Here's what a simple tour looks like as JSON:
{
"id": "onboarding-flow",
"steps": [
{
"title": "Welcome to Dashboard",
"description": "Let's set up your workspace in 3 minutes.",
"target": "[data-tour='dashboard-header']",
"position": "bottom"
},
{
"title": "Create Your First Project",
"description": "Click here to start building.",
"target": "[data-tour='new-project-btn']",
"position": "right"
}
]
}
That's it. No vendor. No mystery API calls. Just data that lives next to your code.
How This Changes Your Workflow
Pull requests for onboarding changes become normal. You can diff them. You can require approval. Your tour's evolution is visible in git blame.
Continuous integration gets smarter. You can write Playwright tests that verify each tour step still targets valid DOM elements. A UI change that would break your onboarding gets caught in CI, not discovered by users.
Analytics and feedback stay decoupled. You track completions and dropoff in your own database or analytics tool. You own that data. No dashboard dependency.
When you need to A/B test a tour, you version it in git and deploy the variant. When you want to migrate to a different platform later, your tour is a portable JSON file. Not locked in. Not lost.
The Real Win
This isn't about being contrarian. It's about keeping your product yours.
Your code lives in your repo. Your infrastructure lives in your control. Your onboarding should too. Tours as JSON files, versioned with your code, reviewed in pull requests, owned forever.
This is what Trailguide does. It's MIT-licensed and free to try. Your tours are plain JSON. They ship with your code. You can integrate Playwright tests to catch tour breakage before production. Analytics and user feedback are built in, but the tour itself is always yours, always in version control.
No dashboard. No vendor lock-in. No surprises.
Try it free at gettrailguide.com
Top comments (0)