How we set Tour Kit's price at $99

I spent three weeks staring at a spreadsheet with one column: "Price." The rows were $49, $79, $99, $149, $199. Each had a napkin-math revenue projection. None of them felt right.

Tour Kit is a headless product tour library for React. Ten packages, MIT core, TypeScript-first. The kind of thing most developers expect to be free. And most of it is. But the extended packages (surveys, scheduling, adoption tracking) need to pay for themselves or they stop getting maintained.

This is the full story of how I landed on $99 one-time. The spreadsheets, the wrong assumptions, the data that changed my mind, and the math I wish someone had shown me before I started.

npm install @tourkit/core @tourkit/react

The core and React packages are MIT. Free forever. What follows is about the Pro tier.

The starting point: subscription was the default

Every pricing article I read in early 2026 said the same thing. Charge monthly. MRR is the metric that matters. Investors want recurring revenue. SaaS multiples are 8-12x ARR.

I built the first pricing page with three tiers: $19/month Starter, $49/month Pro, $99/month Team. Standard SaaS grid. Three columns, a highlighted "Most Popular" badge on the middle one. You've seen it a thousand times.

Then I actually looked at what I was selling. Tour Kit isn't a hosted service. No server, no dashboard, no data pipeline. It's npm packages that ship in your bundle. The "subscription" would be paying monthly for... what exactly? Permission to keep using code already in your node_modules?

That felt dishonest. A Heavybit study on developer tool pricing confirmed my gut: 56% of developers choose tools based on productivity gains, not cost savings. Only 5% pick tools because they're cheap.

Key decision 1: one-time vs. recurring

The data surprised me. SlashData research found 39% of developers prefer one-time purchases for tooling, and that number climbs to 44% for tools that ship as packages (IDEs, editors, libraries). Subscriptions still win overall at 53%, but the gap narrows for anything that doesn't require a running server.

An Indie Hackers thread on subscriptions vs. one-time payments crystallized it for me. One developer wrote:

"As a solo dev, I'm not trying to build a $10M SaaS. I care more about focus, simplicity, and building useful things without running a customer support empire."

That hit hard. Another commenter, who'd switched from subscription to one-time for their own product:

"Conversion rate went up (less commitment = more yes). Support burden went down (no monthly churn anxiety)."

I chose one-time. But the honest truth is that subscription users pay more over time. One commenter put it bluntly: "Subscription users ended up paying several times more over time than one-time buyers." I'm leaving long-term revenue on the table. I know that.

Here's why I'm okay with it: Tour Kit is a library, not a platform. You install it, configure it, ship it. You don't log in every morning. Charging monthly for something you interact with once during setup and then forget about feels like a trick. And tricks erode trust.

Key decision 2: why $99 and not $49 or $199

As of April 2026, developer tool pricing ranges from $0 to $1,000/user/month, with a median around $32/user/month according to CostBench data. A $99 one-time payment equals roughly three months of a typical tool subscription. That's the anchor I wanted.

The psychology breaks down into three zones:

$20-$49: the impulse zone. People buy without thinking. But they also forget about it. Low-commitment purchases get low commitment from buyers. Docs go unread, configuration gets skipped, and support tickets pile up.

$100-$500: the approval zone. At most companies, anything over $100 requires a manager's sign-off. That adds friction and a second decision-maker who doesn't care about your DX preferences. I wanted to stay below that line.

$50-$99: the "I'll expense this" zone. High enough to signal professional quality. Low enough for a single developer to put on their company card without asking anyone. This is the zone where react-admin, Tailwind UI, and most successful open-core React tools live.

react-admin generates roughly 1 million euros per year from their open-core model (Marmelab). Tailwind UI proved that premium add-ons around a free CSS framework work. Tour Kit's model is structurally identical: free core, paid extensions.

$99 it was.

Key decision 3: where to draw the MIT/Pro line

This is the decision that keeps open-core maintainers up at night. Draw the line wrong and your community revolts. The n8n pricing controversy showed what happens when the boundary feels arbitrary:

"The code is public, the community contributes, then pricing lands where autonomy used to live. People push back when the meter sits between them and their own infrastructure."

n8n transitioned from open source to open-core after building a community. Tour Kit was designed as open-core from day one. That distinction matters. Nobody contributed code expecting everything to stay free, because the boundary was published before the first commit.

The split maps to who benefits, not what I could charge for:

The MIT packages give you a complete product tour system. Steps, navigation, highlighting, hints, persistence, keyboard navigation, screen reader support. A solo developer building their first onboarding flow never hits a paywall.

The Pro packages solve organizational problems: NPS surveys, onboarding checklists, feature adoption tracking, scheduled announcements. These are things a product team needs, not a single developer. OpenLogic's 2023 survey found that 67% of enterprises using open-core products eventually upgrade to paid tiers. The funnel works when the boundary makes sense to the buyer.

What went wrong: the payment infrastructure rabbit hole

I wasted two weeks building custom Stripe integration. Webhook handlers. License key generation. Activation limits. A validation API. Database tables for tracking licenses.

Then I found Polar.sh. It handles license key delivery, file downloads, and payment processing at 4% + $0.40 per transaction. That's cheaper than Gumroad or Lemon Squeezy, and it's purpose-built for developer tools. Guillermo Rauch (Vercel's CEO) called it:

"The speed at which Polar is executing on the financial infrastructure primitives the new world needs is very impressive."

I deleted 800 lines of payment code and replaced it with a Polar integration. The entire monetization backend is now someone else's problem. Zero custom infrastructure for license delivery.

That two weeks of wasted work taught me something: the default instinct for developers is to build. But building payment infrastructure isn't my competitive advantage. Building a better tour library is.

What went wrong: pricing in a vacuum

My first mistake was treating pricing as a solo decision. I set $99 based on competitor analysis and spreadsheet models, then went quiet for a month. No blog post. No tweet thread. No "hey, I'm thinking about charging $99, what do you think?"

When I finally showed the pricing page, the first reaction wasn't about the price. It was about the packages. "Wait, analytics is Pro-only? I just want to track tour completion." That feedback shifted the boundary. Basic event callbacks moved to the free tier. The analytics plugin system stayed in Pro.

Building in public works because it turns pricing into a conversation. Research shows projects shared publicly see 30% higher community engagement, and 45% of creators who shared their journey reported stronger user trust and brand loyalty.

Should have done that from the start.

What worked: the boundary nobody argued with

The MIT/Pro split landed without controversy. Not a single GitHub issue, not one angry tweet. I think it's because the boundary follows a natural line: individual developer needs (free) vs. organizational needs (paid). Nobody expects NPS survey infrastructure to be free. Nobody feels cheated that basic tour steps are MIT.

The $99 one-time model also eliminated an entire category of support tickets. No failed renewals. No "my subscription lapsed and tours stopped working." No mid-quarter budget reviews where someone cancels your tool. Once installed, Tour Kit works. Forever.

And Polar's license key delivery just... worked. A buyer pays $99, gets a key in their email, runs npx tourkit activate <key>, and the Pro packages activate. The entire purchase-to-activation flow takes under 90 seconds with zero custom infrastructure on my end.

The napkin math I wish existed

Nobody publishes this, so here it is. My actual sustainability calculation for Tour Kit at $99 per license:

• Polar takes 4% + $0.40 per transaction: $95.64 net per sale
• Monthly costs (domain, hosting, CI, email): roughly $85/month
• Target: cover costs + equivalent of part-time salary at $5,000/month
• $5,085/month / $95.64 per sale = 54 licenses per month

54 sales a month. That's the number. Not 5,000 MRR or 10,000 ARR or whatever SaaS Twitter chases. Just 54 developers (or teams) who need surveys, scheduling, and adoption tracking on top of their product tours.

Is that realistic? The software development tools market is growing from $6.41 billion in 2025 to a projected $7.44 billion in 2026 (Mordor Intelligence). GitHub Copilot hit $400 million in revenue in 2025 with 248% year-over-year growth. Developers are paying for tooling at rates we've never seen before. 54 licenses a month for a well-positioned React library isn't fantasy.

But it's not guaranteed either. Tour Kit doesn't have React Joyride's 603K weekly downloads or Shepherd.js's decade of brand recognition. It has a smaller community, no visual builder, and a React 18+ requirement that excludes legacy projects. Those are real limitations, and pretending otherwise would undermine every trust signal in this post.

What I'd do differently

Start the pricing conversation earlier. I should have posted the pricing model alongside the first public commit. By the time I showed it, people had already formed expectations about what would be free.

Skip the custom Stripe code entirely. Every hour spent on payment infrastructure was an hour not spent on the actual library. Polar (or a similar service) should be the first choice, not the fallback.

Publish the napkin math on day one. The "54 licenses a month" number disarms skepticism faster than any marketing page. When people see the actual sustainability threshold, they root for you. When they see polished pricing tiers with no context, they assume you're optimizing for extraction.

What's next

The $99 price isn't permanent. It's the launch price, and I'll adjust based on real data. If the Pro packages deliver enough value that teams would pay $149, the price goes up. If 54/month turns out to be too ambitious for a young library, it goes down.

But the model stays: one-time payment, MIT core, Pro extensions. No monthly meter running between developers and their own code.

If you want to see the free tier in action, the core and React packages are on npm:

npm install @tourkit/core @tourkit/react

Full documentation at usertourkit.com. The code is on GitHub if you want to judge the quality before the pricing.

And if 54 people a month think the Pro packages are worth $99, this whole thing sustains itself. If not, you'll read about that here too.

Internal linking suggestions:

• Link from build-vs-buy-product-tour-calculator (TCO context)
• Link from one-time-license-vs-subscription-math-bootstrapped-teams (pricing model comparison)
• Link from mau-pricing-onboarding-tool (anti-MAU pricing angle)
• Link to composable-tour-library-architecture (architecture decisions)
• Link to open-source-onboarding-cost-developer-time (cost context)

Distribution checklist:

• Indie Hackers (primary target: building-in-public audience)
• Hacker News (Show HN angle: transparent pricing breakdown)
• Reddit r/reactjs (developer tool pricing angle)
• Reddit r/SaaS (one-time vs subscription debate)
• Dev.to (cross-post with canonical URL)
• Twitter/X thread (napkin math as hook)

Related articles

Build vs BuyApr 9, 2026 · 8 min read

TCO comparison: 3 years of Appcues vs 3 years of Tour Kit

We modeled the full 3-year total cost of ownership for Appcues and Tour Kit at three MAU tiers. See every line item, the compounding effects, and where each tool wins.

Read article

Build vs BuyApr 9, 2026 · 10 min read

The developer's calculator: DIY tour vs library vs SaaS

Calculate the real cost of DIY tours, libraries, and SaaS tools. Compare 3-year TCO with sourced numbers before committing engineering hours.

Read article

Build vs BuyApr 9, 2026 · 12 min read

How to calculate onboarding software ROI (2026)

Calculate onboarding software ROI with concrete formulas, benchmark data, and a fill-in worksheet. Includes build vs buy cost comparison for 2026.

Read article

Build vs BuyApr 9, 2026 · 11 min read

Data ownership in onboarding: who owns your tour analytics?

Examine who actually owns your product tour analytics data when using SaaS onboarding tools. Compare vendor custody, GDPR roles, and code-owned alternatives.

Read article