Keep Your Product Tours in Git, Not Behind a Vendor Dashboard

You know that feeling when a SaaS tool you depend on suddenly changes its pricing, goes down for maintenance, or worse, shuts down entirely? And all your product tours are locked inside their dashboard, inaccessible, unversioned, gone.

Then there's the workflow problem. Your designer updates a tour. It lives only in the vendor's UI. Your engineer has no idea what changed. No code review. No git history. No way to rollback if something breaks in production.

This is why product tours deserve to live where everything else does: in your repository, as plain text files, under version control, owned by you forever.

The Problem With Vendor-Locked Tours

Most product tour tools force you into a visual builder. Click buttons, drag elements, save to their database. It feels easy at first. Then reality hits.

Your team can't review changes before they go live. If a tour breaks user onboarding, you can't just git revert it. You're stuck in the vendor's UI, hunting for what changed. And if the service goes down (it happens), your tours go with it.

Worse: you're paying monthly for the privilege. If you ever want out, everything stays locked away.

The Better Way: Tours as Code

What if your tours were just JSON files sitting in your repo? No vendor dashboard. No lock-in. Just plain data that lives alongside your actual code.

This changes everything:

Your team reviews tour changes in pull requests, just like features. You see exactly what updated. Feedback happens in GitHub. Tours get tested before deployment. Rollbacks are instant with git.

Your git history becomes your audit trail. Who changed what tour, and when? It's all there. Forever.

Here's what that looks like:

{
  "id": "checkout-flow",
  "title": "Complete Your Purchase",
  "steps": [
    {
      "selector": ".cart-summary",
      "title": "Review Your Order",
      "body": "Double-check items and quantities here.",
      "position": "right"
    },
    {
      "selector": "[data-testid='payment-method']",
      "title": "Choose Payment",
      "body": "We support cards, PayPal, and Apple Pay.",
      "position": "bottom"
    }
  ]
}

That's it. No vendor magic. No visual builder. Just your tour, defined clearly, living in version control.

Testing and Deployment

Since tours are JSON in your repo, they integrate with your existing workflow. You can validate the schema in CI. You can write Playwright tests that confirm your tours actually work with the current UI (selectors don't break, steps appear when expected).

When you deploy your app, your tours deploy with it. Same commit. Same confidence.

No more "we updated the product but forgot to update the tour" surprises. No more tours pointing to buttons that don't exist.

What About Analytics?

You'll want to know if tours actually help users. That's not a vendor lock-in problem to solve in JSON, but it is something worth tracking. Events go where all your other analytics go: your own infrastructure, your data warehouse, your rules.

Product tour data should follow the same principles as everything else. Yours to own. Yours to query.

You Don't Have to Build This Alone

Building a tour system from scratch takes time. You need the JSON schema, the player that renders tours in your app, the analytics, the CI integrations. You need to maintain it as your product evolves.

If you want the philosophy without the build, Trailguide does this: tours as JSON files you commit to git, players for React and vanilla JS, Playwright testing built in, analytics optional. It's free to try at gettrailguide.com, with a Pro plan for teams that want more.