DEV Community

Cover image for I Open-Sourced the SDK Behind My SaaS — Here's Why
Raj Chavan
Raj Chavan

Posted on

I Open-Sourced the SDK Behind My SaaS — Here's Why

#opensource #saas #javascript #buildinpublic

I've been building TourKit for the past 3 months — a product tour SDK for SaaS products.

One script tag. Dashboard-controlled tours.
Works on React, Next.js, Vue, HTML, WordPress.

Today I open-sourced the SDK under an MIT license.

Here's why and what's inside.

The problem with closed-source SDKs

When you install a third-party script on your website, you're trusting that it:

  • Doesn't track your users beyond what it says
  • Doesn't inject anything malicious
  • Does exactly what it claims to do

With a closed-source SDK, you have to take the company's word for it.

That's a hard sell for security-conscious developers — especially when the script runs on every page of their product.

So I open-sourced it

The TourKit SDK is now public and MIT-licensed.

github.com/webdev-raj/Tourkit-sdk

You can read every line of code that runs on your users' websites. Audit it. Fork it. Self-host it if you want.

What's inside the SDK

The SDK is vanilla JavaScript with zero dependencies. Here's what it does:

index.js — Config fetcher

// Reads data-key from script tag
// Fetches tour config from TourKit API
// Calls startTour() with steps + config
window.TourKit = {
  startFor: function(path) { ... },
  destroy: function() { ... },
  reset: function(path) { ... },
  resetAll: function() { ... }
}
Enter fullscreen mode Exit fullscreen mode

renderer.js — Tooltip engine

  • Creates spotlight overlay
  • Positions tooltip (top/bottom/left/right)
  • Handles step transitions
  • Mobile bottom sheet under 768px
  • Tracks analytics events

session-key.js — Seen flag management

// Per-path localStorage keys
// tourkit_seen_KEY_dashboard
// tourkit_seen_KEY_projects
// Each page independent
Enter fullscreen mode Exit fullscreen mode

The mobile bottom sheet

This is the part I'm most proud of.

Every other tour SDK breaks on mobile.
Intercom literally doesn't support mobile product tours — their docs say so.

TourKit automatically switches to bottom sheet mode on screens under 768px:

Desktop (768px+):
Tooltip floats beside highlighted element

Mobile (under 768px):
Element highlighted at top of screen
Tooltip slides up from the bottom
Feels completely native

Zero config. SDK detects screen size and switches automatically.

URL-based tour triggers

Each step can target a specific page:

{
  "title": "Your projects",
  "message": "Manage all your projects here",
  "selector": "[data-tourkit='projects-list']",
  "position": "bottom",
  "url_pattern": "/dashboard/projects"
}
Enter fullscreen mode Exit fullscreen mode

Pattern matching supports:

  • Exact: /dashboard
  • Dynamic: /dashboard/projects/[id]
  • Wildcard: /dashboard/*
  • All pages: null

The SDK checks window.location.pathnameon every route change and starts the tour from the matching step automatically.

The AI workflow (the real differentiator)

This is what makes TourKit different from every other tour tool:

Step 1 — Copy the AI prompt
From your TourKit dashboard, copy the agent prompt with one click.

Step 2 — Paste into Cursor
Your AI agent:

  • Reads your entire codebase
  • Identifies key UI elements
  • Adds data-tourkit attributes
  • Detects your routes automatically
  • Generates tour.json with correct url_patterns for each page

Step 3 — Drag and drop
Drop tour.json into the TourKit dashboard. All steps import instantly.

Step 4 — Add script tag once

<script
  src="https://cdn.jsdelivr.net/gh/webdev-raj/Tourkit-sdk@v1.0.0/dist/tourkit.min.js"
  data-key="YOUR_KEY"
  data-api="https://tourkit-phi.vercel.app"
  async>
</script>
Enter fullscreen mode Exit fullscreen mode

Live tour in under 2 minutes.
No manual CSS selectors.
No guessing which elements to highlight.

The open core model

Dashboard stays private.
SDK is open source.

Same model as:

  • Plausible Analytics
  • Cal.com
  • Supabase
  • Fathom

The SDK is the delivery mechanism.
The dashboard is where the value lives — step editor, analytics, AI generator, prebuilt templates, team management.

Current honest status

  • ✅ SDK open source + MIT licensed
  • ✅ Working on React, Next.js, Vue, HTML
  • ✅ Mobile bottom sheet tours
  • ✅ AI tour generator
  • ✅ JSON drag and drop import
  • ✅ Analytics dashboard
  • ❌ 0 paying customers
  • ❌ npm package (coming soon)

Try it

Dashboard (free plan available):
tourkit-phi.vercel.app

Open source SDK:
github.com/webdev-raj/Tourkit-sdk

Docs:
tourkit-phi.vercel.app/docs

If you're building a SaaS and need user onboarding — I'd genuinely love for you to try it and tell me what's broken or missing.

And if you find the SDK useful — a GitHub star genuinely helps with
discovery 🙏

Building in public. 3 months in. 0 paying customers. Shipping every week.

Top comments (5)

Collapse
 
vollos profile image
Pon •

Pinning the CDN tag at v1.0.0 does a lot of unadvertised work for the trust story: whoever audits that version keeps running exactly what they audited, right up until they bump the tag themselves. The flip side is patches, when you fix a bug in the SDK, does the dashboard nudge people still pinned to old tags, or do fixed versions sit there unnoticed? That update path feels like the unglamorous half of open-sourcing the delivery mechanism.

Collapse
 
raj_chavan524 profile image
Raj Chavan •

You put your finger on exactly the unglamorous part I haven't solved yet
But you're right that right now there's no update path; bug fix ships and sits there invisible to everyone still on the old tag
The bridge I'm thinking about: dashboard shows current SDK version vs latest available with a one-line diff of what changed

so the developer sees it, makes a conscious decision to update, and pastes the new tag themselves; keeps the "you control what runs on your site" promise but removes the "updates sit unnoticed" problem
haven't built it yet

thanks men

Collapse
 
vollos profile image
Pon •

That bridge keeps the promise intact, the developer stays the one who moves the tag, and it kills the invisible-fix problem at the same time. If the one-line diff also says fix or feature, the pinned crowd can tell update-whenever from update-this-week at a glance.

Collapse
 
elbokazqc profile image
elboKazQC •

The audit story has one gap that pinning alone does not close: what a developer reads on GitHub and what their browser actually executes are two different artifacts. They audit the repo, the browser loads a file from a CDN. Pinning to v1.0.0 fixes the version, it does not prove the bytes served at that URL still match the tag anyone audited.

The piece that closes it is subresource integrity, and jsDelivr supports it:

<script src="...tourkit.min.js"
        integrity="sha384-..."
        crossorigin="anonymous"
        data-key="YOUR_KEY" async></script>
Enter fullscreen mode Exit fullscreen mode

Now the browser refuses to run the file if a single byte differs from what was audited. It also sharpens the update path from the thread above: changing the SDK forces the developer to change the hash, so a silent swap becomes impossible by construction instead of by policy. Publishing the hash beside each version tag in the dashboard would slot straight into that one-line diff idea.

Worth saying from the other side of the fence: that whole audit story is a privilege of shipping in a browser. I ship a desktop tool, also MIT, and open source buys me far less trust than it buys you, because nobody can verify that the installer they ran was built from the code they read. No network tab, no reproducible build, just my word for it. You can hand people a verifiable claim. Most of us can only hand them a plausible one.

Collapse
 
raj_chavan524 profile image
Raj Chavan •

Thanks for saving. I was focused on version pinning, but you're right that SRI adds a stronger verification layer by ensuring the browser only executes the exact audited build
Publishing the integrity hash with each SDK release feels like a natural next step. Have you seen many developer tools actually expose SRI hashes as part of their release workflow?